ACC, HIMSS and RSNA
Integrating the Healthcare Enterprise5

IT Infrastructure
Technical Framework
10

Volume 2(ITI TF-2)
Transactions

15
Revision 2.0 – Final Text
August 15, 2005
Copyright © 2005: ACC/HIMSS/RSNA
20

25

30

35

40

45

50

55

60

65

Contents
1 Introduction......................................................................................................................... 3
1.1 Overview of the Technical Framework..........................................................................3
1.2 Overview of IT Infrastructure Technical Framework Volume II ....................................4
1.3 Audience.......................................................................................................................5
1.4 Relationship to Standards ..............................................................................................5
1.5 Relationship to Real-world Architectures ......................................................................5
1.6 Comments .....................................................................................................................6
1.7 Copyright Permission ....................................................................................................6
2 Conventions ........................................................................................................................ 7
2.1 The Generic IHE Transaction Model .............................................................................7
2.2 HL7 Profiling Conventions............................................................................................8
2.3 Use of Coded Entities and Coding Schemes ..................................................................8
3 IHE Transactions................................................................................................................. 9
3.1 Maintain Time.............................................................................................................10
3.2 Get User Authentication ..............................................................................................13
3.3 Get Service Ticket.......................................................................................................16
3.4 Kerberized Communication.........................................................................................19
3.5 Join Context ................................................................................................................24
3.6 Change Context...........................................................................................................30
3.7 Leave Context .............................................................................................................37
3.8 Patient Identity Feed....................................................................................................40
3.9 PIX Query...................................................................................................................50
3.10 PIX Update Notification..............................................................................................60
3.11 Retrieve Specific Information for Display ...................................................................64
3.12 Retrieve Document for Display ...................................................................................75
3.13 Follow Context............................................................................................................80
3.14 Register Document Set ................................................................................................86
3.15 Provide and Register Document Set...........................................................................128
3.16 Query Registry..........................................................................................................139
3.17 Retrieve Document....................................................................................................160
3.18 Intentionally Left Blank (ITI-18)...............................................................................165
3.19 Authenticate Node.....................................................................................................166
3.20 Record Audit Event ...................................................................................................171
3.21 Patient Demographics Query.....................................................................................187
3.22 Patient Demographics and Visit Query......................................................................199
3.23 Find Personnel White Pages ......................................................................................212
3.24 Query Personnel White Pages....................................................................................215
Appendix A:
Web Service Definition for Retrieve Specific Information for Display and
Retrieve Document for Display Transaction .....................................................................229
Appendix B:
Definition of Document Unique IDs.............................................................235
B.1: Requirements for Document UIDs.............................................................................235
B.2: Structure of a Document UID....................................................................................235
B.3: Document UID encoding rules ..................................................................................236
B.4: How to obtain a UID registration root?......................................................................236
B.5: Example of a Document UID ....................................................................................236

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

70

75

80

85

90

95

100

Appendix C:
HL7 Profiling Conventions ..........................................................................238
C.1: HL7 Implementation Notes .......................................................................................239
Appendix D:
Cross-Profile Interactions of PIX and PSA ...................................................242
D.1: Namespace Translation from PIX Query to CCOW...................................................244
D.2: Processing Multiple Identifiers ..................................................................................245
Appendix E:
Usage of the CX Data Type in PID-3-Patient Identifier List .........................246
E.1: Patient Identifier Cross-reference Manager actor requirements ..................................247
E.2: Other actor requirements ...........................................................................................248
E.3: E.3 Examples of use ..................................................................................................249
E.3.1:Data sent by source systems ......................................................................................249
E.3.2:Data sent by the Patient Identifier Cross-reference Manager ......................................250
Appendix F:
Intentionally Left Blank ...............................................................................252
Appendix G:
Transition from Radiology Basic Security to ATNA ....................................253
G.1: Message Transformation ...........................................................................................253
Appendix H:
Required Registry Initialization and Schema ................................................264
H.1: Initialization..............................................................................................................264
H.2: Schema .....................................................................................................................264
H.3: Location....................................................................................................................264
Appendix I: Required Initialization of the Affinity Domain .................................................265
Appendix J: Example Submissions and Query Results .........................................................266
Appendix K:
XDS Security Environment ..........................................................................267
K.1: Security Environment................................................................................................267
K.1.1: Threats.................................................................................................................267
K.1.2: Security and Privacy Policy .................................................................................269
K.1.3: Security Usage Assumptions................................................................................270
K.2: Security Objectives ...................................................................................................270
K.2.1: XDS Component Security Objectives ..................................................................271
K.2.2: Environment Security Objectives .........................................................................273
K.3: Functional Environment ............................................................................................273
Appendix L:
Relationship of Document Entry Attributes and Document Headers .............276
Appendix M:
Using Patient Demographics Query in a Multi-Domain Environment ...........284
M.1: HL7 QBP^Q22 Conformance Model.........................................................................284
M.2: IHE PDQ Architecture ..............................................................................................284
M.3: Implementing PDQ in a multi-domain architecture....................................................285
GLOSSARY ...........................................................................................................................287__________________________________________________________________________
2
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1 Introduction

105

110

115

120

125

130

135

Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integrationof the information systems that support modern healthcare institutions. Its fundamental objective
is to ensure that in the care of patients all required information for medical decisions is bothcorrect and available to healthcare professionals. The IHE initiative is both a process and aforum 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 exhibits at major meetings of medical professionals to demonstrate thebenefits of this framework and encourage its adoption by industry and users.
The approach employed in the IHE initiative is to support the use of existing standards, e.g HL7,
ASTM, DICOM, ISO, IETF, OASIS and others as appropriate, rather than to define newstandards. IHE profiles further constrain configuration choices where necessary in thesestandards to ensure that they can be used in their respective domains in an integrated manner
between different actors. 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(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 theEuropean Association of Radiology (EAR) and European Congress of Radiologists (ECR), theCoordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche
Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation duSystème d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società
Italiana di Radiologia Medica (SIRM), and the European Institute for health Records (EuroRec).
In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); theMinistry of Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include theJapan Industries Association of Radiological Systems (JIRA), the Japan Association of
Healthcare Information Systems Industry (JAHIS), Japan 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.

1.1 Overview of the Technical Framework
This document, the IHE IT Infrastructure Technical Framework (ITI TF), defines specificimplementations 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__________________________________________________________________________
3
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

140

145

150

155

160

period of public review, and maintained regularly through the identification and correction oferrata. The current version, rev. 2.0 for Final Text, specifies the IHE transactions defined andimplemented as of August 2005. The latest version of the document is always available via theInternet at http://www.ihe.net/Technical_Framework .
The IHE IT Infrastructure Technical Framework identifies a subset of the functional componentsof the healthcare enterprise, called IHE actors, and specifies their interactions in terms of a set ofcoordinated, standards-based transactions. It describes this body of transactions in progressively
greater depth. The present volume (ITI TF-1) provides a high-level view of IHE functionality,
showing the transactions organized into functional units called integration profiles that highlighttheir capacity to address specific IT Infrastructure requirements.
Volume 2 of the IT Infrastructure Technical Framework (ITI TF-2) provides detailed technicaldescriptions of each IHE transaction used in the IT Infrastructure Integration Profiles. These twovolumes are consistent and can be used in conjunction with the Integration Profiles of other IHE
domains.
The other domains within the IHE initiative also produce Technical Frameworks within theirrespective areas that together form the IHE Technical Framework. Currently, the following IHE
Technical Framework(s) are available:• IHE IT Infrastructure Technical Framework• IHE Cardiology Technical Framework• IHE Laboratory Technical Framework• IHE Patient Care Coordination Technical Framework• IHE Radiology Technical Framework
Where applicable, references are made to other technical frameworks. For the conventions onreferencing other frameworks, see Section 1.6.3 within this volume.

1.2 Overview of IT Infrastructure Technical Framework Volume II
165

The remainder of Section 1 further describes the general nature, purpose and function of theTechnical Framework. Section 2 presents the conventions used in this volume to define IHE
transactions.
Section 3 defines transactions in detail, specifying the roles for each Actor, the standards
employed, the information exchanged, and in some cases, implementation options for thetransaction.

170

The appendices following the main body of this volume provide technical details associated withthe transactions.

__________________________________________________________________________
4
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1.3 Audience

175

The intended audience of this document is:• IT departments of healthcare institutions• Technical staff of vendors planning to participate in the IHE initiative• Experts involved in standards development• Those interested in integrating healthcare information systems and workflows

1.4 Relationship to Standards
180

The IHE Technical Framework identifies functional components of a distributed healthcare
environment (referred to as IHE actors), solely from the point of view of their interactions in thehealthcare enterprise. At its current level of development, it defines a coordinated set oftransactions based on ASTM, DICOM, HL7, IETF, ISO, OASIS and W3C standards. As thescope of the IHE initiative expands, transactions based on other standards may be included as
required.

185

In some cases, IHE recommends selection of specific options supported by these standards;
however, IHE does not introduce technical choices that contradict conformance to thesestandards. If errors in or extensions to existing standards are identified, IHE’s policy is to reportthem to the appropriate standards bodies for resolution within their conformance and standards
evolution strategy.

190

IHE is therefore an implementation framework, not a standard. Conformance claims for products
must still be made in direct reference to specific standards. In addition, vendors who have
implemented IHE integration capabilities in their products may publish IHE Integration
Statements to communicate their products’ capabilities. Vendors publishing IHE Integration
Statements accept full responsibility for their content. By comparing the IHE Integration
Statements from different products, a user familiar with the IHE concepts of actors andintegration profiles can determine the level of integration between them. See Appendix C for theformat of IHE Integration Statements.

195

1.5 Relationship to Real-world Architectures
200

205

The IHE actors and transactions described in the IHE Technical Framework are abstractions of
the real-world healthcare information system environment. While some of the transactions are
traditionally performed by specific product categories (e.g. HIS, Clinical Data Repository,
Radiology Information Systems, Clinical Information Systems or Cardiology Information
Systems), the IHE Technical Framework intentionally avoids associating functions or actors withsuch product categories. For each Actor, the IHE Technical Framework defines only thosefunctions associated with integrating information systems. The IHE definition of an Actor should
therefore not be taken as the complete definition of any product that might implement it, nor__________________________________________________________________________
5
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
should the framework itself be taken to comprehensively describe the architecture of a healthcare
information system.
210

215

The reason for defining actors and transactions is to provide a basis for defining the interactions
among functional components of the healthcare information system environment. In situations
where a single physical product implements multiple functions, only the interfaces between the
product and external functions in the environment are considered to be significant by the IHE
initiative. Therefore, the IHE initiative takes no position as to the relative merits of an integrated
environment based on a single, all-encompassing information system versus one based on
multiple systems that together achieve the same end. IHE demonstrations emphasize theintegration of multiple vendors’ systems based on the IHE Technical Framework.

1.6 Comments
HIMSS and RSNA welcome comments on this document and the IHE initiative. They should bedirected to the discussion server at http://ihe.rsna.org/ihetf/ or to:
220

225

Chris Carr
Director of Informatics
820 Jorie Boulevard
Oak Brook, IL 60523
Email: ihe@rsna.org

Joyce Sensmeier
Director of Professional Services
230 East Ohio St., Suite 500
Chicago, IL 60611
Email: ihe@himss.org

1.7 Copyright Permission
Health Level Seven, Inc., has granted permission to the IHE to reproduce tables from the HL7
standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All rights
reserved.
Material drawn from these documents is credited where used.

__________________________________________________________________________
6
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

230

2

Conventions

This document has adopted the following conventions for representing the framework concepts
and specifying how the standards upon which the IHE IT Infrastructure Technical Framework isbased should be applied.

2.1 The Generic IHE Transaction Model
235

240

Transaction descriptions are provided in Section 3. In each transaction description, the actors, theroles they play, and the transactions between them are presented as use cases.
The generic IHE transaction description includes the following components:• Scope: a brief description of the transaction.
• Use case roles: textual definitions of the actors and their roles, with a simple diagram
relating them, e.g.:

Actor

Actor

Transaction

•
•
245

Referenced Standards: the standards (stating the specific parts, chapters or sections
thereof) to be used for the transaction.
Interaction Diagram: a graphical depiction of the actors and messages that support thetransaction, with related processing within an Actor shown as a rectangle and time
progressing downward, similar to:__________________________________________________________________________
7
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Actor

Actor

Actor

MSG1
MSG2
MSG3

250

•
255

The interaction diagrams used in the IHE IT Infrastructure Technical Framework aremodeled after those described in Grady Booch, James Rumbaugh, and Ivar Jacobson, The
Unified Modeling Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment
messages are often omitted from the diagrams for brevity. One or more messages may berequired to satisfy a transaction. Each message is represented as an arrow starting fromthe Actor initiating the message.
Message definitions: descriptions of each message involved in the transaction, the events
that trigger the message, its semantics, and the actions that the message triggers in thereceiver.

2.2 HL7 Profiling Conventions
See Appendix C in this volume for the HL7 profiling conventions as well as the networking
implementation guidelines.
260

2.3 Use of Coded Entities and Coding Schemes265

IHE does not produce, maintain or otherwise specify a coding scheme or other resource forcontrolled terminology (coded entities). Where applicable, coding schemes required by the HL7
and DICOM standards take precedence. In the cases where such resources are not explicitly
identified by standards, implementations may utilize any resource (including proprietary or local)
provided any licensing/copyright requirements are satisfied.

__________________________________________________________________________
8
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3 IHE Transactions
This section defines each IHE transaction in detail, specifying the standards used, theinformation transferred, and the conditions under which the transaction is required or optional.

__________________________________________________________________________
9
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

270

3.1 Maintain Time
This section corresponds to Transaction ITI-1 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-1 is used by the Time Server and Time Client actors.
3.1.1 Scope
This transaction is used to synchronize time among multiple systems.

275

3.1.2 Use Case Roles
Time Server

Time Client

Maintain Time

Actor: Time Server
Role: Responds to NTP time service queries.
Actor: Time Client
280

Role: Uses NTP or SNTP time service responses to maintain synchronization with Time Servers
and maintain the local system clock.
3.1.3 Referenced Standard
NTP

Network Time Protocol Version 3. RFC1305

SNTP

Simple Network Time Protocol (SNTP) RFC2030__________________________________________________________________________
10
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
285

3.1.4 Interaction Diagram
Time Server

Time Client

NTP Time QueryNTP Time Response

Figure 3.1.4-1. Maintain Time Messages

3.1.4.1 Maintain Time
290

295

The NTP transactions are described in detail in RFC1305. There is also extensive documentationon the transactions and recommendations on configurations and setup provided at
http://www.ntp.org. Rather than reproduce all of that material as part of this Framework, readers
are strongly encouraged to explore that site. The most common mode is the query-response modethat is described below. For other forms, see RFC1305 and the material on http://www.ntp.org.
The Time Server shall support NTP (which implicitly means that SNTP clients are also
supported). Secure NTP may also be supported. The Time Client shall utilize NTP when it isgrouped with a Time Server, or when high accuracy is required. For ungrouped Time Clientswith 1 second accuracy requirements, SNTP may be useable. Time Clients may also support
Secure NTP.
Table 3.1.4-1 Permissible Protocol Selections

300

ProtocolTime Server

SNTPTime Client groupedwith a Time Server

Time Client (1saccuracy)

Time Client (Highaccuracy)

Must Support prohibited

permitted

prohibited

NTP

Must Support Must Support

permitted

permitted

Secure NTP

Optional

Optional

Optional

Optional

3.1.4.1.1 Trigger Events
In a query-response mode the Time Client queries the Time Server and receives a response. Thistransaction includes timing estimation of network delays.

__________________________________________________________________________
11
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.1.4.1.2 Message Semantics
305

310

The Time Client uses the Network Time Protocol (NTP) to synchronize its time with the Time
Server. NTP clients can be configured to use a specific NTP server at a specific IP address, toobtain the NTP server address automatically from DHCP, and/or to discover the NTP server
address automatically. Time clients shall support at least manual configuration and may support
all three modes. Time Clients usually maintain time synchronization by adjusting the system
clock, so that applications continue to use the system clock facilities. The specific precision ofsynchronization depends upon the requirements of specific actors.
Implementations must support a time synchronization accuracy of at least one second.

315

320

325

There is a Simple Network Time Protocol (SNTP) RFC2030 defined that can provide one second
accuracy for Time Clients. It uses the exact same protocol as NTP, but does not include themeasurement data used by the NTP high-accuracy statistical estimation algorithm. It has a lower
implementation cost because it omits the measurements and statistical estimation needed toachieve higher accuracy. This omission of the statistical estimation makes it unsuitable for use
when grouped with a Time Server. Its use is permitted for Time Clients that are not grouped witha Time Server and that do not need better synchronization for another reason.
Note:

The Time Client Actor can often be implemented by using components provided by operating systems.
Some offer only SNTP while others offer the choice of SNTP or NTP clients.

The use of Secure NTP is not required. The risk of subversion of the time base to conceal
penetration is considered very low, and the operational costs of maintaining Secure NTP too highin most environments.
3.1.4.1.3 Expected Actions

330

The Time Server and Time Client will maintain synchronization to UTC. The Time Client
maintains a statistical estimation process utilizing time estimates and network delay estimatesfrom one or more Time Servers. This statistical estimation process yields a time estimate that isused to continually adjust the system clock.
Note:

335

The relationship between the local reported time, UTC, and battery-backed clock is often a source ofconfusion. Different hardware and operating systems have different configuration requirements. Theseshould be clearly documented and made clear in the user interface so that field service and operational
staff do not introduce errors.

__________________________________________________________________________
12
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.2 Get User Authentication

340

This section corresponds to Transaction ITI-2 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-2 is used by the Client Authentication Agent and Kerberos Authentication
Server actors.
3.2.1 Scope

345

This transaction is used to authenticate an enterprise-wide user identity. A challenge-response
method verifies that the user knows the correct password. Once the user is authenticated, theKerberos Authentication Server sends a Ticket Granting Ticket (TGT) to the Client
Authentication Agent to permit optimization of subsequent interactions. The TGT acts as a
substitute for repeated login/password type activity.
This transaction is equivalent to what is called the “Authentication Service” in RFC1510.
3.2.2 Use Case Roles
Client Authentication
Agent

Kerberos
Authentication Server

Kerberos User
Authentication

350

Actor: Client Authentication Agent.
Role: Communicates authentication information to the Kerberos Authentication Server, receives
a TGT, and performs internal TGT management.
Actor: Kerberos Authentication Server. In RFC1510 this is called a Key Distribution Center(KDC).

355

Role: Verifies the authentication information, creates a TGT, and sends it to the Client
Authentication Agent.
3.2.3 Referenced Standard
RFC1510The Kerberos Network Authentication Service (V5)

3.2.4 Interaction Diagram
360

The Client Authentication Agent communicates to the Kerberos Authentication Server a
Kerberos Authentication Service Request (KRB_AS_REQ). This message identifies the user, the__________________________________________________________________________
13
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
name of the ticket-granting service and authentication data. The authentication data is usually atimestamp encrypted with the user’s long-term key. (See RFC1510 for the exception cases.)Client Authentication
Agent

Kerberos
Authentication Server
KRB_AS_REQ

Validate request,
generate TGT,
send response
KRB_AS_REP

365

Figure 3.2.4-1. Get User Authentication Messages

3.2.4.1 Get User Authentication (Request/Response)
3.2.4.1.1 Trigger Events
The Kerberos User Authentication transactions normally take place:
370

375

1.

Upon login or session start for a new user, and2.

Shortly before expiration of a TGT. TGT timeouts are selected to minimize the need forthis transaction, but they may expire prior to user logout/ session complete.

When the Client Authentication Agent supports the Authentication for User Context Option, theClient Authentication Agent shall resolve any Context Manager interface issues before starting
the user authentication. For instance the Client Authentication Agent needs to be sure that it will
be accepted by the Context Manager as the one and only user authenticator in the context for thisuser session. Similar issues may apply with non-IHE uses of CCOW.
3.2.4.1.2 Message Semantics

380

The Client Authentication Agent shall support use of this transaction with the Kerberos user
name/password system defined in RFC 1510. The username and password shall consist of the 94
printable characters specified in the International Reference Version of ISO-646/ECMA-6 (aka
U.S. ASCII).

__________________________________________________________________________
14
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.2.4.1.3 Expected Actions
385

390

The Client Authentication Agent shall perform TGT management, so that subsequent activities
can re-use TGTs from a credentials cache. The Client Authentication Agent shall ensure that auser has access to only to his or her own tickets (both TGT and Service Tickets). This is mostoften done by clearing the credentials cache upon user logout or session completion.
When the Client Authentication Agent supports the Authenticator for User Context Option, theagent shall perform the Change Context Transaction to set the user identity in the context
managed by the Context Manager Actor.
When the user session ends, the Client Authentication Agent shall remove the user credentials
from its cache. If it supports the Authenticator for User Context Option, the agent shall performthe Change Context Transaction to set the user to NULL prior to removing the user credentials.
3.2.5 Extended Authentication Methods

395

The Kerberos challenge-response system used by this Integration Profile can be used to verify
users by means of many authentication mechanisms. The mechanism specified in this profile is
the Kerberos username and password system. Other methods such as smart cards and biometrics
have also been documented but not standardized. (See ITI TF-1: Appendix D for a discussion ofalternate authentication mechanisms.)__________________________________________________________________________
15
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

400

3.3 Get Service Ticket
This section corresponds to Transaction ITI-3 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-3 is used by the Client Authentication Agent and Kerberos Authentication
Server Actors.
3.3.1 Scope

405

The Client Authentication Agent uses this transaction to obtain the service ticket that will be sent
to a Kerberized Server to authenticate this user to a Kerberized Server.
3.3.2 Use Case Roles
Client Authentication
Agent

Kerberos
Authentication Server

Kerberos User
Authentication

Actor: Client Authentication Agent.
410

Role: Client communicates authentication information to the Kerberos Authentication Server,receives a Service Ticket, and performs internal ticket management.
Actor: Kerberos Authentication Server. In RFC1510 this is called a Key Distribution Center(KDC).

415

Role: Verifies the authentication information, creates a ticket, and sends it to the Client
Authentication Agent Actor.
3.3.3 Referenced Standard
RFC1510The Kerberos Network Authentication Service (V5)__________________________________________________________________________
16
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.3.4 Interaction Diagram
Client Authentication Agent

Kerberos Authentication
ServerKRB_TGS_REQ

KRB_TGS_REP

420

Utilize service
requestinformation and
TGT to generate
a service ticket
authenticating theuser to therequested service

3.3.4.1 Kerberos Service Ticket
3.3.4.1.1 Trigger Events
A service ticket is requested prior to communicating with a Kerberized Server. This ticket will be
provided to that service as part of the Kerberized communication process.
3.3.4.1.2 Message Semantics

425

The Client Authentication Agent Actor requests credentials for a service by sending the Kerberos
Authentication Server a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ). Thismessage includes the user’s name, an authenticator encrypted with the user’s logon session key,
the TGT obtained in the Get User Authentication Transaction, and the name of the service forwhich the user wants a ticket.

430

When the Kerberos Authentication Server receives KRB_TGS_REQ, it decrypts the TGT with
its own secret key, extracting the logon session key. It uses the logon session key to decrypt theauthenticator and evaluates that. If the authenticator passes the test, the Kerberos Authentication
Server extracts the authorization data from the TGT and invents a session key for the client toshare with the Kerberized Server Actor that supports the service. The Kerberos Authentication
Server encrypts one copy of this session key with the user’s logon session key. It embeds anothercopy of the session key in a ticket, along with the authorization data, and encrypts this ticket withthe service’s long-term key. The Kerberos Authentication Server then sends these credentials
back to the client in a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).

435

There are no IHE specific extensions or modifications to the Kerberos messaging.
__________________________________________________________________________
17
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
440

3.3.4.1.3 Expected Actions
When the Client Authentication Agent receives the reply, it uses the logon session key to decrypt
the session key to use with the service, and stores the key in its credentials cache. Then it extracts
the ticket for the service and stores that in its cache.
The client shall maintain the ticket in the credentials cache for later use.

445

3.3.4.1.4 Service Registration
The Kerberized Communication services supported in an enterprise shall be registered on theKerberos Authentication Server according to the RFC1510 protocol specification used. The
registration of the service on the KDC is outside the scope of this profile.

__________________________________________________________________________
18
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.4 Kerberized Communication
450

This section corresponds to Transaction ITI-4 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-4 is used by the Client Authentication Agent and Kerberized Server Actors.
3.4.1 Scope
This section specifies the details of the association of a Kerberos user identity with a session fora session oriented protocol, or a transaction for a transaction oriented protocol.

455

3.4.2 Use Case Roles
Kerberized Server

Client Authentication
Agent

Transaction Name

Actor: Client Authentication Agent
Role: Provides appropriate ticket as part of the connection or session management for anotherprotocol.
460

Actor: Kerberized Server
Role: Accepts and verifies the ticket to perform user-identity-related services as part of theconnection or session management for another protocol.
3.4.3 Referenced Standard
RFC1510The Kerberos Network Authentication Service (V5)__________________________________________________________________________
19
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
465

3.4.4 Interaction Diagram
Kerberized Server

Client Authentication AgentKRB_AP_REQ

KRB_AP_REP

Figure 3.4-1 Kerberized Communications

3.4.4.1 Kerberized Communications
470

The sequence diagram above describes information flow that can be encapsulated in a variety ofdifferent protocol startup sequences. The specific details for this encapsulation are defined aspart of the definition of Kerberizing a specific kind of communication protocol.
3.4.4.1.1 Trigger Events
This occurs at the beginning of a session or as part of each session-less transaction.
3.4.4.1.2 Message Semantics

475

480

The Client Authentication Agent Actor requests service from a Kerberized Server by sending theserver a Kerberos Application Request (KRB_AP_REQ). This message contains an authenticator
encrypted with the session key, the ticket obtained in the Get Service Ticket Transaction, and aflag indicating whether the client wants mutual authentication. (The setting of this flag is either
specified by the rules of the Kerberized communications, or is an option of the specificKerberized protocol.)485

The Kerberized Server receives KRB_AP_REQ, decrypts the ticket, and extracts theauthorization data and the session key. The server uses the session key to decrypt theauthenticator and then evaluates the timestamp inside. If the authenticator passes the test, theserver looks for a mutual authentication flag in the client’s request for protocols that support
mutual authentication. If the flag is set, the server uses the session key to encrypt the time__________________________________________________________________________
20
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
supplied by the Client Authentication Actor and returns the result in a Kerberos Application
Reply (KRB_AP_REP).
The actual encoding and exchange of the KRB_AP_REQ and KRB_AP_REP are defined as partof the definition of the specific Kerberized protocol.
490

3.4.4.1.3 Expected Actions
When the Client Authentication Actor receives KRB_AP_REP, it decrypts the server’s
authenticator with the session key it shares with the server and compares the time returned by theservice with the time in the client’s original authenticator. If the times match, the client knowsthat the service is genuine, and the connection proceeds.

495

If no mutual authentication is requested, the other IHE actors proceed with their IHE transactions.
These transactions are identified as being requested by the authenticated user. The other actors
will utilize this information for other purposes, such as confirming user authorization or logging
user actions into audit trails.
3.4.4.2 Kerberized HTTP

500

Kerberized HTTP shall use SPNEGO-HTTP(see http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-04.txt)
Note:

505

At the time of publication there were no Kerberized HTTP normative standards. There are three relatively
well-documented non-normative specifications. In addition, there are commercial and open source
implementations of this specification for web and application servers. It was decided to use theKerberized HTTP specification that is implemented by Microsoft Internet Explorer (MSIE) because many
healthcare desktops use MSIE.

The following Figure shows a typical message sequence for Kerberized HTTP.

__________________________________________________________________________
21
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Client Authentication
Agent

Kerberos
Authentication Server

HTTP Kerberized
ServerStart HTTP
sessionHTTP Get – no authentication
return 401 (WWW-Authenticate: Negotiate)

Internal Ticket
Management

Get Kerberos Service
Ticket [ITI-3]

HTTP Get - Kerberized Communication [ITI-4]
Validate
Ticket510

Figure 3.4-2 Kerberized HTTP

There is also documentation on the transactions, configuration, and troubleshooting these
configurations. Rather than reproduce all of that material as part of this Framework, readers arestrongly encouraged to explore these references.
(See http://support.microsoft.com/default.aspx?scid=kb;ben-us;326985)
515

3.4.4.2.1 Trigger Events
This transaction occurs at the beginning of each HTTP transaction.
Note:

520

When the workstation is properly configured utilizing Microsoft Internet Explorer these transactions aretransparent. A prompt for username, password, and domain is an indication of an improperly configured
component.

3.4.4.2.2 Message Semantics
This IHE profile recognizes that the SPNEGO-HTTP method allows the client side to return
Kerberos credentials or NTLM credentials. This IHE profile thus restricts the transactions to theKerberized credentials.

__________________________________________________________________________
22
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
525

3.4.4.3 Kerberized DICOM
The Kerberization of DICOM has been proposed and is under development. There is not afinished standard at this time.
3.4.4.4 Kerberized HL7

530

The Kerberization of HL7 has been proposed and is under development. There is not a finishedstandard at this time.

__________________________________________________________________________
23
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.5 Join Context
This section corresponds to Transaction ITI-5 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-5 is used by the Patient Context Participant, User Context Participant, Client
Authentication Agent and Context Manager Actors.
535

3.5.1 Scope
Any of the context participant actors using this Transaction (Patient Context Participant, User
Context Participant, and Client Authentication Agent) may locate and join a context management
session specific to the workstation on which the instigating user is interacting.

545

A Context Participant Actor shall first locate the instance of the Context Manager Actor via
technology specific methods as defined in the HL7 Context Management “CCOW” technology
mapping documents. Once the context manager reference is returned, the Context Participant
Actor issues a join method to the context manager, which returns a unique participant identifier.
User Context Participant and Client Authentication Agent shall use this identifier along with ashared secret as inputs to a two stage secure binding process, which results in the exchange of
public keys between the two actors.

550

If an implementation groups two or more context participant actors, this Transaction shall be
performed only once on a launch of an application in which those actors are grouped. All
grouped actors share the same common context. If at least one of the grouped actors is a User
Context Participant or a Client Authentication Agent, this transaction shall include the two-stage
secure binding process.

540

555

The semantics of the methods used in this Transaction are defined in the documents HL7
Context Management “CCOW” Standard: Component Technology Mapping: ActiveX or HL7
Context Management “CCOW” Standard: Component Technology Mapping: Web. A Context
Participant Actor can implement either technology. The Context Manager Actor shall support
both technologies in order to interoperate with joining participants implementing the technologyof their choice.

__________________________________________________________________________
24
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.5.2 Use Case Roles
Patient Context
Participant Actor

User Context
Participant Actor

ClientAuthentication
Agent

Join Context

Context
Manager Actor

560

Actor: Patient Context Participant
Role: Initiates establishment of context session connection with the Context Manager so as to beable to change and follow Patient Subject changes in the common context.
Actor: User Context Participant

565

Role: Initiates establishment of a secure context session connection with the Context Manager
so as to be able to follow User Subject changes in the common context.
Actor: Client Authentication Agent
Role: Initiates establishment of a secure context session connection with the Context Manager
so as to be able to perform User Subject changes in the common context.
Actor: Context Manager

570

Role: Responds to the request to join the context session from the context participant.
3.5.3 Referenced Standard
HL7 Context Management “CCOW” Standard, Version 1.4:
Technology and Subject Independent Architecture
Component Technology Mapping: ActiveX

575

Component Technology Mapping: Web__________________________________________________________________________
25
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.5.4 Interaction Diagrams
The Join Context Transaction involves a different set of messages depending on the type ofsubjects the context participant is interested in, either Patient subject, User subject or both Patientand User subjects.
Patient Context
Participant Actor

Context Manager
Actor

Locate Context Manager
JoinCommonContext

580
Figure 3.5-1 Patient Subject Join Context Interaction Diagram
Client Authentication
Agent Actor

Context
Manager
Actor

User Context
Participant
Actor

Locate Context Manager
JoinCommonContext
InitializeBinding
FinalizeBinding

Locate Context Manager
JoinCommonContext
InitializeBinding
FinalizeBinding

Figure 3.5-2 User Subject Join Context Interaction Diagram585

3.5.4.1 Join Context – Locate Method
To join the common context upon launch of an application, it is necessary for the context
participant to locate the Context Manager that supports context management for the user’s__________________________________________________________________________
26
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
workstation. This is achieved by the invocation of the Locate method in accordance withspecifications of the HL7 Context Management “CCOW” Standard.
590

3.5.4.1.1 Trigger Events
The Locate method is triggered by the user launch of an application that contains one of thefollowing actors: Patient Context Participant, User Context Participant or Client Authentication
Agent.
3.5.4.1.2 Message Semantics

595

600

In a Web/HTTP implementation, Locate is defined as a method of theContextManagementRegistry interface. The IHE Context Manager Actor provides this interface
for the context participants to call upon, and thus implements the CCOW defined Context
Management Registry, which is used to locate the appropriate instance of the Context Manager.
In an ActiveX implementation, the context participants determine the location of the instance ofContext Manager from the operating system registry.
3.5.4.1.3 Expected Actions

605

The Locate method invocation is specific to the Web technology mapping. In this case, theContent Manager shall return the valid URL of the Context Manager instance or a CCOW
defined UnableToLocate exception. Refer to the HL7 Context Management “CCOW” Standard:
Component Technology Mapping: Web/HTTP, Chapter 3 for the details of the response
specifications.
3.5.4.2 Join Context – JoinCommonContext Method
The JoinCommonContext method is invoked by the one of the following actors: Patient Context
Participant, User Context Participant or Client Authentication Agent.

610

3.5.4.2.1 Trigger Events
The JoinCommonContext method is triggered by the valid response of the Locate method with areference to the context manager.
3.5.4.2.2 Message Semantics

615

JoinCommonContext is defined as a method on the ContextManager interface. It shall be
invoked by a Context Participant Actor to complete the establishment of the secure context
session. A Context Participant Actor shall provide parameters for this method as specified in the
CCOW Standard.

__________________________________________________________________________
27
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

620

Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.6.3, for a detailed description of theparameters associated with this method.
3.5.4.2.3 Expected Actions
If the JoinCommonContext method is successful, the Context Manager shall issue the invoking
Actor a unique context participant identifier which is to be used until the context session is
terminated by either a Context Participant Actor or the Context Manager Actor.

625

If the method fails a descriptive CCOW exception will be returned.

630

After the context session is established, the Context Manager Actor shall periodically verify
availability of a Context Participant Actor by invoking the Ping method on theContextParticipant interface as specified in the CCOW Standard. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,
Section 17.3.7.6, for a detailed description of the parameters associated with this method.

635

Should the Context Manager Actor need to terminate an established context session (for example,
in a case of restart), it shall inform the context participants of such action by invocation of theCommonContextTerminated method on the ContextParticipant interface as specified in the
CCOW Standard. Refer to the HL7 Context Management “CCOW” Standard: Technology and
Subject-Independent Architecture document, Section 17.3.7.5, for a detailed description of theparameters associated with this method.
The success of this method signifies completion of the Join Context Transaction for the actors
intending to participate only in the patient context.
3.5.4.3 Join Context – InitializeBinding Method

640

The InitializeBinding method is invoked by the one of the following actors intending toparticipate in a user context: User Context Participant or Client Authentication Agent.
3.5.4.3.1 Trigger EventsThe InitializeBinding method is triggered by the valid response of the JoinContext method.
3.5.4.3.2 Message Semantics

645

650

InitializeBinding is defined as a method on the SecureBinding interface and allows a Context
Participant Actor and Context Manager to verify each other’s identity and supply the Context
Manager’s public key to the requesting context participant.
In the invocation of this method, context participant supplies the application identification and adigest produced from that identification concatenated with a shared secret. The shared secret is
known in CCOW terms as an applications passcode. The passcode shall be site configurable.
__________________________________________________________________________
28
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.12.2, for a description of the parameters
associated with this method, to be issued by the Context Participant Actor.
3.5.4.3.3 Expected Actions
655

Performing the InitializeBinding method, the Context Manager verifies the identity of arequesting context participant and responds with the message containing its public key. Refer tothe HL7 Context Management “CCOW” Standard: Technology and Subject-Independent
Architecture document, Section 17.3.12.2, for the specifics of the response formation.
3.5.4.4 Join Context – FinalizeBinding Method

660

The FinalizeBinding method is invoked by the one of the following actors: User Context
Participant or Client Authentication Agent.
3.5.4.4.1 Trigger Events
The FinalizeBinding method is triggered by the valid response of the InitializeBinding method.
3.5.4.4.2 Message Semantics

665

FinalizeBinding is defined as a method on the SecureBinding interface and allows a Context
Participant Actor to supply the Context Manager with its public key.
In the invocation of this method, the context participant supplies its public key and a digest
digitally signed with its private key.

670

Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.12.3, for a description of the parameters
associated with this method, to be issued by the Context Participant Actor.
3.5.4.4.3 Expected Actions

675

Performing the FinalizeBinding method, the Context Manager verifies the identity of arequesting context participant and accepts or rejects its public key. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,
Section 17.3.12.3, for the specifics of the response formation.
The success of this method signifies completion of the Join Context Transaction for the actors
intending to participate in the user context.

__________________________________________________________________________
29
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.6 Change Context
680

This section corresponds to Transaction ITI-6 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-6 is used by the Context Participant and Context Manager actors.
3.6.1 Scope

685

690

695

700

705

710

This transaction allows for an application supporting the Context Participant Actor to change thevalues for one or more context subjects, forcing other Context Participant actors to synchronize
based on the new context values.
The Change Context Transaction is composed of multiple methods as defined by the HL7
Context Management “CCOW” Standard. There are two key characteristics to this transaction.
The first is that the transaction has multiple phases consisting of instigating the change,
surveying the other participants, and finally publishing the decision as to whether the context
changed or not. The second characteristic is that the context change involves a specific subject.
For the Patient Context Participant Actor the subject being changed is the patient subject. For the
Client Authentication Agent Actor the subject being changed is the user subject. Applications
that implement only the Patient Context Participant Actor shall not expect the user subject to be
set in context.
The semantics of the methods used are defined in the documents HL7 Context Management“CCOW” Standard: Component Technology Mapping: ActiveX or HL7 Context Management“CCOW” Standard: Component Technology Mapping: Web, in conjunction with the HL7
Context Management “CCOW” Standard: Subject Data Definitions document. The Context
Participant Actor can choose the technology implementation it wishes to implement. The
Context Manager Actor must support both technology implementations in order to accommodate
whichever implementation a participant ends up choosing.
In the case where Patient Context Participant Actors use identifiers from different patient
identifier domains the Context Manager Actor shall be grouped with the Patient Identifier Crossreference Consumer Actor and the corresponding PIX Query Transaction as defined in ITI TF-2:
3.9 to retrieve all identifiers the patient is known by. The IHE Context Manager Actor
encompasses more than a CCOW context manager function. See ITI TF-2: Appendix D for acomplete discussion of the grouping of these two actors.
The CCOW architecture is defined as a set of components that implement defined interfaces andtheir detailed methods as specified in the HL7 Context Management “CCOW” Standard:
Technology Independent Architecture document. This structure is different than the traditional
IHE network transaction. As is depicted in the interaction diagram in Section 3.6.4, the IHE
Change Context Transaction is composed of multiple CCOW-defined methods.

__________________________________________________________________________
30
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.6.2 Use Case Roles
Patient Context
Participant Actor

ClientAuthentication
Agent Actor

Change Context

Context
Manager Actor

715
Actor: Client Authentication Agent
Role: Initiates context change for user subject by supplying new context values.
Actor: Patient Context Participant
720

Role: Initiates context change for patient subject by supplying new context values. After
receiving the context survey results it finalizes context change decision. Applications containing
this Actor without a patient lookup function would not use this transaction.
Actor: Context Manager
Role: Manages Change Context Transaction lifecycle.
3.6.3 Referenced Standard

725

HL7 Context Management “CCOW” Standard, Version 1.4:
Technology and Subject Independent Architecture
Component Technology Mapping: ActiveX
Component Technology Mapping: Web
Subject Data Definitions__________________________________________________________________________
31
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
730

3.6.4 Interaction Diagram
Patient Context
Participant Actor
or Client Authentication
Agent

Context
Manager
Actor
StartContextChanges
SetItemValues

EndContextChanges Request
EndContextChanges Response

PublishChangesDecision

Figure 3.6-1 Change Context sequence

3.6.4.1 Context Change – StartContextChanges Method
3.6.4.1.1 Trigger Events
735

This method is triggered by a specific user gesture. The user gesture that triggers this transaction
in for the Patient Context Participant Actor is one of selecting a patient. The user gesture thattriggers this transaction for the Client Authentication Agent Actor is authentication of a user.
3.6.4.1.2 Message Semantics

740

745

The Patient Context Participant and/or the Client Authentication Agent Actor will issue aStartContextChanges method of the ContextManager interface. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,
Section 17.3.6.5, for a more detailed description of the parameters associated with this method.
IHE specifies no restrictions or extensions to the CCOW definition of the StartContextChanges
method.
3.6.4.1.3 Expected Actions
The Context Manager Actor returns the pending context coupon. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,__________________________________________________________________________
32
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

750

Section 17.3.6.5, for a more detailed description of the response issued by the Context Manager
Actor. IHE specifies no restrictions or extensions to the CCOW definition of theStartContextChanges method.
3.6.4.2 Change Context – SetItemValues Method
3.6.4.2.1 Trigger Events
The SetItemValues method is triggered by the return of a context coupon in response to theStartContextChanges method.

755

3.6.4.2.2 Message Semantics
3.6.4.2.2.1 Patient Context Participant Actor support for CCOW Patient Subject

760

765

The Patient Context Participant Actor issues an invocation of the SetItemValues method of theContextData interface to the Context Manager Actor. Refer to the HL7 Context Management“CCOW” Standard: Technology and Subject-Independent Architecture document, Section
17.3.4.4, for a more detailed description of the parameters associated with this method, to beissued by the Patient Context Participant Actor. The Patient Context Participant Actor supports
synchronization around the CCOW patient subject. A Patient Context Participant Actor
performing a Change Context Transaction shall set the Patient.Id.IdList.1 patient identifier item.
All other patient identifier items as defined by the CCOW standard and shown in Table 3.6.4.2-1
Patient Subject Identifier Items, are subject to deprecation in future releases of the standard.
Table 3.6.4.2-1 Patient Subject Identifier Items
Patient Subject
Identifier Item Name

HL7 Meaning

HL7
Data
Type

HL7 Semantic Constraints on
ValuesCase
Sensitive

Patient.Id.MRN.Suffix

Patient’s medical
record number,per PID-2

ST

HL7 Table 0203Identifier Type = MR

No

Patient.Id.MPI

Patient’s identifierin the “Master
Patient Index”,
per PID-2

ST

HL7 Table 0203Identifier Type = PT
or PI (as agreed upon by context
sharing systems) and Assigning
Authority represents the MPI system

No

Patient.Id.NationalIdNumber

Patient’s national
identifier number,per PID-2

ST

HL7 Table 0203Identifier Type = PT
and Assigning Authority represents
agreed-upon National Authority

No

Patient.Id.IdList

A list of patient
identifiers for apatient, per PID-3

CX

May be a repeating set of CX item
values each of which contains an
identifier that denotes the same patientNo

Adapted from the HL7 Context Management “CCOW” Standard, version 1.4__________________________________________________________________________
33
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

770

775

The Patient.Id.IdList.1 item shall populate component 1, (the patient identifier), and either subcomponent 1, (namespace ID), of component 4, (the assigning authority), of the CX data item.
This is to be consistent with the requirements for the patient identifier as defined in the PIXQuery transaction documented in ITI TF-2: 3.9.4.1.2.2.
The Patient Context Participant Actor should use the SetItemValues associated with theContextData interface, as defined in Sections 17.3.4.4 and 17.3.4.5 respectively of the HL7
Context Management “CCOW” Standard: Technology and Subject-Independent Architecture
document.
3.6.4.2.2.2 Client Authentication Agent Actor support for CCOW User Subject
•

780

785

The Client Authentication Agent Actor supports synchronization around the CCOW user subject. A
Client Authentication Agent Actor performing a Change Context Transaction shall set theUser.Id.Logon.Suffix identifier item, where the Suffix is assigned as Kerberos. This would make theitem name to be used by the Client Authentication Agent Actor User.Id.Logon.Kerberos. The value ofUser.Id.Kerberos shall be the username@realm.

The Client Authentication Agent Actor shall use the SetItemValues associated with
SecureContextData interface as defined in Section 17.3.13.3 of the HL7 Context Management“CCOW” Standard: Technology and Subject-Independent Architecture document.
3.6.4.2.3 Expected Actions

790

795

The Context Manager Actor returns an acknowledgement of the changed data. IHE specifies norestrictions or extensions to the CCOW definition of the SetItemValues method. Refer to the
HL7 Context Management “CCOW” Standard: Technology and Subject-Independent
Architecture document, Section 17.3.4.4, for a more detailed description of the response issued
by the Context Manager Actor to the Patient Context Participant Actor. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,
Section 17.3.13.3, for a more detailed description of the response issued by the Context Manager
Actor to the Client Authentication Agent Actor.
3.6.4.3 Context Change – EndContextChanges
3.6.4.3.1 Trigger EventsThe EndContextChanges method is triggered by the completion of the SetItemValues method.
3.6.4.3.2 Message Semantics

800

The Patient Context Participant and Client Authentication Agent Actors issue an
EndContextChanges method of the ContextManager interface to the Context Manager Actor.
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.6.6, for a description of the parameters__________________________________________________________________________
34
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
associated with this method. IHE specifies no restrictions or extensions to the CCOW definitionof the EndContextChanges method.
805

3.6.4.3.3 Expected Actions
The EndContextChanges method triggers the ContextChangesPending method as defined in ITI
TF-2: 3.13.4.1. The Context Manager Actor returns the results of the context survey to theinstigating Patient Context Participant or Client Authentication Agent Actor.

810

If the instigating Patient Context Participant or Client Authentication Agent Actor receives aunanimous acceptance in the survey results, then it triggers an accept in the
PublishChangesDecision method.

820

If the instigating Patient Context Participant or Client Authentication Agent Actor receives one
or more Conditional Accept responses in the survey results, then the application containing theActor must ask the user to continue, suspend context participation, or cancel the pending context
change transaction. The user’s decision to continue will result in the context change being
accepted. The user’s decision to suspend context participation will cancel the change transaction
and allow the user to temporarily use the application without affecting the current context session.
The user’s decision to cancel will cancel the pending context change transaction. At this point
the Patient Context Participant or Client Authentication Agent Actor triggers the
PublishChangesDecision with the user’s response.

825

In the event a participant application does not respond to the survey, after a configurable periodof time the Context Manager Actor will deem the application as “busy”. If the instigating
participant application receives one or more busy responses, it shall only present the suspend orcancel choices. This prevents an application from inadvertently becoming out of synch with thecontext, unbeknownst to the user.

830

Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.6.6, for a more detailed description of the
response issued by the Context Manager Actor and actions required by the Patient Context
Participant and or Client Authentication Agent Actors. IHE specifies no restrictions or
extensions to the CCOW definition of the EndContextChanges method.

815

3.6.4.4 Context Change – PublishChangesDecision
3.6.4.4.1 Trigger Events
The PublishChangesDecision method is triggered by the return of EndContextChanges method.
3.6.4.4.2 Message Semantics
835

The Patient Context Participant and Client Authentication Agent Actors shall issue either an
accept or cancel via the PublishChangesDecision method of the ContextManager interface to the__________________________________________________________________________
35
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

840

Context Manager Actor. Refer to the HL7 Context Management “CCOW” Standard: Technology
and Subject-Independent Architecture document, Section 17.3.6.8, for a more detailed
description of the parameters associated with this method. IHE specifies no restrictions or
extensions to the CCOW definition of the PublishChangesDecision method.
3.6.4.4.3 Expected Actions

845

When the PublishChangesDecision method is received by the Context Manager Actor it triggers
the ContextChangesAccepted or ContextChangesCancelled method as defined in ITI TF-2:
3.13.4.2 or ITI TF-2: 3.13.4.3 respectively. IHE specifies no restrictions or extensions to the
CCOW definition of the PublishChangesDecision method. Refer to the HL7 Context
Management “CCOW” Standard: Technology and Subject-Independent Architecture document,
Section 17.3.6.8, for a description of the response issued by the Context Manager Actor.

__________________________________________________________________________
36
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.7 Leave Context
850

This section corresponds to Transaction ITI-7 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-7 is used by the Patient Context Participant, User Context Participant, Client
Authentication Agent, and Context Manager Actors.
3.7.1 Scope

855

860

This transaction allows for an application supporting the Patient Context Participant, User
Context Participant, or Client Authentication Agent Actor to terminate participation in a context
management session in which it is participating.
A Context Participant Actor notifies the Context Manager Actor that is leaving the common
context. The semantics of the methods used are defined in the documents HL7 Context
Management “CCOW” Standard: Component Technology Mapping: ActiveX or HL7 Context
Management “CCOW” Standard: Component Technology Mapping: Web. The Context
Participant Actor can choose the technology implementation it wishes to implement. The
Context Manager Actor must support both technology implementations in order to accommodate
whichever implementation a joining participant ends up choosing.
3.7.2 Use Case Roles
Patient Context
Participant Actor

User Context
Participant Actor

ClientAuthentication
Agent Actor

Leave Context

User Context
Manager Actor

865

Actor: Patient Context Participant
Role: Initiates notification to the Context Manager that it will no longer be participating in thecontext management session.
Actor: User Context Participant

870

Role: Initiates notification to the Context Manager that it will no longer be participating in thecontext management session.
__________________________________________________________________________
37
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Actor: Client Authentication Agent
Role: Initiates notification to the Context Manager that it will no longer be participating in thecontext management session.
Actor: Context Manager
875

Role: Responds to the request to leave the context session from the context participant.
3.7.3 Referenced Standard
HL7 Context Management “CCOW” Standard, Version 1.4:
Technology and Subject Independent Architecture
Component Technology Mapping: ActiveX

880

Component Technology Mapping: Web
3.7.4 Interaction Diagram
Patient Context Participant Actor
or User Context Partcipant Actor
or Client Authentication Agent

Context
Manager
Actor

LeaveCommonContext

Figure 3.7-1 Leave Context Sequence

3.7.4.1 Leave Context – LeaveCommonContext Method885

3.7.4.1.1 Trigger Events
This transaction is triggered by the user closing an application that contains a Patient Context
Participant Actor, a User Context Participant Actor, or Client Authentication Agent Actor.
3.7.4.1.2 Message Semantics

890

LeaveContext is defined as a method on the ContextManager interface. It shall be invoked by aContext Participant Actor to announce its departure from the secure context session. A Context
Participant Actor shall provide parameters for this method as specified in the CCOW Standard.
__________________________________________________________________________
38
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.6.4, for a description of the parameters
associated with this method.
895

3.7.4.1.3 Expected Actions
The Context Manager Actor acknowledges the receipt of the notification. Refer to the HL7
Context Management “CCOW” Standard: Technology and Subject-Independent Architecture
document, Section 17.3.6.4, for a description of the response issued by the Context Manager
Actor.

900

The context participant is expected to dispose of all context manager interface references uponreceipt of the message reply. No further context change transactions will be processed by theContext Manager for this context participant.

__________________________________________________________________________
39
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.8 Patient Identity Feed
905

This section corresponds to Transaction ITI-8 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-8 is used by the Patient Identity Source, Patient Identifier Cross-referenceManager and Document Registry actors.
3.8.1 Scope

910

This transaction communicates patient information, including corroborating demographic data,
after a patient’s identity is established, modified or merged or after the key corroborating
demographic data has been modified.
3.8.2 Use Case Roles
Patient Identifier
Cross-reference
M anager

Patient Identity
SourceDocument
Registry

Patient Identity
Feed

Actor: Patient Identity Source
915

Role: Provides notification to the Patient Identifier Cross-reference Manager and Document
Registry for any patient identification related events including: creation, updates, merges, etc.
Actor: Patient Identifier Cross-reference Manager

920

Role: Serves a well-defined set of Patient Identification Domains. Based on information
provided in each Patient Identification Domain by a Patient Identification Source Actor, it
manages the cross-referencing of patient identifiers across Patient Identification Domains.
Actor: Document Registry
Role: Uses patient identifiers provided by Patient Identity Source to ensure that XDS
Documents metadata registered is associated with a known patient and updates patient identity indocument metadata by tracking identity change operations (e.g. merge).

925

3.8.3 Referenced Standards
HL7 Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration
HL7 version 2.3.1 was selected for this transaction for the following reasons:• It provides a broader potential base of Patient Identity Source Actors capable ofparticipating in the profiles associated with this transaction.
__________________________________________________________________________
40
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
930•

It allows existing ADT Actors from within IHE Radiology to participate as Patient
Identity Source Actors.

3.8.4 Interaction Diagram
Docu ment Regis try
orPatient Identifier
Cro ss-referen ce
M anager

Patient Id entity
So urce

A dmit/ Register or Update Patient: HL7 ADT^** - A0 1, A 04, A 05, A 08
Patient Identity M erge: HL7 ADT ^A40

Figure 3.8-1 Patient Identity Sequence935

3.8.4.1 Patient Identity Management – Admit/Register or Update Patient
3.8.4.1.1 Trigger Events

940

945

The following events from a Patient Identity Source Actor will trigger one of the Admit/Registeror Update messages:• A01 – Admission of an in-patient into a facility• A04 – Registration of an outpatient for a visit of the facility• A05 – Pre-admission of an in-patient (i.e., registration of patient information ahead of
actual admission).
Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger
the following Admit/Register or Update message:• A08 – Update Patient Information
The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic onmessages received from Patient Identity Source Actors. For a given Patient Identifier Domain
there shall be one and only one Patient Identity Source Actor, but a given Patient Identity Source
Actor may serve more than one Patient Identifier Domain.

950

3.8.4.1.2 Message Semantics
The Patient Identity Feed transaction is conducted by the HL7 ADT message, as defined in thesubsequent sections. The Patient Identity Source Actor shall generate the message whenever apatient is admitted, pre-admitted, or registered, or when some piece of patient demographic data__________________________________________________________________________
41
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

955

changes. Pre-admission of inpatients shall use the A05 trigger event. The segments of themessage listed below are required, and their detailed descriptions are provided in the following
subsections.
Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7
profiling are stated in Appendix C and C.1 in this Volume.

960

Required segments are defined below. Other segments are optional
Table 3.8-1 ADT Patient Administration Messages
ADT

Patient Administration Message

Chapter in
HL7 2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

PV1

Patient Visit

3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See Appendix C.1.3, “Acknowledgement Modes”, for definition anddiscussion of the ACK message.
965

970

This transaction does not require Patient Identity Source Actors to include any attributes notalready required by the corresponding HL7 message (as is described in the following sections).
This minimal set of requirements enables inclusion of the largest range of Patient Identity Source
Actor systems.
This transaction does place additional requirements on the Patient Identifier Cross-referenceManager and Document Registry Actors, requiring them to accept aset of HL7 attributes beyond
what is required by HL7. (See Section 3.8.4.1.3 for a description of these additional
requirements)..
3.8.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in Appendix C.1.2 “Message Control”.

975

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of ADT; the second component shall have values of A01, A04, A05 or A08 as appropriate.
The third component is optional; however, if present, it shall have a value of ADT_A01.
3.8.4.1.2.2 EVN Segment

980

The Patient Identity Source Actor is not required to send any attributes within the EVN segment
beyond what is specified in the HL7 standard. See Table C.1-4 in Appendix C.1.4 “Common
Segment Definitions” for the specification of this segment.

__________________________________________________________________________
42
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.8.4.1.2.3 PID Segment
The Patient Identity Source Actor is not required to send any attributes within the PID segment
beyond what is specified in the HL7 standard.
985

990

This message shall use the field PID-3 Patient Identifier List to convey the Patient ID uniquely
identifying the patient within a given Patient Identification Domain.
The Patient Identity Source Actor shall provide the patient identifier in the ID component (firstcomponent) of the PID-3 field (PID-3.1). If the Patient Identity Source Actor provides
component PID-3.4, Assigning Authority, then either the first subcomponent (namespace ID) or
the second and third subcomponents (universal ID and universal ID type) shall be populated. If
all three subcomponents are populated, the first subcomponent shall reference the same entity as
is referenced by the second and third components.
3.8.4.1.2.4 PV1 Segment

995

The Admit/ Register or Update Patient message is not required to include any attributes within
the PV1 segment beyond what is specified in the HL7 standard.
3.8.4.1.3 Expected Actions – Patient Identifier Cross-reference Manager

1000

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
PID segment as specified in Table 3.8-2. This is to ensure that the Patient Identifier Crossreference Manager can handle a sufficient set of corroborating information in order to perform its
cross-referencing function.
Table 3.8-2 IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

O

00104

Set ID - Patient ID

2

20

CX

O

00105

Patient ID

3

250

CX

R

00106

Patient Identifier List

4

20

CX

O

00107

Alternate Patient ID

5

250

XPN

R

00108

Patient Name

6

250

XPN

R+

00109

Mother’s Maiden Name

7

26

TS

R+

00110

Date/Time of Birth

8

1

IS

R+

00111

Administrative Sex

9

250

XPN

O

00112

Patient Alias

10

250

CE

O

00113

Race

11

250

XAD

R2

00114

Patient Address

12

4

IS

O

00115

County Code

13

250

XTN

R2

00116

Phone Number - Home

14

250

XTN

R2

00117

Phone Number - Business

0001
0005
0289

__________________________________________________________________________
43
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
TBL#

ITEM#

15

SEQ

250

LEN

CE

DT
O

OPT

0296

00118

Primary Language

16

250

CE

O

0002

00119

Marital Status

17

250

CE

O

0006

00120

Religion

18

250

CX

O

00121

Patient Account Number

19

16

ST

R2

00122

SSN Number – Patient

20

25

DLN

R2

00123

Driver's License Number - Patient

21

250

CX

O

00124

Mother's Identifier

22

250

CE

O

00125

Ethnic Group

23

250

ST

O

00126

Birth Place

24

1

ID

O

00127

Multiple Birth Indicator

25

2

NM

O

00128

Birth Order

26

250

CE

O

0171

00129

Citizenship

27

250

CE

O

0172

00130

Veterans Military Status

28

250

CE

O

0212

00739

Nationality

29

26

TS

O

00740

Patient Death Date and Time

30

1

ID

O

00741

Patient Death Indicator

0189
0136

0136

ELEMENT NAME

Adapted from the HL7 standard, Version 2.3.1
Note: This table reflects attributes required to be handled by the Patient Identifier Cross-reference Manager(receiver). It is likely that not all attributes marked as R2 or R+ above will be sent in some environments.

1005

1010

1015

If the PID-3.4 (assigning authority) component is not included in the message (as described in
Section 3.8.4.1.2.3) the Patient Identifier Cross-reference Manager shall fill PID-3.4 prior tostoring the ID information and performing its cross-referencing activities. The information filledby the Patient Identifier Cross-reference Manager is based on the configuration associating eachof the Patient Identity Source actors with the subcomponents of the correct assigning authority(namespace ID, UID and UID type). (See 3.8.4.1.3.1 below for a list of required Patient
Identifier Cross-reference Manager configuration parameters).
A single Patient Identity Source Actor can serve multiple Patient Identification domains as longas it explicitly provides a fully qualified assigning authority. The Patient Identifier Crossreference Manager Actor shall only recognize (by configuration) a single Patient Identity Source
Actor per domain. (See 3.8.4.1.3.1 below for a list of required Patient Identifier Cross-referenceManager configuration parameters).
The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient
Identifier Cross-reference Manager Actor, but its specification is beyond the scope of IHE.

1020

Once the Patient Identifier Cross-reference Manager has completed its cross-referencing function,
it shall make the newly cross-referenced identifiers available to PIX queries and send out
notification to any Patient Identifier Cross-reference Consumers that have been configured (as__________________________________________________________________________
44
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
being interested in receiving such notifications) using the PIX Update Notification transaction(see Section 3.10 for the details of that transaction).
3.8.4.1.3.1 Required Patient Identifier Cross-reference Manager Configuration
1025

1030

1035

1040

The following items are expected to be parameters that are configurable on the Patient Identifier
Cross-reference Manager Actor. For each Identification Domain included in the Identification
Cross-reference Domain managed by a Patient Identifier Cross-reference Manager Actor, thefollowing configuration information is needed:• Identifier of the Identification Domain itself. This identifier shall specify the 3components of the HL7 assigning authority (including the namespace ID and/or both theuniversal ID and universal ID type subcomponents) of the PID-3 field for theidentification domain/source.
• Patient Identity Source Actor for that domain. This is expected to be the MSH-3 Sending
Application field in the HL7 ADT message. (Alternative identification schemes might
include IP address of the Patient Identity Source Actor or Node Authentication if the
Basic Security Profile defined by IHE Radiology is used.)• Details about where in the HL7 ADT message (Identity Feed transaction) that the Source
Actor will provide the patient identifier for the domain (e.g., first component of the PID-3
field). If a Source Actor is managing multiple Patient Identifier Domains then the Source
Actor is required to include the assigning authority in its Identity Feed Transactions.
3.8.4.1.4 Expected Actions – Document Registry
The Document Registry shall be capable of accepting attributes in the PID segment as specified
in Table 3.8-2. The Patient Identity Feed transaction contains more than what the XDS
Document Registry needs for its operation.

1045

Table 3.8-2 IHE Profile - PID segment
SEQ
3

LEN
250

DT
CX

OPT

TBL#

R

ITEM#
00106

ELEMENT NAME
Patient Identifier List

Adapted from the HL7 standard, Version 2.3.1
Note: This table reflects only the attributes required to be handled by the Document Registry (receiver). Other
attributes of the PID Segment may be ignored.

1050

1055

If the PID-3.4 (assigning authority) component is not included, or subcomponents 2 and 3 (theuniversal ID and the universal ID Type of Assigning Authority) of PID-3.4 are not filled in themessage (as described in Section 3.8.4.1.2.3) the Document Registry shall fill subcomponents 2
and 3 of PID-3.4 prior to storing the patient identity in the registry. The assigning authority
information filled by the Document Registry is based on its configuration associating to each of
the Patient Identity Source actors, which shall include the universal ID and the universal ID Typeof the correct assigning authority. (See 3.8.4.1.4.1 below for a list of required Document Registry
configuration parameters).
__________________________________________________________________________
45
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1060

1065

A single Patient Identity Source Actor can serve multiple Patient Identification domains, andtherefore may include multiple patient identifiers in a message, as long as it explicitly specifies afully qualified assigning authority for each patient identifier. The Document Registry Actor shall
only recognize (by configuration) one single Patient Identity Source Actor per domain. (See
3.8.4.1.4.1 below for a list of required Document Registry configuration parameters).
The Document Registry shall store only the patient identifiers of the patient identification
domain designated by the Affinity Domain for document sharing in the registry. Patient
identifiers of other patient identification domains (assigning authorities), if present in a received
message, shall be ignored.
3.8.4.1.4.1 Required Document Registry Configuration

1070

The following items are expected to be parameters that are configurable on the Document
Registry Actor:• Identifier of the Patient Identification Domain itself. This identifier shall be specified with 2
components of the HL7 assigning authority (date type HD): universal ID and universal ID
type. The universal ID shall be an OID (ISO Object Identifier), and therefore the universal ID
Type must be “ISO”.
3.8.4.2 Patient Identity Management –Patient Identity Merge (Merge Patient ID)
3.8.4.2.1 Trigger Events

1075

1080

When two patients’ records are found to identify the same patient by a Patient Identity Source
Actor in a Patient Identifier Domain and are merged, the Patient Identity Source shall trigger thefollowing message:• A40 – Merge Patient – Internal ID
An A40 message indicates that the Patient Identity Source Actor has done a merge within a
specific Patient Identification Domain. That is, MRG-1 (patient ID) has been merged into PID-3(Patient ID).
3.8.4.2.2 Message Semantics

1085

The Patient Identity Feed transaction is an HL7 ADT message. The message shall be generated
by the system (Patient Identity Source Actor) that performs the update whenever two patient
records are found to reference the same person.
Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7
profiling are stated in Appendix C and C.1 in this Volume.

1090

The segments of the HL7 Merge Patient message listed below are required, and the detailed
description of the message is provided in Section 3.8.4.2.2.1–3.8.4.2.2.6. The PV1 segment is
optional.
__________________________________________________________________________
46
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Table 3.8-3 ADT A40 Patient Administration Message
ADT A40

Patient Administration Message

Chapter in
HL7 v2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

MRG

Merge Information

3

[PV1]

Patient Visit

3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See Appendix C.1.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
1095

1100

A separate merge message shall be sent for each pair of patient records to be merged. For
example, if Patients A, B, and C are all to be merged into Patient B, two ADT^A40 messages
would be sent. In the first ADT^A40 message, patient B would be identified in the PID segment
and Patient A would be identified in the MRG segment. In the second ADT^A40 message,
patient B would be identified in the PID segment, and Patient C would be identified in the MRG
segment.
Modification of any patient demographic information shall be done by sending a separate Update
Patient Information (A08) message for the current Patient ID. An A40 message is the only
method that may be used to update a Patient ID.
3.8.4.2.2.1 MSH Segment

1105

MSH segment shall be constructed as defined in the Appendix C.1.2 “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of ADT; the second component shall have value of A40. The third component is optional;
however, if present, it shall have a value of ADT_A39.
3.8.4.2.2.2 EVN Segment

1110

See Appendix C.1.4 for the list of all required and optional fields within the EVN segment.
3.8.4.2.2.3 PID Segment
The PID segment shall be constructed as defined in Section 3.8.4.1.2.3.
3.8.4.2.2.4 MRG Segment

1115

The PID and PV1 segments contain the dominant patient information, including Patient ID (andIssuer of Patient ID). The MRG segment identifies the “old” or secondary patient records to be__________________________________________________________________________
47
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
de-referenced. HL7 does not require that the ”old” record be deleted; it does require that the"old" identifier shall not be referenced in future transactions following the merge.

1120

IHE does not require that the Patient Identity Source Actor send any attributes within the MRG
segment beyond what is specified in the HL7 standard. If the assigning authority component of
MRG-1 is present (MRG-1.4), it shall be equal to the assigning authority component of PID-3(PID-3.4)
3.8.4.2.2.5 PV1 Segment
PV1 segment shall be constructed as defined in Section 3.8.4.1.2.4.
3.8.4.2.3 Expected Actions

1125

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
MRG segment as specified in Table 3.8-4.
Table 3.8-4 IHE Profile - MRG segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

250

CX

R

00211

Prior Patient Identifier List

2

250

CX

O

00212

Prior Alternate Patient ID

3

250

CX

O

00213

Prior Patient Account Number

4

250

CX

R2

00214

Prior Patient ID

5

250

CX

O

01279

Prior Visit Number

6

250

CX

O

01280

Prior Alternate Visit ID

7

250

XPN

R2

01281

Prior Patient Name

Adapted from the HL7 Standard, Version 2.3.1
1130

1135

In addition, the Patient Identifier Cross-reference Manager shall perform the Expected Actions as
specified in Section 3.8.4.1.3.
When the Patient Identifier Cross-reference Manager receives the ADT^A40 message type of thePatient Identity Feed transaction, it shall cross-reference the patient identifiers provided in the
PID-3 and MRG-1 fields of the message by replacing any references it is maintaining internallyto the patient ID provided in the MRG-1 field by the patient ID included in the PID-3 field. Afterthe identifier references are replaced, the Patient Identifier Cross-reference Manager shallreapply its internal cross-referencing logic/ policies before providing the updated information via
either the PIX Query or PIX Notification Transactions.
3.8.4.2.4 Expected Actions – Document Registry1140

The Document Registry shall be capable of accepting attributes in the MRG segment as specified
in Table 3.8-4. Other attributes may exist, but the Document Registry shall ignore them.

__________________________________________________________________________
48
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Table 3.8-4 IHE Profile - MRG segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

250

CX

R

00211

Prior Patient Identifier List

2

250

CX

O

00212

Prior Alternate Patient ID

3

250

CX

O

00213

Prior Patient Account Number

4

250

CX

R2

00214

Prior Patient ID

5

250

CX

O

01279

Prior Visit Number

6

250

CX

O

01280

Prior Alternate Visit ID

7

250

XPN

R2

01281

Prior Patient Name

Adapted from the HL7 Standard, Version 2.3.1
In addition, the Document Registry shall perform the Expected Actions as specified in Section
3.8.4.1.4.
1145

1150

When the Document Registry receives the ADT^A40 message type of the Patient Identity Feedtransaction, it shall merge the patient identity specified in MRG-1 (secondary patient identity)
into the patient identity specified in PID-3 (primary patient identity) in its registry. After themerge, all Document Submission Sets (including all Documents beneath them) under thesecondary patient identity before the merge shall point to the primary patient identity. The
secondary patient identity shall no longer be referenced in the future services provided by theDocument Registry.

__________________________________________________________________________
49
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.9 PIX Query
1155

This section corresponds to Transaction ITI-9 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-9 is used by the Patient Identifier Cross-reference Consumer and Patient
Identifier Cross-reference Manager actors.
3.9.1 Scope

1160

This transaction involves a request by the Patient Identifier Cross-reference Consumer Actor fora list of patient identifiers that correspond to a patient identifier known by the consumer. The
request is received by the Patient Identifier Cross-reference Manager. The Patient Identifier
Cross-reference Manager immediately processes the request and returns a response in the formof a list of corresponding patient identifiers, if any.
3.9.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIX Query1165

Actor: Patient Identifier Cross-reference Consumer
Role: Queries the Patient Identifier Cross-reference Manager for a list of corresponding patient
identifiers, if any
Actor: Patient Identifier Cross-reference Manager

1170

Role: Manages the cross-referencing of patient identifiers across Patient Identification Domains.
Upon request it returns a list of corresponding patient identifiers, if any.
3.9.3 Referenced Standard
HL7 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query
HL7 version 2.5 was selected for this transaction for the following reasons:1175

It was considered the most stable version that contained the functionality required bytransactions ITI-9 and ITI-10.

__________________________________________________________________________
50
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.9.4 Interaction Diagram
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

Get Corresponding
Identifiers: HL7 QBP^Q23

Return Corresponding
Identifiers: HL7 RSP^K23

Figure 3.9-1 Get Corresponding Identifiers Sequence

3.9.4.1 Get Corresponding Identifiers1180

3.9.4.1.1 Trigger Events
A Patient Identifier Cross-reference Consumer’s need to get the patient identifier associated witha domain for which it needs patient related information will trigger the request forcorresponding patient identifiers message based on the following HL7 trigger event:• Q23 – Get Corresponding Identifiers1185

3.9.4.1.2 Message Semantics

1190

The Request for Corresponding Patient Identifiers transaction is conducted by the HL7
QBP^Q23 message. The Patient Identifier Cross-reference Consumer Actor shall generate thequery message whenever it needs to obtain a corresponding patient identifier(s) from other
Patient Identification Domain(s). The segments of the message listed below are required, andtheir detailed descriptions are provided in the following subsections.
Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7
profiling are stated in Appendix C and C.1 in this Volume.

Table 3.9-1 QBP Query By Parameter
QBP

Query By Parameter

Chapter in
HL7 2.5

MSH

Message Header

2

QPD

Query Parameter Definition5__________________________________________________________________________
51
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
QBP

Query By Parameter

RCP

1195

Chapter in
HL7 2.5

Response Control Parameter5

The receiver shall respond to the query by sending the RSP^K23 response message. Thissatisfies the requirements of original mode acknowledgment; no intermediate ACK message is tobe sent.
3.9.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in Appendix C.1.2 “Message Control”.

1200

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of QBP; the second component shall have the value of Q23. The third component is
optional; however, if present, it shall have a value of QBP_Q21.
3.9.4.1.2.2 QPD Segment

1205

The Patient Identifier Cross-reference Consumer Actor is required to send attributes within the
QPD segment as described in Table 3.9-2.
Table 3.9-2 IHE Profile - QPD segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

0471

01375

Message Query Name

00696

Query Tag

1

250

CE

R

2

32

ST

R+

3

250**

CX

R

Person Identifier

4

250

CX

O

What Domains Returned

Adapted from the HL7 Standard, version 2.5** Note: This value assumes completion of an HL7 erratum to correct an error identified in the standard.

1210

This message shall use the field QPD-3 Person Identifier to convey a single Patient ID uniquely
identifying the patient within a given Patient Identification Domain.
The Patient Identifier Cross-reference Consumer Actor shall provide the patient identifier in the
ID component (first component) of the QPD-3 field (QPD-3.1).

1215

The Patient Identifier Cross-reference Consumer Actor shall provide component QPD-3.4,
Assigning Authority, by including either the first subcomponent (namespace ID) or the second
and third subcomponents (universal ID and universal ID type) If all three subcomponents are
populated, the first subcomponent shall reference the same entity as is referenced by the second
and third components.
If the requesting system wishes to select the domains from which they wish to receive PatientIDs, it does so by populating QPD-4-What Domains Returned with as many repetitions as__________________________________________________________________________
52
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1220

1225

domains for which it wants to receive Patient IDs. Each repetition of QPD-4 shall contain an
instance of data type CX in which only the fourth component (Assigning Authority) is populated;
the remaining components shall be empty. The responding system shall return the Patient ID
value for each requested domain if a value is known.
If QPD-4 is empty, the Patient Identifier Cross-reference Manager Actor shall return Patient IDs
for all domains for which it possesses a corresponding Patient ID (subject to local publication
restrictions).
3.9.4.1.2.3 RCP Segment

1230

Although HL7 requires that the RCP Segment be sent in all QBP messages, IHE does not requirethat the Patient Identifier Cross-reference Consumer Actor send any attributes within the RCP
segment, as is specified in the HL7 standard.
3.9.4.1.2.3.1 3.9.4.1.2.3.1 Populating RCP-1-Query Priority
Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is tobe returned in Immediate mode.
3.9.4.1.3 Expected Actions

1235

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
QPD segment as specified in Table 3.9-2.
The Patient Identifier Cross-reference Manager Actor must be capable of receiving all valid
combinations of subcomponents that make up the Assigning Authority component (i.e., all valid
combinations of QPD-3.4).

1240

The Patient Identifier Cross-reference Manager Actor shall be capable of accepting multiple
concurrent PIX Query requests (Get Corresponding Identifiers messages) and responding
correctly using the Return Corresponding Identifiers message.
3.9.4.2 Return Corresponding Identifiers
3.9.4.2.1 Trigger Events

1245

The Patient Identifier Cross-reference Manager’s response to the Get Patient Identifiers message
will trigger the following message:• K23 – Corresponding patient identifiers
3.9.4.2.2 Message Semantics

1250

The Return Corresponding Identifiers transaction is conducted by the HL7 RSP^K23 message.
The Patient Identifier Cross-reference Manager Actor shall generate this message in direct__________________________________________________________________________
53
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1255

response to the QBP^Q23 query message previously received. This message satisfies the
Application Level, Original Mode Acknowledgement for the HL7 QBP^Q23 message. The
segments of the message listed without enclosing square brackets in the Table below are required.
Detailed descriptions of all segments listed in the table below are provided in the following
subsections. Other segments of the message are optional.
Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7
profiling are stated in Appendix C and C.1 in this Volume.

Table 3.9-3 RSP Segment Pattern Response
RSP

Segment Pattern Response

Chapter in
HL7 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2

[ERR]

Error segment

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5

[PID]

Patient Identification

3

3.9.4.2.2.1 MSH Segment
1260

The MSH segment shall be constructed as defined in Appendix C.1.2, “Message Control”.
Field MSH-9-Message Type shall have at least two components. The first component shall have avalue of RSP; the second component shall have the value of K23. The third component is
optional; however, if present, it shall have a value of RSP_K23.
3.9.4.2.2.2 MSA Segment

1265

The Patient Identifier Cross-reference Manager Actor is not required to send any attributes
within the MSA segment beyond what is specified in the HL7 standard. See Appendix C.1.3 forthe list of all required and optional fields within the MSA segment.
3.9.4.2.2.3 QAK Segment

1270

The Patient Identifier Cross-reference Manager Actor shall send attributes within the QAK
segment as defined in Table 3.9-4. For the details on filling in QAK-2 (Query Response Status)
refer to Section 3.9.4.2.2.6.
Table 3.9-4 IHE Profile - QAK segment
SEQ

LEN

DT

OPT

1

32

ST

R

2

2

ID

R+

TBL#
0208

ITEM#

ELEMENT NAME

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5__________________________________________________________________________
54
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1275

3.9.4.2.2.4 QPD Segment
The Patient Identifier Cross-reference Manager Actor shall echo the QPD Segment value thatwas sent in the QBP^Q23 message.
3.9.4.2.2.5 PID Segment

1280

1285

1290

1295

1300

1305

The Patient Identifier Cross-reference Manager Actor shall return only those attributes within the
PID segment that are required by the HL7 standard: PID-3-Patient IdentifierList and PID-5Patient Name.
The PID segment is returned only when the Patient Identifier Cross-reference Manager Actor
recognizes the specified Patient Identification Domain and Patient ID and an identifier exists forthe specified patient in at least one other domain. See Section 3.9.4.2.2.6, “Patient Identifier
Cross-reference Manager Actor Query Response Behavior,” for a detailed description of how thePatient Identifier Cross-reference Manager Actor responds to the query request under various
circumstances.
The Patient Identifier Cross-reference Manager Actor shall use the field PID-3 Patient Identifier
List to convey the Patient ID uniquely identifying the patient within each Patient Identification
Domain for which a Patient ID exists for the specified patient. Each resulting ID returned in PID3 shall include a fully qualified Assigning Authority component. In other words, the Assigning
Authority component returned shall include ALL subcomponents (namespace ID, Universal ID,
and Universal ID type).
To eliminate the issue of conflicting name values between Patient Identifier Domains, the Patient
Identifier Cross-reference Manager Actor shall return in an empty (not present) value in the first
repetition of field PID-5-Patient Name, and shall return a second repetition of field PID-5Patient Name in which the only populated component is Component 7 (Name Type Code).
Component 7 of repetition 2 shall contain a value of S (Coded Pseudo-name to assure
anonymity). All other components of repetition 2 shall be empty (not present).
3.9.4.2.2.6 Patient Identifier Cross-reference Manager Actor Query Response
Behavior
It is wholly the responsibility of the Patient Identifier Cross-reference Manager Actor to performthe matching of patient identifiers based on the patient traits it receives. The information
provided by the Patient Identifier Cross-reference Manager Actor to Patient Identifier Crossreference Consumer Actors is a list of cross-referenced identifiers in two or more of the domains
managed by the cross-referencing Actor. The list of cross-references is not made available until
the set of policies and processes for managing the cross-reference function have been completed.
The policies of administering identities adopted by the cooperating domains are completelyinternal to the Patient Identifier Cross-reference Manager Actor and are outside of the scope of__________________________________________________________________________
55
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1310

this framework. Possible matches should not be communicated until the healthcare institution
policies and processes embodied in the Patient Identifier Cross-reference Manager Actor reach apositive matching decision.
The Patient Identifier Cross-reference Manager Actor shall respond to the query request as
described by the following 6 cases:

1315

1320

Case 1: The Patient Identifier Cross-reference Manager Actor recognizes the specified Patient
Identification Domain and Patient ID sent by the Patient Identifier Cross-reference Consumer in
QPD-3, and corresponding identifiers exist for the specified patient in at least one of the domains
requested in QPD-4 (one identifier per domain). (See Case 6 below for the required behavior if
there are multiple identifiers recognized within a given Identifier Domain by the Patient
Identifier Cross-reference Manager Actor.)
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

1325

1330

A single PID segment is returned in which one repetition of PID-3 Patient Identifier List is
populated for each of the domains, if any, that the Patient Identifier Cross-reference Manager
Actor did recognize in which a single identifier exists for the requested patient, not including thequeried-for patient identifier that is returned in QPD-3.
Case 2: The Patient Identifier Cross-reference Manager Actor recognizes the Patient
Identification Domain and Patient ID sent in QPD-3, but no identifier exists for that patient inany of the domains sent in QPD-4.
AA (application accept) is returned in MSA-1.
NF (no data found, no errors) is returned in QAK-2.
No PID segment is returned.

1335

Case 3: The Patient Identifier Cross-reference Manager Actor recognizes the specified Patient
Identification Domain sent in the fourth component of QPD-3, but does not recognize the Patient
ID sent in the first component of QPD-3.
AE (application error) is returned in MSA-1 and in QAK-2.

1340

An ERR segment is returned in which the components of ERR-1-Error Code and Location arevalued as follows.
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence1__________________________________________________________________________
56
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________COMP #COMPONENT NAME

VALUE

3

Field Position

3

4

Field Repetition

1

5

Component Number

1

6

Sub-Component Number(empty)As specified by HL7, ERR-2.6-Sub-Component Number is not valued because we are referring to
the entire fourth component of field QPD-4.
1345

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Identifier Cross-referenceManager Actor did not recognize the value in the first component of QPD-3.
Case 4: The Patient Identifier Cross-reference Manager Actor does not recognize the Patient
Identification Domain of the identifier sent in QPD-3.

1350

AE (application error) is returned in MSA-1 and in QAK-2.
An ERR segment is returned in which the components of ERR-2-Error Location are valued asfollows.

1355

COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

3

4

Field Repetition

1

5

Component Number

4

6

Sub-Component Number(empty)As specified by HL7, ERR-2.6-Sub-Component Number is not valued because we are referring to
the entire fourth component of field QPD-3.
ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Identifier Cross-referenceManager Actor did not recognize the value in the fourth component of QPD-3.

1360

Case 5: The Patient Identifier Cross-reference Manager Actor does not recognize one or more of
the Patient Identification Domains for which an identifier has been requested.
AE (application error) is returned in MSA-1 and in QAK-2.
For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.
__________________________________________________________________________
57
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1365
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

4

4

Field Repetition(see below)

5Component Number(empty)6

Sub-Component Number(empty)As specified by HL7, ERR-2.5-Component Number and ERR-2.6-Sub-Component Number are
not valued because we are referring to the entire field QPD-4.

1370

1375

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Identifier Cross-referenceManager Actor did not recognize the domain for the occurrence of QPD-4-What Domains
Returned whose ordinal number is returned as an integer in ERR-2.4.
Case 6: The Patient Identifier Cross-reference Manager Actor recognizes the specified Patient
Identification Domain and Patient ID sent by the Patient Identifier Cross-reference Consumer in
QPD-3, and corresponding identifiers exist for the specified patient in at least one of the domains
requested in QPD-4, and there are multiple identifiers within at least one of the requested
domains.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

1380

A single PID segment is returned in which one repetition of PID-3-Patient Identifier List is
populated for each of the identifiers, not including the queried-for patient identifier that isreturned in QPD-3. If the Patient Identifier Cross-reference Manager Actor chooses to return
multiple identifiers associated with the same domain, it shall return these identifiers grouped insuccessive repetitions within the PID-3-Patient Identifier List.
3.9.4.2.3 Expected Actions

1385

1390

The Patient Identifier Cross-reference Consumer will use the list of patient identifier aliases
provided by the Patient Identifier Cross-reference Manger to perform the functions for which it
requested the list.
In the case where the returned list of identifiers contains multiple identifiers for a single domain,
the Patient Identifier Cross-reference Consumer shall either use ALL of the multiple identifiers
from the given domain or it shall ignore ALL of the multiple identifiers from the given domain.
This allows Patient Identifier Cross-reference Consumer Actors capable of handling multiple
identities for a single patient within a single domain (i.e., those that can correctly aggregate theinformation associated with the different identifiers) to do so. For those Patient Identifier Cross__________________________________________________________________________
58
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1395

reference Consumer Actors not capable of handling this situation, ignoring the entire list ofdifferent identifiers prevents the consumer from presenting incomplete data.

__________________________________________________________________________
59
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.10 PIX Update Notification
This section corresponds to Transaction ITI-10 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-10 is used by the Patient Identifier Cross-reference Consumer andPatient Identifier Cross-reference Manager actors.
1400

3.10.1 Scope

1405

This transaction involves the Patient Identifier Cross-reference Manager Actor providing
notification of updates to patient identifier cross-reference associations to Patient Identifier
Cross-reference Consumers that have registered (by configuration on the Cross-referenceManager) their interest in receiving such notifications. This transaction uses HL7’s generic‘Update Person Information’ message to communicate this patient-centric information.
3.10.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIX Update
Notification

Actor: Patient Identifier Cross-reference Manager
1410

Role: It serves a well-defined set of Patient Identification Domains. The Patient Identifier
Cross-reference Manager manages the cross-referencing of patient identifiers across Patient
Identification Domains by providing a list of patient ID “aliases” via notification to a configured
list of interested Patient Identifier Cross-reference Consumers.
Actor: Patient Identifier Cross-reference Consumer1415

Role: Receives notifications from the Patient Identifier Cross-reference Manager of changes topatient ID aliases. Typically the Patient Identifier Cross-reference Consumer Actor uses thisinformation to maintain information links about patients in a different patient ID domain.
3.10.3 Referenced Standard
HL7 Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration
HL7 version 2.5 was selected for this transaction for the following reason:

1420

It was considered the most stable version that contained the functionality required by Transaction
ITI-9 and ITI-10.
__________________________________________________________________________
60
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.10.4 Interaction Diagram

Patient Identifier
Cross-referenceManager

Patient Identifier
Cross-reference
Consumer

Update Person Information:
HL7 ADT^A31

Figure 3.10-1 Update Person Information Sequence1425

3.10.4.1 Update Person Information
3.10.4.1.1

1430

1435

Trigger Events

The Patient Identifier Cross-reference Manager shall notify a Patient Identifier Cross-reference
Consumer when there is a change in a set of cross-referenced patient identifiers for any of thepatient identifiers belonging to Patient Identifier Domains of interest to the consumer. The
configuration of the domains of interest to a Patient Cross-reference Consumer is maintained by
the Patient Cross-reference Manager Actor.
Several notifications may have to be issued to communicate a single update to a set of crossreference patient identifiers as required to reflect all the changes on the resulting sets of crossreference patient Identifiers belonging to Patient Identifier Domains of interest to the Patient
Identifier Cross-referencing Consumer.
The following HL7 trigger event will be used to update to the list of patient identifiers:• A31 – Update Person Information
3.10.4.1.2

1440

Message Semantics

The PIX Update Notification transaction is conducted by the ADT^A31 message. The Patient
Identifier Cross-reference Manager Actor initiates this transaction whenever identifier list
information is updated for a patient.
It is wholly the responsibility of the Patient Identifier Cross-reference Manager Actor to performthe matching of patient identifiers based on the patient traits it receives. The information
provided by the Patient Identifier Cross-reference Manager Actor to Patient Identifier Cross__________________________________________________________________________
61
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1445

1450

1455

reference Consumer Actors is a list of cross-referenced identifiers in two or more of the domains
managed by the cross-referencing Actor. The list of cross-references is not made available until
the set of policies and processes for managing the cross-reference function have been completed.
The policies of administering identities adopted by the cooperating domains are completelyinternal to the Patient Identifier Cross-reference Manager Actor and are outside of the scope of
this standard. Possible matches should not be communicated until the healthcare institution
policies and processes embodied in the Patient Identifier Cross-reference Manager Actor reach apositive matching decision.
The Patient Identifier Cross-reference Manager Actor Configuration is expected to haveconfiguration indicating which Identity Consumers are interested in receiving the PIX Update
Notification Transactions. This configuration information shall include identification of theidentity consumer systems interested in receiving notifications and, for each of those systems, alist of the patient identifier domains of interest.
The segments of the message listed in the Table below are required. Other segments are optional.
Table 3.10-1 ADT Patient Administration Message
ADT

1460

Patient Administration Message

Chapter in
HL7 2.5

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

PV1

Patient Visit

3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See Appendix C.1.3, “Acknowledgement Modes” for the definition anddiscussion of the ACK message.
3.10.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in Appendix C.1.2, “Message Control”.

1465

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of ADT; the second component shall have the value of A31. The third component is
optional; however, if present, it shall have a value of ADT_A31.
3.10.4.1.2.2 EVN Segment
See Appendix C.1.4 for the list of all required and optional fields within the EVN segment.

1470

3.10.4.1.2.3 PID Segment
The Patient Identifier Cross-reference Manager Actor shall provide only those attributes within
the PID segment that are required by the HL7 standard: PID-3-Patient Identifier List and PID-5Patient Name.
__________________________________________________________________________
62
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1475

1480

1485

The Patient Identifier Cross-reference Manager Actor shall use the field PID-3 Patient Identifier
List to convey the Patient IDs uniquely identifying the patient within each Patient Identification
Domain for which a Patient ID exists for the specified patient. Each resulting ID returned in PID3 shall include a fully qualified Assigning Authority component. In other words, the Assigning
Authority component returned shall include ALL subcomponents (namespace ID, Universal ID,
and Universal ID type).
To eliminate the issue of multiple name values between Patient Identifier Domains, the Patient
Identifier Cross-reference Manager Actor shall return a single space character in field PID-5Patient Name.
A single PID segment is sent in which one repetition of PID-3-Patient Identifier List is populated
for each of the identifiers in the notification. If the Patient Identifier Cross-reference Manager
Actor chooses to send multiple identifiers associated with the same domain, it shall return theseidentifiers grouped in successive repetitions within the PID-3-Patient Identifier List.
3.10.4.1.2.4 PV1 Segment

1490

As is specified by the HL7 Standard, Version 2.5, the PV1 Segment is required. The required
field PV1-2-patient class shall contain N (not applicable) to indicate the transmission of patient
information outside the context of a visit or encounter. Other fields shall be left blank.
Table 3.10-2 IHE Profile – PV1 segment
SEQ

LEN

2

1

DT
IS

OPT
R

TBL#

ITEM#

0004

00132

ELEMENT NAME
Patient Class

Adapted from the HL7 Standard, version 2.5
3.10.4.1.3
1495

Expected Actions

The Patient Identifier Cross-reference Consumer, when it receives the ADT^A31 message, shallupdate its internal identifier information for the affected patient(s) in all domains in which it isinterested whenever it receives updated identifier information that results in a change to thecross-referencing of a patient.

1500

In the case where the returned list of identifiers contains multiple identifiers for a single domain,
the Patient Identifier Cross-reference Consumer shall either use ALL of the multiple identifiers
from the given domain or it shall ignore ALL of the multiple identifiers from the given domain.

1505

This allows Patient Identifier Cross-reference Consumer Actors capable of handling multiple
identities for a single patient within a single domain (i.e., those that can correctly aggregate theinformation associated with the different identifiers) to do so. For those Patient Identifier Crossreference Consumer Actors not capable of handling this situation, ignoring the entire list ofdifferent identifiers prevents the consumer from presenting incomplete data.

__________________________________________________________________________
63
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.11 Retrieve Specific Information for Display
This section corresponds to Transaction ITI-11 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-11 is used by the Information Source and Display actors.
1510

1515

1520

3.11.1 Scope
This transaction involves the query of information for presentation purposes. This may occur
when a user attempts to lookup information associated with certain patient that is stored on adifferent system. Note that the retrieved information is always related to a well-identified patient(Patient ID), but its content, although of a specific type (lab summary, or radiology summary, listof allergies), is generally dynamic (i.e., retrieving the same type of specific information at adifferent point in time is likely to result in different content); for example, a list of allergies may
have been updated between two requests.
To support a wide range of display capabilities, the information provided is formatted into wellformed XHTML. Such formatting shall be done using XHTML Basic and W3C HTMLCompatibility Guidelines provided in the Appendix C of the W3C XHTML 1.0
Recommendation.
3.11.2 Use Case Roles

Display

Information Source

Retrieve SpecificInfo for Display

1525

Actor: Display
Role: A system that requests specific information for display, and displays it.
Actor: Information Source
Role: A system that provides specific information in response to the request from the Display
Actor, in a presentation-ready format.

1530

3.11.3 Referenced Standards•

IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html__________________________________________________________________________
64
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
1535

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001.
http://www.w3.org/TR/wsdl.

1540

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition).A Reformulationof HTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002.
http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtmbasic.
Interaction Diagram
Display

Information
SourceRequest For Specific Information (Summary, List)
Response With Specific Information (Summary, List)

1545

Figure 3.11-1 Request For Specific Information – Summary sequence

3.11.3.1 Request For Specific Information - Summary
3.11.3.1.1

1550

The following event will trigger a Request for Specific Information:• User of the Display Actor needs to review a summary list of information/ reports that arepart of a patient’s clinical history (i.e., summary of lab reports, summary of radiology
exam reports, etc.) with the intent of selecting a specific item off the list for subsequent
retrieval as a persistent object via the Retrieve Document for Display Transaction
3.11.3.1.2

1555

Trigger Events

Message Semantics

The Retrieve Specific Information for Display transaction is performed by the invocation of a
web service. The Display Actor shall generate a web service request whenever a user needs toreview the information stored as part of a patient’s clinical history on the Information Source
Actor.
__________________________________________________________________________
65
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1560

To specify the type of information that needs to be returned, a web service request shall include
the following parameters (keys) to filter the subset of information (See Table 3.11.4-1). All
parameter names and values (see Table 3.11.4-2) are case-sensitive.
Table 3.11.4-1 Web Service Request Keys
Parameter
Name

REQ

Description

Notes

requestType

R

requestType specifies what type of
information shall be retrieved. Thisparameter shall always be valued.

See Table 3.11.4-2 for the list of possible
values.

patientID

R

This attribute identifies the subject of
the results being queried for. Its value
shall include identification of assigningauthority.

PatientID value shall be formatted as HL7 CX
data type (including assigning authority)
according to the requirements specified for the
Patient Identity Feed transaction (see Section
3.8.4.1.2.3)

lowerDateTime

O

Used to constrain the earliest date/timeof creation of information.

This value shall be encoded in the XML
primitive dateTime format.

upperDateTime

O

Used to constrain the latest date/time ofcreation of information.

This value shall be encoded in the XML
primitive dateTime format.

mostRecentResults

R

The numeric value that indicates thenumber of most recent results to be
included into the response, i.e., 1
indicates to provide the latest result.

Value of 0 indicates that all available results
shall be returned.

Table 3.11.4-2 Web Service Request TypesrequestType value

1565

Description

SUMMARY

Summary of all reports known to the Information Source

SUMMARY-RADIOLOGY

Summary of radiology reports

SUMMARY-CARDIOLOGY

Summary of cardiology reports

SUMMARY-LABORATORY

Summary of laboratory reports

SUMMARY-SURGERY

Summary of surgery reports

SUMMARY-EMERGENCY

Summary of emergency reports

SUMMARY-DISCHARGE

Summary of discharge reports

SUMMARY-ICU

Summary of intensive care reports

SUMMARY-RX
Summary of Prescriptions
Note: parameter values that contain reserved characters need to be encoded using %<hex><hex> notation.
Reserved characters include slash (/, encode as %2f) and ampersand (&, encode as %26).

Formal definition of the web service in WSDL is provided in the Appendix A.
The only binding required for both the Display Actor and Information Source Actor is thebinding to the HTTP-GET. In this binding the sample message will be formatted as follows:__________________________________________________________________________
66
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1570

1575

http://<location>/IHERetrieveSummaryInfo?requestType=SUMMARY&patientID=9999841
0^^^%26www.mlhlife.com%26DNS &lowerDateTime=2003-0101T00:00:00&upperDateTime=2003-01-01T23:59:59&mostRecentResults=1
The <location> part of the URL is configurable by the implementation, and must contain the hostname, an optional port address, and may be followed by an optional path. The path if present
may not contain a ‘?’ character. The remainder of the URL, including IHERetrieveSummaryInfo
and the following request parameters are specified by the WSDL and may not be changed.
More specifically, using the definitions from RFC 1738, the <location> part of the URL mustmatch the production for location from the figure below:
location= hostport [ "/" hpath ]hostport
hosthostnamedomainlabel
toplabelalphadigit
hostnumber
port= host [ ":" port ]= hostname | hostnumber= *[ domainlabel "." ] toplabel= alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit= alpha | alpha *[ alphadigit | "-" ] alphadigit= alpha | digit= digits "." digits "." digits "." digits= digits

1590

hpath
hsegment
lowalpha1595

hialpha= hsegment *[ "/" hsegment ]= *[ uchar | ";" | ":" | "@" | "&" | "=" ]= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |"y" | "z"= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

1600

alpha
digit

1580

1585

safe
extra

1605

1610

hex

= lowalpha | hialpha= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |"8" | "9"= "$" | "-" | "_" | "." | "+"= "!" | "*" | "'" | "(" | ")" | ","escape= digit | "A" | "B" | "C" | "D" | "E" | "F" |"a" | "b" | "c" | "d" | "e" | "f"= "%" hex hex

unreserveduchar= alpha | digit | safe | extra= unreserved | escapeThe following location values are legal according to this specification:__________________________________________________________________________
67
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________<location> value

Resulting URL

Myhosthttp://myhost/IHERetrieveSummaryInfo?…

myhost:8080

http://myhost:8080/IHERetrieveSummaryInfo?
…

myhost/MyAspPageThatLooksLikeItCould
BeAFolder.aspx

http://myhost/MyAspPageThatLooksLikeItCou
ldBeAFolder.aspx/IHERetrieveSummaryInfo?
…

myhost:8080/MyAspPageThatLooksLikeItC
ouldBeAFolder.aspx

http://myhost:8080/MyAspPageThatLooksLike
ItCouldBeAFolder.aspx/IHERetrieveSummaryInfo?…

myhost/MyJspPage.jsp

http://myhost/MyJspPage.jsp/IHERetrieveSummaryInfo?…

myhost:8080/MyJspPageThatLooksLikeItC
ouldBeAFolder.jsp

http://myhost/MyJspPage.jsp/
IHERetrieveSummaryInfo?…

The following location values are not legal:<location> value

Resulting URL

My+Computer‘+’ is not a legal character in a host name.

myhost:99999

99999 is not a valid port.

myhost/myPath.jsp?request=‘?’ is not valid in a path.

1615
In addition, the Display Actor shall support the following field of the HTTP request:
Table 3.11.4-3 HTTP Request and Response Fields
HTTP
Field

REQ

AcceptLanguage

O

Description

ValuesThis field restricts the set of natural languages that are
preferred as a response to the request.

Any valid value according to
RFC2616

The Information Source actor shall support the following field of the HTTP response.

__________________________________________________________________________
68
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1620

Table 3.11.4-4 HTTP Response Fields
HTTP
Field

REQ

Description

ValuesExpires

R

This field gives the date/time after which
the response is considered stale

Shall be 0. This is now deprecated usage, but it is the
widely supported means of specifying no cacheing.

CacheControl

R

This field indicates that this response
should not be cached.

Shall be no-cache

If necessary, the Display Actor may perform the request to the web service utilizing HTTPS
protocol.
•1625

Information Source Actors may return HTTP redirect responses (responses with values of 301, 302,
303 or 307) in response to a request. Display Actors can expect to receive an error response, or thedata requested, or a request to look elsewhere for the data. A Display Actor must follow redirects, but
if a loop is detected, it may report an error.

3.11.3.1.3
1630

Expected Actions

Upon reception of the Request for Specific Information, the Information Source Actor shall parsethe request and if there are no errors, return the Response with Specific Information as specified
in Section 3.11.4.2, and HTTP response code 200 - OK.
To specify the type of information that needs to be processed, an Information Source Actor shallsupport the following parameters (keys) to filter the subset of information (See Table 3.11.4-5).
Table 3.11.4-5 Web Service Request Keys
Parameter
Name

REQ

Description

Notes

requestType

R

requestType specifies what type of
information shall be retrieved. Thisparameter shall always be valued.

See Table 3.11.4-2 for the list of possible
values.

patientID

R

This attribute identifies the subject of
the results being queried for. Its value
shall include identification of assigningauthority.

PatientID value shall be formatted as HL7 CX
data type (including assigning authority)
according to the requirements specified for the
Patient Identity Feed transaction (see Section
3.8.4.1.2.3)

lowerDateTime

R

Used to constrain the earliest date/timeof creation of information.

This value shall be encoded in the XML
primitive dateTime format.

upperDateTime

R

Used to constrain the latest date/time ofcreation of information.

This value shall be encoded in the XML
primitive dateTime format.

mostRecentResults

R

The numeric value that indicates thenumber of most recent results to be
included into the response, i.e., 1
indicates to provide the latest result.

Value of 0 indicates that all available results
shall be returned.

1635__________________________________________________________________________
69
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
If the requestType specified is not supported, the Information Source Actor shall return HTTP
response-code 404 (not found) with the suggested reason-phrase “requestType not supported”.. If
the Information Source Actor is not able to format the document in any content types listed in the'Accept' field, it shall return HTTP response code 406 – Not Acceptable.
1640

1645

1650

If the Patient ID specified by the Display Actor is not known to the Information Source Actor, it
shall return HTTP response-code 404 (not found) with the suggested reason-phrase “Patient ID
not found”. If the Display Actor provides the Patient ID from a different domain than the one theInformation Source Actor belongs to, and the Information Source Actor is grouped with thePatient ID Consumer Actor, it may attempt to obtain a mapping of the provided Patient ID into
its domain before responding.
Note: Other HTTP response codes may be returned by the Information Source Actor, indicating conditions outsideof the scope of this profile, for example, 401 – Authentication Failed might be returned if Information
Source Actor is grouped with the Kerberized Server Actor.
Note: It is recommended that the Information Source Actor complement the returned error code with a humanreadable description of the error condition.

If an error condition cannot be automatically recovered, at a minimum, the error should be
displayed to the user by the Display Actor.
1655

If lowerDateTime and/or upperDateTime parameters are specified, they shall define the lower
and/or upper inclusive boundary of the temporal range in which returned information shouldhave been created. The value of the mostRecentResults parameter shall be interpreted withinsuch specified date/time range.
3.11.3.2 Response with Specific Information - Summary
3.11.3.2.1

1660

Trigger Events

This message is sent by the Information Source Actor in response to the Request For SpecificInformation web service request.
3.11.3.2.2

Message Semantics

Information Source Actor shall support at least one of the values of the requestType parameter
specified in Table 3.11.4-2.
1665

1670

The Information Source shall set an expiration of zero to ensure no caching. The message shallbe formatted using XHTML Basic and W3C HTML Compatibility Guidelines provided in the
Appendix C of the W3C XHTML 1.0 Recommendation.
The Display Actor may request the Information Source Actor to provide any specific information
including a summary of reports of different types pertaining to a particular patient. The exact
content of the summary is determined by the Information Source Actor and may be regulated by
the institution policy. For example, it may contain the hyperlink to a persistent object so that it__________________________________________________________________________
70
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1675

can be retrieved by using the Retrieve Document for Display Transaction. In the case of
retrieving a summary of documents (requestType of SUMMARY[-xx]), it is strongly
recommended to include a link to the relevant documents, for each item of the summary. If
present, the link will have to be formatted as a web service request in accordance to therequirements in Section 3.12. It may also contain a hyperlink representing the invocation of theRequest for Specific Information for display, as specified in this Section.
3.11.3.2.3

1680

1685

Expected Actions

The Display Actor shall render the received response for the user. It shall not assume that thecontent of the document may be meaningfully parsed beyond determination of XHTML tags
necessary for accurate presentation of provided information.
When the summary responses include links to documents or other specific information,
Information Source Actors are strongly encouraged to format them according to the requirements
stated in Sections 3.11 and 3.12, to facilitate retrieval of information from other information
sources.
3.11.3.3 Request For Specific Information - List
3.11.3.3.1

1690

The following event will trigger a Request for Specific Information:• User of the Display Actor needs to review a particular subset of information that is part ofa patient’s clinical history (i.e., lab report, radiology exam report, list of medications,etc.) that is stored on the Information Source system.
3.11.3.3.2

1695

Trigger Events

Message Semantics

The Retrieve Specific Information for Display transaction is performed by the invocation of a
web service. The Display Actor shall generate a web service request whenever a user needs toreview the information stored as part of a patient’s clinical history on the Information Source
Actor.
To specify the type of information to be returned, a web service request shall include thefollowing parameters (keys) to filter the subset of information (See Table 3.11.4-7). All
parameter names and values (see Table 3.11.4-7) are case-sensitive.

1700

Table 3.11.4-6 Web Service Request Keys
Parameter
Name

REQ

requestType

R

Description
requestType specifies what type of
information shall be retrieved. Thisparameter shall always be valued.

Notes
See Table 3.11.4-7 for the list of possible values.

__________________________________________________________________________
71
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Parameter
Name

REQ

patientIDR

Description

Notes

This attribute identifies the subject of
the results being queried for. Its value
shall include identification of assigningauthority.

PatientID value shall be formatted as HL7 CX data
type (including assigning authority) according to
the requirements specified for the Patient Identity
Feed transaction (see Section 3.8.4.1.2.3)

Table 3.11.4-7 Web Service Request TypesrequestType value

Description

LIST-ALLERGIES

List of allergies and adverse reactions for a patient known to the Information Source

LIST-MEDS

List of medications currently taken by or administered to a patient

Formal definition of the web service in WSDL is provided in the Appendix A.
1705

The only binding required for both Display Actor and Information Source Actor is the binding to
the HTTP-GET. In this binding the sample message will be formatted as follows:
http://<location>/IHERetrieveListInfo?requestType=LISTMEDS&patientID=99998410^^^%26www.mlhlife.com%26DNS

1710

The <location> part of the URL is configurable by the implementation, and must contain the hostname, an optional port address, and may be followed by an optional path. The path if present
may not contain a ‘?’ character. The remainder of the URL, including IHERetrieveListInfo andthe following request parameters are specified by the WSDL and may not be changed. See thediscussion about location in section 3.11.4.1.2 Message Semantics above.
In addition, the Display Actor shall support the following field of the HTTP request:

1715

Table 3.11.4-8 HTTP Request and Response Fields
HTTP Field

REQ

AcceptLanguage

O

Description

ValuesThis field restricts the set of natural languages that are preferred
as a response to the request.

Any valid value according
to RFC2616

The Information Source actor shall support the following field of the HTTP response.
Table 3.11.4-9 HTTP Request Fields
HTTP
Field

REQ

Description

ValuesExpires

R

This field gives the date/time after which
the response is considered stale

Shall be 0. This is now deprecated usage, but it is the
widely supported means of specifying no cacheing.

CacheControl

R

This field indicates that this response
should not be cached.

Shall be no-cache__________________________________________________________________________
72
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

1720

If necessary, the Display Actor may perform the request to the web service utilizing HTTPS
protocol.
•
•

1725

Information Source Actors may return HTTP redirect responses (responses with values of 301, 302,
303 or 307) in response to a request. Display Actors can expect to receive an error response, or thedata requested, or a request to look elsewhere for the data. A Display Actor must follow redirects, but
if a loop is detected, it may report an error.

3.11.3.3.3

Expected Actions

Upon reception of the Request for Specific Information, the Information Source Actor shall parsethe request and if there are no errors, shall return the Response with Specific Information as
specified in Section 3.11.4.2, and HTTP response code 200 - OK.
1730

1735

If the requestType specified is not supported, the Information Source Actor shall return HTTP
response-code 404 (not found) with the suggested reason-phrase “requestType not supported”. If
the Information Source Actor is not able to format the document in any content types listed in the'Accept' field, it shall return HTTP response code 406 – Not Acceptable.
If the Patient ID specified by the Display Actor is not known to the Information Source Actor, it
shall return HTTP response-code 404 (not found) with the suggested reason-phrase “Patient ID
not found”. If the Display Actor provides the Patient ID from a different domain than the one theInformation Source Actor belongs to, and the Information Source Actor is grouped with thePatient ID Consumer Actor, it may attempt to obtain a mapping of the provided Patient ID into
its domain before responding.

1740

1745

Note: Other HTTP response codes may be returned by the Information Source Actor, indicating conditions outsideof the scope of this profile, for example, 401 – Authentication Failed might be returned if Information
Source Actor is grouped with the Kerberized Server Actor.
Note: It is recommended that the Information Source Actor complement returned error code with a humanreadable description of the error condition.

If an error condition cannot be automatically recovered, at a minimum, the error should be
displayed to the user by the Display Actor.
3.11.3.4 Response with Specific Information - List
3.11.3.4.1
1750

Trigger Events

This message is sent by the Information Source Actor in response to the Request For SpecificInformation web service request.

__________________________________________________________________________
73
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.11.3.4.2

Message Semantics

Information Source Actor shall support at least one of the values of the requestType parameter
specified in Table 3.11.4-7.
1755

1760

The Information Source shall set an expiration of zero to ensure no caching. The message shallbe formatted using XHTML Basic and W3C HTML Compatibility Guidelines provided in the
Appendix C of the W3C XHTML 1.0 Recommendation.
The Display Actor may request the Information Source Actor to provide a list of information
items (pertaining to a particular patient) that the Information Source has presently recorded. The
exact content of the list is determined by the Information Source Actor.
The Display Actor shall not use the lowerDateTime, upperDateTime or mostRecentResultsparameters in a query. The Information Source shall ignore them if they are specified.
3.11.3.4.3

1765

Expected Actions

The Display Actor shall render the received response for the user. It shall not assume that thecontent of the document may be meaningfully parsed beyond determination of XHTML tags
necessary for accurate presentation of provided information.

__________________________________________________________________________
74
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.12 Retrieve Document for Display
This section corresponds to Transaction ITI-12 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-12 is used by the Information Source and Display actors.
1770

3.12.1 Scope

1775

This transaction involves the retrieval of a document (persistent object) for presentation purposes.
The uniquely identifiable persistent object means that retrieving the same document instance at adifferent point in time will provide the same semantics for its presented content. The information
content of the document is immutable even if the presentation of such content is provided withthe use of different formats, stylesheets, etc.
3.12.2 Use Case Roles

Display

Information Source

Retrieve Document
for Display

Actor: Display
1780

Role: A system that requests a document/object for display, and displays it.
Actor: Information Source
Role: A system that provides specific information in response to the request from the Display
Actor, in a presentation-ready format.
3.12.3 Referenced Standards

1785

IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001.
http://www.w3.org/TR/wsdl.

__________________________________________________________________________
75
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1790

3.12.4 Interaction Diagram
Display

Information
SourceRequest for Persistent Document
Delivery of Persistent Document

Figure 3.12-1 Request for Persistent Document Sequence

3.12.4.1 Request for Persistent Document
3.12.4.1.1
1795

The request for a document is triggered when a user of the Display Actor needs to review aparticular document that is stored by the Information Source Actor.
3.12.4.1.2

1800

Trigger Events

Message Semantics

The Retrieve Document for Display transaction is performed by the invocation of a web service.
The Display Actor shall generate the web service request whenever a user needs to review the
document stored as part of a patient’s clinical history on the Information Source Actor.
The web service request shall include the following parameters (keys) to identify the document
to be returned and its format See Table (3.12.4-1). All parameter names and values are casesensitive.
Table 3.12.4-1 Query Keys
Parameter Name

REQ

Description

ValuesrequestType

R

This parameter is required to have avalue of DOCUMENT.

DOCUMENT

documentUID

R

Identifies document’s UID as known toboth actors.

This value shall be a properly defined Object
identifier (OID) as specified in Volume 2,
Appendix B.

preferredContentType

R

This parameter is required to identify
the preferred format the document is tobe provided in (as MIME contenttype).

Display may specify one of the following
formats:
image/jpeg
application/x-hl7-cda-level-one+xml (seenote)
application/pdf (see note)__________________________________________________________________________
76
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1805
Note: see IANA registry for details about hl7-cda-level-one and PDF, such as version. Applications creating PDF
may use this MIME type for other versions of PDF up to 1.3. Receivers shall support document encodedin this version and previous versions.
Note: see HL7 CDA framework release 1.0 for details about application/x-hl7-cda-level-one+xml.

1810
Formal definition of the web service in WSDL is provided in Appendix A.
The only binding required for both the Display Actor and Information Source Actor is thebinding to the HTTP-GET. In this binding the sample message will be formatted as follows:1815

http://<location>/IHERetrieveDocument?requestType=DOCUMENT&documentUID=1.2.3&preferredContentType=application%2fpdf

1820

The <location> part of the URL is configurable by the implementation, and must contain the hostname, an optional port address, and may be followed by an optional path. The path if present
may not contain a ‘?’ character. The remainder of the URL, including IHERetrieveDocument
and the following request parameters are specified by the WSDL and may not be changed. See
the discussion about location in section 3.11.4.1.2 Message Semantics above.
In addition, the Display Actor shall support the following fields of the HTTP request:
Table 3.12.4-3 HTTP Request and Response Fields
HTTP
Field
AcceptREQ

Description

ValuesOThis field may be used to specify certain media
types which are acceptable for the response

At least one of the following values:
image/jpeg
application/x-hl7-cda-level-one+xml
application/pdf*/*
Other values may be included as well

AcceptLanguage

O

This field is similar to Accept, but restricts theset of natural languages that are preferred as a
response to the request.

Any valid value according to RFC2616

Expires

R

This field gives the date/time after which the
response is considered stale

Any valid value according to RFC2616, or 0

The Information Source actor shall support the following field of the HTTP response.
1825

Table 3.12.4-4 HTTP Response Fields
HTTP
Field
Expires

REQ

Description

ValuesR

This field gives the date/time after which the
response is considered stale

Any valid value according to RFC2616, or 0__________________________________________________________________________
77
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________The Display Actor may provide list of content types it supports in the HTTP Accept field. If the
HTTP Accept Field is absent, it means that any content type is acceptable by the Display Actor.

1830

The preferredContentType parameter shall specify the content type desired by the Display Actor.
The value of the preferredContentType parameter of the request shall be one of the values fromthe Table 3.12.4-1 and shall not contradict values specified in the HTTP Accept field.
The Information Source shall provide info in preferredContentType if capable, otherwise it shall
only use a type specified in the Accept Field as appropriate given the information to be returned.
If necessary, the Display Actor may perform the request to the web service utilizing HTTPS
protocol.

1835

•
•

1840

Information Source Actors may return HTTP redirect responses (responses with values of 301, 302,
303 or 307) in response to a request. Display Actors can expect to receive an error response, or thedata requested, or a request to look elsewhere for the data. A Display Actor must follow redirects, but
if a loop is detected, it may report an error.

3.12.4.1.3

Expected Actions

Upon reception of the Request for Specific Information, the Information Source Actor shall parsethe request and shall return the retrieved document as specified in Section 3.12.4.2, and HTTP
response code 200 - OK.
1845

If the requestType specified is a not a legal value according to this profile, the Information
Source Actor shall return HTTP response-code 403 (forbidden) with the suggested reason-phrase“requestType not supported”.
If the Information Source Actor is not able to format the document in any content types listed in
the 'Accept' field, it shall return HTTP response code 406 – Not Acceptable.

1850

If the specified documentUID is not known to the Information Source Actor, it shall return
HTTP response-code 404 (not found) with the suggested reason-phrase “Document UID not
found”.
If the documentUID, preferredContentType or requestType parameters are missing, theInformation Source Actor shall return HTTP response code 400 - Bad Request.

1855

If the documentUID or preferredContentType parameters are malformed, the Information Source
Actor shall return HTTP response code 400 - Bad Request.
If the specified preferredContentType is not consistent with the setting of the HTTP Accept field,
the Information Source Actor shall return HTTP response code 400 – Bad Request.

1860

Note: Other HTTP response codes may be returned by the Information Source Actor, indicating conditions outsideof the scope of this profile, for example, 401 – Authentication Failed might be returned if Information
Source Actor is grouped with the Kerberized Server Actor.

__________________________________________________________________________
78
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Note: It is recommended that the Information Source Actor complement returned error code with a humanreadable description of the error condition.

1865

If an error condition cannot be automatically recovered, at a minimum, the error should be
displayed to the user by the Display Actor.
3.12.4.2 Delivery of Persistent Document
3.12.4.2.1

1870

The Delivery of Persistent Document message is the transmission of the requested document inspecified format from the Information Source Actor to the Display Actor. This transmission will
happen if such document, identified by the documentUID parameter in the request, has beensuccessfully located by the Information Source Actor.
3.12.4.2.2

1875

Trigger Events

Message Semantics

In response to the request from the Display Actor, the Information Source Actor shall format the
document according to the preferredContentType specified, and return it in the HTTP response.
See Section 3.12.4.1.2 for a discussion of the rules related to preferredContentType.
The Information Source Actor shall maintain global uniqueness of object identifiers.
The Information Source Actor shall set an expiration date compatible with the policies associatedwith the possible removal of instances of persistent documents (no more than a week).
3.12.4.2.3

1880

Expected Actions

The Display Actor shall render the received document for the user.

__________________________________________________________________________
79
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.13 Follow Context

1885

This section corresponds to Transaction ITI-13 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-13 is used by the Patient Context Participant, User Context
Participant and Context Manager Actors.
3.13.1 Scope
This transaction allows the Context Manager Actor to force other context participant actors tosynchronize based on the new context values.

1890

1895

1900

This transaction is composed of multiple methods as defined by the HL7 Context Management“CCOW” Standard. It has multiple phases consisting of surveying the participants, indication tothem of final decision as to whether the context changed or not, and retrieval of the new context
values by the context participants.
Each of the context participant actors follows a specific subject. The Patient Context Participant
Actor follows the patient subject and does not expect the user subject to be set in context. The
User Context Participant follows the user subject.
The semantics of the methods used are defined in the documents HL7 Context Management“CCOW” Standard: Component Technology Mapping: ActiveX or HL7 Context Management“CCOW” Standard: Component Technology Mapping: Web, in conjunction with the HL7
Context Management “CCOW” Standard: Subject Data Definitions document. A Context
Participant Actor can implement either technology. The Context Manager Actor shall support
both technologies in order to interoperate with joining participants implementing the technologyof their choice.

__________________________________________________________________________
80
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.13.2 Use Case Roles
Patient Context
Participant Actor

User Context
Participant Actor

Follow Context

Context
Manager Actor

1905

Actor: Patient Context Participant
Role: Responds to context survey. Synchronizes display to new value(s) in the patient subject ofa context it follows.
Actor: User Context Participant

1910

Role: Responds to context survey. Synchronizes display to new value(s) in the patient subject ofa context it follows.
Actor: Context Manager
Role: Conducts context survey, notifies the context participants of acceptance or cancellation ofa change, and provides context values.
3.13.3 Referenced Standard

1915

HL7 Context Management “CCOW” Standard, Version 1.4
Technology and Subject Independent Architecture
Component Technology Mapping: ActiveX
Component Technology Mapping: Web
Subject Data Definitions__________________________________________________________________________
81
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1920

3.13.4 Interaction Diagram
Patient Context
Participant Actor
orUser Context ParticipantContext
Manager
Actor

ContextChangesPending
ContextChangesAccepted
ContextChangesCancelled
GetItemValues

Figure 3.13-1 Follow Context – ContextChangesPending Method Sequeice

3.13.4.1 Follow Context – ContextChangesPending Method
1925

The ContextChangesPending method is invoked by the Context Manager Actor to survey context
participant actors with regard to acceptability of changes proposed by a Patient Context
Participant or Client Authentication Agent Actors.
3.13.4.1.1

Trigger Events

The ContextChangesPending method is triggered when the Context Manager receives invocationof the EndContextChanges method.
1930

3.13.4.1.2

Message Semantics

ContextChangesPending is defined as a method on the ContextParticipant interface and allows
the Context Manager to survey a context participant as to whether or not it is ready to follow thechanges in the context.
1935

In the invocation of this method, the Context Manager shall provide the pending context’s
coupon.
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.7.2, for a description of the parameters
associated with this method.

__________________________________________________________________________
82
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.13.4.1.3
1940

1945

Expected Actions

Performing the ContextChangesPending method, the Patient Context Participant or User Context
Participant Actor makes a decision whether or not it can accept change of context (for example
due to operation being in progress). To reach this decision, it may invoke the GetItemValues
method to inspect proposed new values in the context.
As a response, a Context Participant Actor will respond with an indication to Accept orConditionally Accept the proposed change. Refer to the HL7 Context Management “CCOW”
Standard: Technology and Subject-Independent Architecture document, Section 17.3.7.2, for the
specifics of the response formation.
3.13.4.2 Follow Context – ContextChangesAccepted Method

1950

The ContextChangesAccepted method is invoked by the Context Manager Actor to confirm tothe context participants that instigator of change accepted proposed changes.
3.13.4.2.1

Trigger Events

The ContextChangesAccepted method is triggered when the Context Manager receives
invocation of the PublishChangesDecision method indicating that the changes have been
accepted.
1955

3.13.4.2.2

Message Semantics

ContextChangesAccepted is defined as a method on the ContextParticipant interface and allows
the Context Manager to inform a context participant that the context value(s) have been changed.
In the invocation of this method, the Context Manager provides the new context coupon.
1960

Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture, Section 17.3.7.3 for a description of the parameters associated withthis method.
3.13.4.2.3

1965

Expected Actions

Performing the ContextChangesAccepted method, the Patient Context Participant or User
Context Participant Actor accepts new context and can subsequently retrieve new values using
the GetItemValues method.
It responds with confirmation of success or an exception. Refer to the HL7 Context Management“CCOW” Standard: Technology and Subject-Independent Architecture document, Section
17.3.7.3, for the specifics of the response formation.

__________________________________________________________________________
83
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.13.4.3 Follow Context – ContextChangesCancelled Method
1970

The ContextChangesCancelled method is invoked by the Context Manager Actor to inform thecontext participants that instigator of change cancelled proposed changes.
3.13.4.3.1

1975

Trigger Events

The ContextChangesCancelled method is triggered when the Context Manager receives
invocation of the PublishChangesDecision method indicating that the changes have beencancelled.
3.13.4.3.2

Message Semantics

ContextChangesCancelled is defined as a method on the ContextParticipant interface and allows
the Context Manager inform a context participant that the pending context change has beencancelled.
1980

In the invocation of this method, the Context Manager provides the pending context’s coupon.
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture, Section 17.3.7.4 for a description of the parameters associated withthis method.
3.13.4.3.3

1985

1990

Expected Actions

Performing the ContextChangesCancelled method, the Patient Context Participant or User
Context Participant Actor keeps its current context and destroys information about a pending
context change that has been cancelled.
It responds with confirmation of success or an exception. Refer to the HL7 Context Management“CCOW” Standard: Technology and Subject-Independent Architecture document, Section
17.3.7.4, for the specifics of the response formation.
3.13.4.4 Follow Context – GetItemValues Method
The GetItemValues method is invoked by a Context Participant Actor to retrieve value(s) fromthe context it follows.
3.13.4.4.1

1995

Trigger Events

The GetItemValues method is triggered by a Context Participant Actor after it receives thecontext coupon as a result of the ContextChangesPending, ContextChangesAccepted or
GetContextCoupon methods.

__________________________________________________________________________
84
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.13.4.4.2
2000

2005

2010

Message Semantics

GetItemValues is defined as a method on the ContextData or SecureContextData interface. If thecontext is not secured when a participant actor has joined the context (i.e., Patient Context
Participant that only follows patient context), then this method should be invoked on theContextData interface. Otherwise, it shall be invoked on the SecureContextData interface.
By invocation of this method without specification of the list of item names, a context participant
retrieves values of all items presently set in context. It can also first invoke the GetItemNames
method on the same interface (as specified in CCOW Standard) and use the list of items forselective retrieval of item values from the context via GetItemValues method. The Patient
Context Participant needs to search through the resulting list of Patient.Id.IdList.<n> values until
a recognized Patient Domain is found. The Patient Context Participant may choose to be groupedwith a PIX Patient Identifier Cross-reference Consumer to handle the cases where no known
Patient Domain is found in the resulting IdList.
Refer to the HL7 Context Management “CCOW” Standard: Technology and SubjectIndependent Architecture document, Section 17.3.4.5, for the Patient Context Participant Actor,
and Section 17.3.13.2, for the User Context Participant, for a description of parameters
associated with this method.

2015

3.13.4.4.3

Expected Actions

2020

Context Manager shall return the values of requested items or an exception. Refer to the HL7
Context Management “CCOW” Standard: Technology and Subject-Independent Architecture
document, Section 17.3.4.5, for the Patient Context Participant Actor, and Section 17.3.13.2, for
the User Context Participant, for a description of the response issued by the Context Manager
Actor.

__________________________________________________________________________
85
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.14 Register Document Set
This section corresponds to Transaction ITI-14 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-14 is used by the Document Repository Actor to register a set of
documents with the Document Registry.
2025

3.14.1 Scope
The Register Document Set transaction passes a Submission Request from a Document
Repository Actor to a Document Registry Actor.
A Register Document Set transaction carries:
Metadata describing zero or more documents

2030

XDS Submission Set definition along with the linkage to new documents and references toexisting documents
XDS Folder definitions along with linkage to new or existing documents
3.14.2 Use Case Roles
Document
Repository

Document
Registry

RegisterDocument Set

2035
Actor: Document Repository
Role: A document storage system that submits document metadata to a Document Registry.
Actor: Document Registry
Role: A document indexing system that receives and stores document metadata.
2040

3.14.3 Referenced Standards
ebRIM OASIS/ebXML Registry Information Model v2.0
ebRS OASIS/ebXML Registry Services Specifications v2.0
HTTP HyperText Transfer Protocol HTTP/1.1 (IETF RFC2616)__________________________________________________________________________
86
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________CDA HL7 Clinical Document Architecture (ANSI/HL7 CDA R1-2000)
2045

HL7V2

HL7 Version 2.5

3.14.4 Interaction Diagram
Document
Repository

Document
Registry

Register Document Metadata

Register Document Metadata
Acknowledgment

3.14.4.1 Register Document Metadata
The Document Repository sends metadata for a set of documents to the Document Registry.
2050

3.14.4.1.1

Trigger Events

The Register Document Metadata message is triggered when:

2055

1.

A Document Repository wants to register metadata for a set of documents it holds.

2.

A Document Repository receives a Provide and Register Document Set transaction (ITI15)

3.14.4.1.2

Message Semantics

The following sections specify the mapping of XDS concepts to ebRS and ebRIM semantics:
XDS Document
XDS Submission Request
XDS Submission Set
2060

XDS Folder
Document Relationships
Metadata definitions to support the above are discussed as follows:
XDS Document__________________________________________________________________________
87
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDS Submission Request
2065

XDS Submission Set
XDS Folder
In addition the following topics are discussed:
Protocol requirements
XDS registry adaptor function

2070

General metadata issues
Security requirements
Sequencing Requirements
3.14.4.1.2.1 Class Diagram
ExtrinsicObject

XDSDocumentEntry

2075

2080

ebXML ebRIM
Classes

RegistryPackage«type»XDSSubmissionSet«type»XDSFolder

XDS
ClassesFigure 3.14.4.1-1 ebXML Class Diagram of the Register Document Metadata

The XDSDocumentEntry class is derived from the ebXML ExtrinsicObject class. The
XDSSubmissionSet and XDSFolder classes are derived from the ebXML1 RegistryPackage class.
Since the ebXML Registry standard does not allow for subclassing the RegistryPackage class,these two classes are implemented as ebXML RegistryPackages. Type information (submission
set vs. folder) is coded as an ebXML Classification against two object types created by the XDS
profile, XDSSubmissionSet and XDSFolder.
3.14.4.1.2.2 Document Specification

2085

A new registry object type is declared as a subclass of ebXML ExtrinsicObject. Its name is
XDSDocumentEntry. An object of this type in the XDS registry is used to represent a document
in an XDS repository.

1

ebXML Registry terms such as RegistryPackage are shown with an ebXML prefix to help distinguish ebXML
Registry terms from XDS terms. Unless otherwise indicated, references to ‘ebXML’ in XDS refer to the ebXML
Registry specifications as opposed to other ebXML specifications. The short term is used for readability.

__________________________________________________________________________
88
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________An XDSDocumentEntry object in the registry contains a reference to a single document in asingle repository.
Note: A repository may hold documents that are not indexed in the registry.

2090

Appendix H defines the metadata to initialize an ebXML registry to serve as an XDS Document
Registry.
3.14.4.1.2.3 XDS Submission Request Specification
A Submission Request is the collection of information that is transferred to an XDS Document
Registry or Repository.

2095

There are two types of submission requests: XDS Registry Submission Request and XDS
Repository Submission Request. Both are described below.
Appropriate protocol bindings are used to transfer this content between systems when the actors
are not implemented together on the same system. The bindings are described in section
3.14.4.1.2.11.
The two types of XDS Submission Requests are described next.

2100

3.14.4.1.2.3.1

XDS Registry Submission Request

2105

An XDS Registry Submission Request is the collection of metadata transferred between a
Document Repository and a Document Registry in a single ebXML SubmitObjectsRequest. This
request contains:• A collection of metadata to be stored in the registry including:• Metadata for new documents• Folders to be created• Documents to be added to folders• A single XDS Submission Set, contained within the metadata, organizing the metadataThis request is part of the Register Document Set transaction.

2110

2115

3.14.4.1.2.3.2

XDS Repository Submission Request

An XDS Repository Submission Request is the collection of metadata and documents transferred
between a Document Source and a Document Repository using a single ebXML
SubmitObjectsRequest. This request contains:•
Metadata•
Zero or more documents; each document is represented by an XDSDocumentEntry object
in the metadata. Submissions that add metadata to the registry without adding documents
to the repository are possible.
__________________________________________________________________________
89
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
This request is the information payload of the Provide and Register Document Set message of
the Provide and Register Document Set transaction ITI-15.
2120

Unless otherwise stated, the XDS Submission Set requirements specified hereafter apply to bothtypes of XDS Submission Requests
3.14.4.1.2.3.3

2125

Atomicity Requirements for XDS Submission Requests

XDS Submission requests shall be atomic operations. The result of a Submission Request is to
update either:•a Registry or•
a Registry and a Repository.
All changes requested are successfully applied or no net changes are made. More specifically:2130

1. Atomicity shall be managed by an XDS registry adaptor. (see section 3.14.4.1.2.12 fordetails on registry adaptor.addressing the fact that the ebXML Registry specification does
not guarantee that a SubmitObjectsRequest is atomic). XDS specifies the mechanism
through which atomicity is to be implemented and where it is needed.

2135

2. All objects shall have their Status attribute set to Submitted when the objects are firstcreated in the ebXML registry. An ebXML ApproveObjectsRequest, shall be issued
within the XDS Registry Adaptor to change the Status attribute to Approved. This
completes the transaction.

2140

3. The following types of objects shall be have their status set to Approved to be consideredpublicly available:• XDSSubmissionSet (ebXML RegistryPackage)• XDSFolder (ebXML RegistryPackage)• XDSDocumentEntry (subclass of ebXML ExtrinsicObject)
If an error occurs storing documents in the repository then all documents stored as part of theRepository Submission Request shall be removed.

2145

2150

If an error occurs storing metadata in the registry, then the following actions are performed:• All metadata stored as part of the Registry Submission Request shall be removed
from the registry• All documents stored as part of the Repository Submission Request shall be
removed. This only applies if the Registry Submission Request is a result of a
Repository Submission Request.
Registry queries from the Registry Query transaction shall not find XDS Submission Sets,
XDS Folders or XDSDocumentEntry objects until after the above atomic operation thatcreates them has completed successfully and the status attributes have been set toApproved.
__________________________________________________________________________
90
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.14.4.1.2.3.4
2155

2160

A Submission Request may contain metadata beyond the XDS Submission Set, XDS Folder, andXDSDocumentEntry objects. These are:•ebXML Associations linking XDSDocumentEntry objects to XDSFolder objects. There
are no restrictions on whether the XDSDocumentEntry objects or XDSFolder objects arein this Submission Request. Such an Association is the ebXML mechanism for including
objects in an ebXML RegistryPackage (the basis of XDSFolder).
•Associations linking existing (already contained in the registry) XDSDocumentEntry
objects to the XDSSubmissionSet RegistryPackage contained in this Submission Request.
This option is discussed in the next section.
3.14.4.1.2.3.5

2165

Other Properties of Submission Requests

Attribute Size

All attribute values shall conform to the size specification of ebRIM version 2.1 that is detailed
in section 7.2 Data Types of that specification. More specifically, all Slots shall conform to thespecification of ebRIM version 2.1, which is detailed in section 7.6.1 of that specification. The
version 2.0-ebRIM specification is overly limiting in this respect. Without adopting the newer
size limits, many typical patient record values could not be encoded.
3.14.4.1.2.4 Submission Set Specifications

2170

2175

Submission Sets exist for two reasons:1.

To support atomic submission to the registry3.

To make a permanent record in the registry of• The existence and status of the submission• The XDS Folders and XDSDocumentEntry objects included in the submission.

An XDS SubmissionSet is an ebXML RegistryPackage, classified as XDSSubmissionSet that isused to bundle XDSDocumentEntry objects.
A Submission Set has a set of attributes that are described in section 3.14.4.1.2.8 Submission Set
Metadata.

2180

Documents may be included in a Submission Set in two ways: inclusion by value and inclusion
by reference.
Inclusion by value: A new document is being submitted to the registry. The Submission Set
contains the XDSDocumentEntry object with associated attributes.

2185

Inclusion by reference: Existing documents in the registry can be referenced by a Submission
Set. These documents are included because of their clinical relevance to the rest of theSubmission Set.
__________________________________________________________________________
91
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Linking document metadata to submission set: An XDSSubmissionSet shall be represented byan ebXML RegistryPackage. Document metadata (XDSDocumentEntry objects) shall be linked
to the RegistryPackage via ebXML Associations according to the ebXML Registry standard.
2190

2195

2200

For documents included by reference, the Submission Request shall include the Association
object used to link the document. For documents included by value, the Submission Request
shall include the XDSDocumentEntry object and the Association object used to link the
document.
Submission Set Association labeling: Two types of association labels are defined: original(submission by value), or reference (Submission by reference). This allows finding thesubmission set that first submitted any document. It also supports proper rollback in case of a
submission error. For document metadata included by value, a rollback of the submission shalldelete the document metadata and the association. For document metadata included by reference,a rollback of the submission shall not delete the document metadata but shall still delete theassociation. (The document whose association is being deleted existed before this submission
and shall be maintained.) The following labeling of the Associations is required.
.Table 3.14.4.1-1 Submission Set Association Labeling
Inclusion typeRollback

Association Labeling

By Value

Yes

Slot: Name=SubmissionSetStatus
Value=Original

By ReferenceNo

Slot: Name=SubmissionSetStatus
Value=Reference

2205

2210

2215

Submission Sets and patients: A Submission Set is restricted in terms of mixing documentsfrom different patients. All documents included by value in a Submission Set shall have theirpatientId attribute set to the same value. This restriction does not apply to documents included byreference.
Document metadata duplication: There are several conditions regarding the duplication of
document metadata that can occur.
• Duplicate registration of a document - A document and its metadata are submitted to therepository as part of a Repository Submission Request. This document already exists in one
or more repositories and is already represented in the registry. It is submitted with a new (notpreviously used) UUID for the XDSDocumentEntry and associated ancillary objects. The
registry shall accept such duplicate registration of the documents.
• Duplicate document id submitted to repository - A document with its associated metadata ispart of a Repository Submission Request. A document with the same
XDSDocumentEntry.uniqueID is present in the repository but the XDSDocumentEntry.hashis different. This is an error and the Submission Request shall be rejected by the repository.
__________________________________________________________________________
92
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Note: There are two approaches to detecting this fault. First, this can be detected at the repository if repository
logic can validate the hashes and has record of the document id to compare. Otherwise the request canbe forwarded on to the registry and let the fault be detected by the registry (see next bullet). The
repository then deals with the error returned by the registry.

2220
•

2225

2230

Duplicate document ID submitted to registry - Metadata representing a document(XDSDocumentEntry) is part of a Registry Submission Request. An XDSDocumentEntry
object with the same uniqueID is present in the registry but, the hash is different. This is anerror and the Submission Request shall be rejected by the XDS registry adaptor.

3.14.4.1.2.5 Folder Specification
An XDS Folder is an ebXML RegistryPackage classified as XDSFolder. This folder is used tobundle XDSDocumentEntry objects. Folders shall not be nested inside other folders. The
patientId attribute of the XDSDocumentEntry objects it contains shall match the patientId
attribute on the folder itself. This shall be enforced by the Registry Actor.
Note: The nesting of folders may be considered as a future extension to this transaction.

3.14.4.1.2.6 Document Relationships and Associations
3.14.4.1.2.6.1

2235

Document Relationships from HL7

Relationships between documents can be established with XDS. XDS adopts the document
relationship semantics defined in HL7 CDA. The supported relationships are listed below inTable 3.14.4.1-2. The semantics behind each of these relationships are documented in HL7 CDA
Release 2, Committee Ballot 2.
To create a document relationship in the registry, submit:
A new document (XDSDocumentEntry)
An Association linking the new document to an existing document.

2240

2245

The association type defines the document relationship. The new document and the associationmust be submitted in the same Submission Set. The existing document must be an Approved
object already in the registry. The identity (registry UUID) of the existing document must be
discovered via registry query.
The association types used for document relationships are defined by XDS and an XDS Registrymust be initialized with their definitions. See Appendix H for details.
Table 3.14.4.1-2 Document Relationships

Relationship

Definition

APND (append)

The current document is an addendum to the parent document.

RPLC (replace)

The current document is a replacement of the parent document.

__________________________________________________________________________
93
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XFRM (transform)

The current document is a transformation of the parent
document.

XFRM_RPLC(transform withreplace)

The current document is both a transformation and areplacement of the parent document.
Adapted from HL7 CDA Release 2, Committee Ballot 2

2250

2255

2260

2265

2270

A Document Relationship refers to any of the relationships listed in Table 3.14.4.1-2 above.
Section 3.15.5.1 documents for the Document Source which of these operations are required andoptional.
A Document Source actor creates a document relationship by submitting a Submission Set
containing:
XDSDocumentEntry – this defines the new document being submitted• The uniqueId attribute must be unique.
• The UUID must be unique or symbolic (the registry assigns)
Association – this links the original XDSDocumentEntry (already in the registry) with the
new XDSDocumentEntry being submitted.
• The targetObject attribute of the Association object references the existing documentin the registry.
• The sourceObject attribute of the Association object references the
XDSDocumentEntry contained in the Submission Set.
• The Association Type is one of the relationships in table 3.14.4.1-2.
The targetObject attribute of the Association is the registry UUID representing the existing
document in the registry. This UUID must be discovered via registry query.
The existing document shall be deprecated by the following rules (based on CDA R2):
• The APND and XFRM relationships leave the original document with its status
unchanged (Approved).
• The RPLC and XFRM_RPLC relationships change the status of the original document toDeprecated.
The Registry Adaptor manages document deprecation. See section 3.14.4.1.2.12 XDS Registry
Adaptor for details.

2275

Table 3.14.4.1-3 lists all metadata associated with XDSDocumentEntry objects. The attribute
XDSDocumentEntry.parentDocumentId is a reference to the targetObject attribute of the new
Association. The attribute XDSDocumentEntry.parentDocumentRelationship is a reference to__________________________________________________________________________
94
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
the Assocition Type. This represents two distinct naming conventions, HL7 CDA and ebXML
Registry.
Document relationship metadata may coexist with other metadata in a Submission Set.
2280

The new document (related to original document by RPLC, APND, XFRM, or XFRM_RPLC
Associations) are assigned their own uniqueId attribute unrelated to the original document’s.
See ITI Vol-1: 10.4.11.1 for further detail on the use and meaning of document relationships.
3.14.4.1.2.6.2

2285

2290

Association type signs

An ebRIM Association with associationType of signs shall be used to link an
XDSDocumentEntry representing a Digital Signature with the XDSDocumentEntry representing
the document being signed. Details of how Digital Signatures are represented in XDS are foundin the Document Content Profile on Digital Signatures. In constructing this association, theattributes are:sourceObject: references the XDSDocumentEntry representing the Digital SignaturetargetObject: references the XDSDocumentEntry representing the document being signed
associationType: signs
Other requirements on the use of this Association may exist in the Document Content Profile on
Digital Signatures.
3.14.4.1.2.7 Document Definition Metadata

2295

Several data types are used in the tables below describing the document metadata. These datatypes are derived from other standards, and encoded in the registry as described in the following
table.
For the data types derived from HL7 standards, XDS requires that the default HL7 separators be
used to represent the structure of HL7 V2 data types:
Field Separator|

Component Separator^

Subcomponent Separator&

Repetition Separator~

2300
Table 3.14.4.1-3 Data Types

XDS Data Type

SourceStandard

Encoding SpecificationCX

HL7 V2This is an identifier. HL7 Identifier type CX consist of__________________________________________________________________________
95
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Identifier

several components, but this specification restricts themto the use of two components, the ID Number, and theAssigning Authority (AA). The Assigning Authority
identifies the "domain" over which the ID Number
represents a unique entity. Furthermore, the AA isrepresented using a Universal ID and Universal ID
Type. In XDS specification, ISO Object Identifiers (seeOID below) must be used as Universal ID. Therefore,
Universal ID Type is always ISO. The required format
is:
IDNumber^^^&OIDofAA&ISO
An explicit example is:543797436^^^&1.2.840.113619.6.197&ISO

Note that the '&' character must be properly encoded in
the XML content. See the examples in the tables below
for the appropriate representation.
DTM

HL7 V2
Date Time

This is a date/time value, represented as precisely as
possible. All date time values in the registry are stored
using universal coordinated time [UTC].
"UTC" implies that the source and the consumer shallconvert the time from/to the local time.
The format of these values is defined as the following
regular expression:
YYYY[MM[DD[hh[mm[ss]]]]]
The following are legal date time values with increasing
precision representing the date and time January 2,
2005, 3:04:05am
2005
200501
20050102
2005010203
200501020304
20050102030405

OID

ISO Object
Identifier

An ISO Object identifier. Limited in length to 64
characters, and made up of characters from the set[0-9.]. It must start with an integer, and is followed by
one or more additional integer values, separated byperiods. Integers are represented without leading 0
digits unless the value is zero.
1.3.6.1.4.1.21367.2005.3.7__________________________________________________________________________
96
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________In the attribute tables below, when an OID format is
specified, it shall follow the assignment and format rules
defined for document UID in ITI TF-2 : Appendix B
Field

HL7 V2Message
Segment

Specified as the Field identifier, followed by a pipe (|)
and then the data value represented with corresponding
HL7 V2 data type as defined in HL7 standard. Note that
if a HL7 data type is used to derive XDS data type (asshown in this table), the derived XDS data type shall be
used to represent the value.
An example of field Patient Identifier List (the third
field of PID segment) is as follows:
PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7& ISO

URI

UUID

XCN

Uniform
Resource
Identifer

See RFC 2616

Universally
UniqueIdentifier

A DCE Universally Unique Identifier, represented inregistry attributes using the URN syntax for UUIDs:

HL7 V2
Extended
Person Name

This includes the ID Number and Name of a person,
specified with first 6 components of the HL7 data type
XCN:

http://www.ihe.net

urn:uuid:9e0110f8-4748-4f1e-b0a8-cecae32209c7

Identifier
Last NameFirst Name
Second and Further Given Names
SuffixPrefixA example of person name with ID number using thisdata type is as follows:
11375^Welby^Marcus^J^Jr. MD^Dr.

XON

HL7 V2
Organization
Name

This is the organization name, specified with the firstcomponent (XON.1) of the HL7 data type XON:
Organization Name
An example of organization name using this data type is
as follows:
Fairview Hospital__________________________________________________________________________
97
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________The source/query column indicates which attributes are required, and whether they may be usedin queries according to the table below.
2305

Table 3.1.14.1-4 Codes for Source/Query Column

Code

MeaningR

Required

R2

Required if Known

O

OptionalP

Not supported in query.

Cp

Computed/Assigned by Repository, required in register transaction.

Cg

Computed/Assigned by Registry

The XDSDocumentEntry object type is created in ebXML Registry by extending the ebXML
Registry ObjectType Classification Scheme2.
2310

The following metadata elements shall be used to describe an XDS Document. They shall be
provided by the Document Repository Actor in the Register Document Set Transaction either
directly if grouped with a Document Source Actor or forwarded from a Provide and Register
Document Set Transaction.
The XDSDocumentEntry.URI shall be supplied by the Document Repository Actor. Its value isdependent on how the repository stores the document.

2315

Each attribute shown below is an attribute on the XDSDocumentEntry object. The attributename is defined with a prefix of the object type of XDSDocumentEntry when referenced byother objects, for example XDSDocumentEntry.patientId.
Table 3.14.4.1-5 Document Metadata Attribute Definition

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

authorInstitution

Represents a specific healthcare facility under which the human and/or
machines authored the document. A specific case is that of homecare.

R2/R

XON

2

The specific requirement in ebRIM that object types be user extendable was introduced after version 2.0.

__________________________________________________________________________
98
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R2/R

XCN

<rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>Fairview Hospital</rim:Value></rim:ValueList></rim:Slot>authorPerson

Represents the humans and/or machines that authored the document within
the authorInstitution. The document author may be the patient itself. This
attribute may be multi-valued.
<rim:Slot name="authorPerson"><rim:ValueList><rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value></rim:ValueList></rim:Slot>authorRole

authorSpecialty

A code that represents the role of the author with respect to thepatient when the document was created.
<rim:Slot name="authorRole"><rim:ValueList><rim:Value>theAuthorRole</rim:Value></rim:ValueList></rim:Slot>
Represents a specific specialty within a healthcare facility under which the human and/or
machines authored the document.

R2/O

R2/O

<rim:Slot name="authorSpecialty"><rim:ValueList><rim:Value>theAuthorSpecialty</rim:Value></rim:ValueList></rim:Slot>availabilityStatus An XDS Document shall have one of two availability statuses:
Approvedavailable for patient care

Deprecatedobsolete

Cg/R

This attribute is always set to Approved as part of thesubmission of new XDS Documents. It may be changed to
Deprecated under the primary responsibility of the Document
Source with possible patient supervision.
Although XDS supports the ability to delete documents, there
is no such state as “the Document Entry is removed” (only anaudit trail is kept if such a deletion is allowed).
This list may be extended in the future.
The example below shows the status attribute, however, this__________________________________________________________________________
99
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R/R

XDS
Affinity
Domainspecific

R/P

XDS
Affinity
Domainspecific

R/P

XDS
Affinity
Domainspecific

attribute is only returned on query, not set during any registryor repository transaction.
<ExtrinsicObject
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="Approved"
mimeType="application/octet-stream"> …

classCodeThe code specifying the particular kind of document (e.g.
Prescription, Discharge Summary, Report). It is suggested that
the XDS Affinity Domain draws these values from a coding
scheme providing a coarse level of granularity (about 10 to
100 entries).
<rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="theDocument"
nodeRepresentation="classCode"><rim:Name><rim:LocalizedStringvalue="classCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

classCodeDisplayName

The name to be displayed for communicating to a human themeaning of the classCode.
See classCode for example.

confidentialityCo The code specifying the level of confidentiality of the XDS
deDocument. These codes are specific to an Affinity Domain.
Enforcement and issues related to highly sensitive documents
are beyond the scope of XDS (see security section). Theseissues are expected to be addressed in later years.
confidentialityCode is part of a codification scheme and value
set enforced by the Document Registry.
<rim:Classification
classificationScheme=__________________________________________________________________________
100
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R/R

DTM

Cg/P

UUID

O/R

XDS
Affinity
Domainspecific"urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument"
nodeRepresentation="confidentialityCode"><rim:Name><rim:LocalizedString value="displayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

creationTime

Represents the time the author created the document in theDocument Source.
<rim:Slot name="creationTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>entryUUID

The globally unique identifier (may be assigned by either by
Source, Repository, or Registry) is primarily intended for use
as a document registry management identifier. It is not meant
to be an external reference for XDS Documents (e.g. in links
within other documents). The uniqueId is meant for that
purpose so that such links remain valid beyond the XDS
Affinity Domain.
In the example below, the entryUUID is a6e06ca8-0c75-40649e5c-88b9045a96f6<rim:ExtrinsicObject mimeType="application/pdf"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">…
eventCodeList

This list of codes represents the main clinical acts, such as a colonoscopy or
an appendectomy, being documented. In some cases, the event is inherent
in the typeCode, such as a "History and Physical Report" in which theprocedure being documented is necessarily a "History and Physical" act.
An event can further specialize the act inherent in the typeCode, such aswhere it is simply "Procedure Report" and the procedure was a"colonoscopy". If one or more eventCodes are included, they shall notconflict with the values inherent in the classCode, practiceSettingCode or__________________________________________________________________________
101
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

O3/P

XDS
Affinity
Domainspecific

R/O

XDS
Affinity
Domainspecific

typeCode, as such a conflict would create an ambiguous situation.
This short list of codes is provided to be used as “key words” for certain
types of queries.
<rim:Classification
classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="eventCode"><rim:Name><rim:LocalizedStringvalue="eventCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

eventCodeDisplayNameList

The list of names to be displayed for communicating to humanreader the meaning of the eventCode.

formatCode

Code globally uniquely specifying the format of the document.
Along with the typeCode, it should provide sufficient
information to allow any potential XDS Document Consumer
to know if it will be able to process the document. The
formatCode shall be sufficiently specific to ensure
processing/display by identifying a document encoding,
structure and template (e.g. for a CDA Document, the fact thatit complies with a CDA schema, possibly a template and the
choice of a content-specific style sheet).

See eventCodeList for an example.

<rim:Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="theDocument"
nodeRepresentation="formatCode"><rim:Name><rim:LocalizedString value="name"/></rim:Name>

3

Required if eventCode has a value.

__________________________________________________________________________
102
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

<rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

hashhealthcareFacilityTypeCode

Hash key of the XDS Document itself. This value is computed Cp/P
by the Document Repository and used by the Document
Registry for detecting the improper resubmission of XDS
Documents.
<rim:Slot name="hash"><rim:ValueList><rim:Value>
da39a3ee5e6b4b0d3255bfef95601890afd80709</rim:Value></rim:ValueList></rim:Slot>
This code represents the type of organizational setting of the clinical encounter during which
the documented act occurred.

R/R

In some cases, the setting of the encounter is inherent in the
typeCode, such as "Diabetes Clinic Progress Note".
healthcareFacilityTypeCode shall be equivalent to or further
specialize the value inherent in the typeCode; for example,
where the typeCode is simply "Clinic Progress Note" and thevalue of healthcareFacilityTypeCode is "private clinic". The
value shall not conflict with the value inherent in the
typeCode, as such a conflict would create an ambiguoussituation.
<rim:Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="theDocument"
nodeRepresentation="healthcareFacilityTypeCode"><rim:Name><rim:LocalizedStringvalue="healthcareFacilityTypeCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>__________________________________________________________________________
103
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

SHA1
hash

XDS
Affinity
Domainspecific

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

healthcareFacilityTypeCodeDisplayName

The name to be displayed for communicating to a human themeaning of the healthcareFacilityTypeCodeSee healthcareFacilityTypeCode for an example.

R/P

XDS
Affinity
DomainspecificlanguageCode

Specifies the human language of character data in the
document. The values of the attribute are language identifiers
as described by the IETF (Internet Engineering Task Force)
RFC 3066.

R/P

This value may further be restricted by the registry according
to XDS Affinity Domain specific policy.
<rim:Slot name="languageCode"><rim:ValueList><rim:Value>en-us</rim:Value></rim:ValueList></rim:Slot>legalAuthenticat
orRepresents a participant who has legally authenticated or attested the
document within the authorInstitution. Legal authentication implies that adocument has been signed manually or electronically by thelegalAuthenticator. This attribute may be absent if not applicable.

O/O

XCN

<rim:Slot name="legalAuthenticator"><rim:ValueList><rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value></rim:ValueList></rim:Slot>

mimeType

MIME type of the document in the Repository.

R/P<rim:ExtrinsicObject mimeType="application/pdf"
id="theDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a0329b2a5b5186c1"> …

parentDocumentI The identifier of the parentDocument entry that represents thedsource of a document replacement, addendum, transformation,or signs relationship.

R/P

May identify a document which is unknown by the Document
Registry.
<rim:ObjectRef__________________________________________________________________________
104
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

ebRIM
Associaton

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R/P

Use
one ofthefollowingvalues:id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"/><rim:Association
associationType="parentDocumentRelationShip"
sourceObject="theDocument"
targetObject="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"/>

If the parent document is in the registry then code as
association to it, otherwise create a stub document object, anduse its entryUUID as the value for the targetObject attribute.
A document stub represents a document that is not in registry
but is needed by another object to point at. This association iscoded with a type from parentDocumentRelationship.
A document may have a single relationship via the RPLC,
APND, or XFRM association types. There is no restriction on
the number of signs relationships that a document may be partof.
parentDocument
Relationship

The type of relationship that the document has with theparentDocument (e.g. Replace, addendum, transformation, or
signs).
See parentDocumentID for an example.

APND
RPLC
XFRM
signs
patientId

The patientId represents the subject of care medical record
identifier as selected by the Document Source. This identifier
shall be from the Assigning Authority Domain supporting theAffinity Domain in which the Document Registry operates. It
shall contain two parts:

R/R

Authority Domain Id (enforced by the Registry)An Id in the above domain.
The value of the patientId shall be the same for all new__________________________________________________________________________
105
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNACX

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R/R

XDS
Affinity
Domainspecific

R/P

XDS
Affinity
Domainspecific

R2/R

HL7
V2
DTM

documents of a Submission Set.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"><rim:Name><rim:LocalizedString value ="XDSDocumentEntry.patientId"/></rim:Name></rim:ExternalIdentifier>practiceSettingCode

The code specifying the clinical specialty where the act that
resulted in the document was performed (e.g. Familly Practice,
Laboratory, Radiology). It is suggested that the XDS Affinity
Domain draws these values from a coding scheme providing acoarse level of granularity (about 10 to 100 entries)<rim:Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"classifiedObject="theDocument"
nodeRepresentation="practiceSettingCode"><rim:Name><rim:LocalizedStringvalue="practiceSettingCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>practiceSettingC
ode
DisplayName

The name to be displayed for communicating to a human themeaning of the practiceSettingCode.

serviceStartTime

Represents the start time the service being documented took
place (clinically significant, but not necessarily when the
document was produced or approved). This may be the sameas the encounter time in case the service was delivered during
an encounter. This time is expressed as (date/time/UTC).

See practiceSettingCode for an example.

__________________________________________________________________________
106
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R2/R

HL7
V2
DTM

Cp/P

Integer

R/P

CX

Note: Other times, such as document creation or approval are
to be recorded, if needed, within the document.
<rim:Slot name="serviceStartTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>serviceStopTime

Represents the stop time the service being documented took
place (clinically significant, but not necessarily when the
document was produced or approved). This may be the sameas the encounter time in case the service was delivered during
an encounter. This time is expressed as (date/time/UTC). If
the Service happens at a point in time, this attribute shallcontain the same value as the serviceStartTime.
<rim:Slot name="serviceStopTime"><rim:ValueList><rim:Value>20041225232010</rim:Value></rim:ValueList></rim:Slot>size

Size in bytes of the byte stream that was provided in theRegister and Provide Transaction and stored by the XDS
Document Repository. This value is computed by theDocument Repository and included in the Register Documents
Set Transaction.
<rim:Slot name="size"><rim:ValueList><rim:Value>3654</rim:Value></rim:ValueList></rim:Slot>sourcePatientId

The sourcePatientId represents the subject of care medical
record Identifier (e.g. Patient Id) in the local patient Identifier
Domain of the Document Source. It shall contain two parts:
Authority Domain Id
An Id in the above domain (e.g. Patient Id).
This sourcePatientId is not intended to be updated once theDocument is registered (just as the Document content and__________________________________________________________________________
107
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/Query

metadata itself will not be updated without replacing theprevious document). As this sourcePatientId may have been
merged by the source actor, it may no longer be in use within
the Document Source (EHR-CR). It is only intended as anaudit/checking mechanism and has occasional use forDocument Consumer Actors.
<rim:Slot name="sourcePatientId"><rim:ValueList><rim:Value>j98789^^^id.domain</rim:Value></rim:ValueList></rim:Slot>sourcePatientInfoThis attribute contains demographics information of the patient R4/P
to whose medical record this document belongs, as theDocument Source knew it at the time of Submission.
This information typically includes: the patient first and last
name, sex, and birth date. The Clinical Affinity Domain
policies may require more specific information and format.
This patient information is not intended to be updated once theDocument is registered (just as the Document content andmetadata itself will not be updated without replacing theprevious document). As sourcePatientInfo may have been
updated by the source actor, it may no longer be in use within
the Document Source (EHR-CR). It is only intended as anaudit/checking mechanism and has occasional use forDocument Consumer actors.
<rim:Slot name="sourcePatientInfo"><rim:ValueList><rim:Value>PID-3|DTP-1^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO</rim:Value><rim:Value>PID-5|DICTAPHONE^ONE^^^</rim:Value><rim:Value>PID-7|19650120</rim:Value><rim:Value>PID-8|M</rim:Value><rim:Value>PID-11|100 Main
St^^BURLINGTON^MA^01803^USA</rim:Value></rim:ValueList></rim:Slot>

4

Certain segments are required, see definition.

__________________________________________________________________________
108
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

Data
Type

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

PID-3 is required and must include the source patient
identifier.
PID-5 is required and must include the patient name.
PID-8 is required and must code the patient gender as
M – MaleF – Female
O – OtherU – Unknown
PID-7 is required if known, and must include the patient dateof birth.
PID-11 is required if known, and must include the patient
address.
PID-2, PID-4, PID-12 and PID-19 should not be used.
Other PID segments are optional.
title

Represents the title of the document. Clinical documents often
do not have a title, and are collectively referred to by thedisplay name of the classCode (e.g. a "consultation" or"progress note"). Where these display names are rendered tothe clinician, or where the document has a unique title, the title
component shall be used. Max length, 128 bytes, UTF-8.

O/P<rim:ExtrinsicObject
id="theDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
mimeType="application/pdf"><rim:Name><rim:LocalizedString value="title"/></rim:Name>…
</rim:ExtrinsicObject>

typeCode

The code specifying the precise kind of document (e.g.
Pulmonary History and Physical, Discharge Summary,Ultrasound Report). It is suggested that the XDS Affinity
Domain draw these values from a coding scheme providing afine level of granularity.

R/R<rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="theDocument"
nodeRepresentation="typeCode">__________________________________________________________________________
109
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

XDS
Affinity
Domainspecific

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

R/P

XDS
Affinity
Domainspecific<rim:Name><rim:LocalizedStringvalue="typeCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

typeCodeDisplay
Name

The name to be displayed for communicating to a human themeaning of the typeCode.
See typeCode for an example.

__________________________________________________________________________
110
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

uniqueId

The globally unique identifier assigned by the document
creator to this document. This unique identifier may be usedin the body of other XDS Documents to reference thisdocument. The length of Unique Identifier shall not exceed
128 bytes. The structure and format of this Id shall beconsistent with the specification corresponding to the format
attribute. (e.g. for a DICOM standard document a 64 character
numeric UID, for an HL7 CDA format a serialization of the
CDA Document id extension and root in the formoid^extension, where OID is a 64 digits max, and the ID is a
16 UTF-8 char max).

R/R

See
section
3.14.4.
1.2.7.2

Cp/P

URI

This uniqueId is intended to respond to the following types ofusage:The means to reference this XDS document from within thecontent of another document. Neither the XDS Registry nor
the Repository is aware of such references, but the Document
Sources and Consumers are.
The means to ensure that when a XDS Document is retrieved
from the XDS Document Repository using the URI
component, the selected XDS Document is the correct one.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="1.3.6.1.4.1.21367.2005.3.7^11379"><rim:Name><rim:LocalizedStringvalue="XDSDocumentEntry.uniqueId"/></rim:Name></rim:ExternalIdentifier>

URI

The URI of the XDS Document to be used for retrieval.
XDS does not constraint the format of this URI beyond RFC
2616. However, the IHE Retrieve Information for Display
Integration Profile defined format may be used in cases where
the Document repository is grouped with a RID Information
Source Actor (See ITI TF-1:Appendix E.5)
RID links can be used only if they yield the document in full__________________________________________________________________________
111
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

XDSDocumentE
ntry Attribute

Definition

Source/
Query

Data
Type

fidelity.
<rim:Slot name="URI"><rim:ValueList><rim:Value>http://www.ihe.net</rim:Value></rim:ValueList></rim:Slot>

2320

2325

3.14.4.1.2.7.1

XDSDocumentEntry.formatCode

In general, the repository holds an octet stream representing the document. The registry metadata
describes, among other things, the format of the document. This is coded in
XDSDocumentEntry.formatCode. This code will identify document format parameters necessary
for interoperability. Rules about handling the formatCode are necessary but are not imposed by
XDS. In the future. IHE content specific Integration Profiles may be created that specify theserules.
Note: Although only a small number of document standards may be used, a large number of code values may
be defined to point to specific templates and archetypes structuring specific document content.

3.14.4.1.2.7.2
2330

2335

XDSDocumentEntry.uniqueId

The specification of the format and encoding for this attribute depends on the document standard
defining the content of the XDS Document (e.g. OID with optional extension ID for HL7 CDA,UUID in some cases, SOP Instance UID for DICOM composite objects. Format is:
OID^Extension). This attribute shall not exceed 128 bytes in size. It shall be used as an opaqueand globally unique identifier for the XDS Document. Document Consumers, Registries,
Repositories shall not attempt to interpret its content.
3.14.4.1.2.8 Submission Set Metadata

2340

The following metadata elements shall be used to describe an XDS Submission Set. They shallbe provided by the Document Source Actor in the Provide and Register Document Set
transaction. They shall be provided by the Document Repository Actor in the Register Document
Set Transaction either directly if grouped with a Document Source Actor or forwarded from a
Provide and Register Document Set Transaction.
Each of the attributes listed below is an attribute on the RegistryPackage object defining theSubmission Set. The attribute name is defined with a prefix of the object type of
XDSSubmissionSet when referenced by other objects, for example XDSSubmissionSet.sourceId.

__________________________________________________________________________
112
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
2345

In the attribute tables below, when an OID format is specified, it shall follow the assignment andformat rules defined for document UID in ITI TF-2 : Appendix B.
Table 3.14.4.1-6 Submission Set Metadata Attribute Definitions

XDSSubmission
Set
Attribute

Definition

Source/
Query

Data
Type

authorInstitution

Represents a specific healthcare facility under which thehuman and/or machines authored the Submission Set.

R2/R

XON

O/R

XCN

<rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>Fairview Hospital</rim:Value></rim:ValueList></rim:Slot>authorPerson

Represents the human and/or machines that authored theSubmission Set. The document author may be the patient
itself.
<rim:Slot name="authorPerson"><rim:ValueList><rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value></rim:ValueList></rim:Slot>authorRole

authorSpecialty

A code that represents the role of the author with respect to thepatient when the document was created.
<rim:Slot name="authorRole"><rim:ValueList><rim:Value>theAuthorRole</rim:Value></rim:ValueList></rim:Slot>
Represents a specific specialty within a healthcare facility under which the human and/or
machines authored the document.

R2/O

R2/O

<rim:Slot name="authorSpeciality"><rim:ValueList><rim:Value>theAuthorSpeciality</rim:Value></rim:ValueList></rim:Slot>comments

Comments associated with the Submission Set. Free form text
with an Affinity Domain specified usage.

R2/R<rim:Description><rim:LocalizedString value = "comments"/></rim:Description>__________________________________________________________________________
113
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

Use
specific
to XDS
Affinity
Domain.

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDSSubmission
Set
Attribute

Definition

Source/QuerycontentTypeCode

The code specifying the type of clinical activity that resulted in R/R
placing these XDS Documents in this XDS-Submission Set.
These values are to be drawn for a vocabulary defined by theAffinity Domain.

Data
Type
XDS
Affinity
Domainspecific<rim:Classification
classificationScheme=“urn:uuid:aa543740-bdda-424e-8c96-df4873be8500”
classifiedObject=”submissionSet”
nodeRepresentation=”contentTypeCode”><rim:Name><rim:LocalizedStringvalue=”contentTypeCodeDisplayName” /></rim:Name><rim:Slot name=”codingScheme”><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

contentTypeCode
DisplayName

The name to be displayed for communicating to a human themeaning of the contentTypeCode.

patientId

The patientId represents the medical record identifier ofsubject of care whose longitudinal record is being maintained,
as selected by the Document Source. Attaching an existing
document for patient A to a folder for patient B is presumed inthis case to be an update to the longitudinal record for patient
B. In this case, the Submission Set patientId would be that ofpatient B.

R/P

XDS
Affinity
Domainspecific

R/R

CX

See contentTypeCode for an example.

This identifier shall be from the Assigning Authority Domain
supporting the Affinity Domain in which the Document
Registry operates. It shall contain two parts:
Authority Domain Id (enforced by the Registry)An Id in the above domain.
The value of the patientId shall be the same for all new
documents of a Submission Set.
__________________________________________________________________________
114
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDSSubmission
Set
Attribute

Definition

Source/
Query

Data
Type

R/R

CX

R/R

DTM

R/R

OID

<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"><rim:Name><rim:LocalizedString value = "patientId"/></rim:Name></rim:ExternalIdentifier>sourceId

Globally unique identifier for the instance of the Document
Source that contributed the Submission Set. The assigningauthority for these identifiers is specified by the XDS Affinity
Domain. When a "broker" is involved in sending submission
sets from a collection of client systems, it should use a
different source ID for submissions from each separate system
to allow for tracking.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
value="8449607624^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"><rim:Name><rim:LocalizedString value ="XDSSubmissionSet.sourceId"/></rim:Name></rim:ExternalIdentifier>submissionTime

Point in Time at the Document Source when the Submission
Set was created and issued for registration to the Document
Registry.
This shall be provided by the Document Source (in case of email with significant delay).
<rim:Slot name="submissionTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>

uniqueId

Globally unique identifier for the submission-set instanceassigned by the Document Source in OID format.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:4b052cba-b03b-4233-8b27-e8d5e3f8d3e4"
value="1.3.6.1.4.1.21367.2005.3.7.3670984664"><rim:Name><rim:LocalizedString value =__________________________________________________________________________
115
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

See
Appendix B

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDSSubmission
Set
Attribute

Definition

Source/
Query

Data
Type

"XDSSubmissionSet.uniqueId"/></rim:Name></rim:ExternalIdentifier>3.14.4.1.2.9 Folder Metadata2350

The following metadata elements shall be used to describe an XDS Folder. They shall be
provided by the Document Source Actor in the Provide and Register Document Set transaction.
They shall be provided by the Document Repository Actor in the Register Document Set
transaction if this transaction is used outside the context of a Provide and Register Document Set
transaction.

2355

Each of the attributes listed below is an attribute on the RegistryPackage object defining the
Folder. The attribute name is defined with a prefix of the object type of XDSFolder whenreferenced by other objects, for example XDSFolder.patientId.
In the attribute tables below, when an OID format is specified, it shall follow the assignment andformat rules defined for document UID in ITI TF-2 : Appendix B.
2360
Table 3.14.4.1-7 Folder Metadata Attribute Definitions

XDSFolder
Attribute

Definition

Source/
Query

Data
Type

codeList

The list of codes specifying the type of clinical activity that
resulted in placing these XDS Documents in this XDSFolder.
These values are to be drawn for a vocabulary or coding
scheme defined by the Clinical Affinity Domain.

R/R

MultiValued.
XDS
Affinity
Domainspecific

When a new submission request associates XDS Documents(new submission or previously submitted) to an XDS Folder,
the Code included in the codeList is appended to the existing
list of codes for this Folder (if any) unless this code is alreadypresent in the list managed by the Registry for the same XDSFolder.
Only one code may be assigned to the Folder when a XDS
Document is placed in a Folder.
<rim:Classification
classificationScheme='urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5'
classifiedObject='Foloder'
nodeRepresentation='codeList'__________________________________________________________________________
116
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDSFolder
Attribute

Definition

Source/
Query

Data
Type

R/P

Multivalued.

R2/R

XDS
Affinity
Domainspecific
.

Cg/R

DTM

R/R

CX

>
<rim:Name><rim:LocalizedStringvalue='codeListCodeDisplayName' /></rim:Name><rim:Slot name='codingScheme'><rim:ValueList><rim:Value>Affinity Domain Specific
Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

codeDisplayName
List

The list of human readable descriptions of the meaning of each
on of the codes present in the codeList.
Only one code may be assigned to the Folder when a XDS
Document is placed in such a Folder.
See codeList for an example.

comments

Comments associated with the Folder. Free form text with an
Affinity Domain specified usage.
<rim:Description><rim:LocalizedString value = "comments"/></rim:Description>

lastUpdateTime

Point in time at the Document Registry when an XDS
Document was registered and placed in the XDS Folder.
<rim:Slot name="submissionTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>patientId

The patientId represents the subject of care medical record
Identifier as defined by the Document Source. This identifier
shall be from the Assigning Authority Domain supporting theAffinity Domain in which the Document Registry operates. It
shall contain two parts:
Authority Domain Id (enforced by the Registry)An Id in the above domain.
The value of the patientId shall be the same for all new
documents of a Folder.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"__________________________________________________________________________
117
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________XDSFolder
Attribute

Definition

Source/
Query

Data
Type

R/R

OID

value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"><rim:Name><rim:LocalizedString value = "patientId"/></rim:Name></rim:ExternalIdentifier>uniqueId

Globally unique identifier for the XDS-Folder in which one ormore XDS Documents are placed. It is assigned by theDocument Source at the time the XDS Folder is created in
OID format.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:4b052cba-b03b-4233-8b27-e8d5e3f8d3e4"
value="1.3.6.1.4.1.21367.2005.3.7.3670984664"/>

3.14.4.1.2.10 Registry Adaptor Enforcement of Attributes
2365

Table 3.14.4.1-8 Document Metadata Attribute Enforcement

XDSDocumentEntry Attribute

Registry Enforcement

availabilityStatus

No enforcement

authorInstitution

No enforcement

authorPerson

No enforcement

authorRole

No enforcement

authorSpecialty

No enforcementclassCodeCoding Scheme and Code Value.

classCodeDisplayName

Must match classCode

confidentialityCode

Coding Scheme and Code Value

creationTime

No enforcement

entryUUID

No enforcement

eventCodeList

Coding Scheme and Code Value__________________________________________________________________________
118
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA

See
Appendix B

IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
eventCodeDisplayNameList

Must match eventCodeList

formatCode

Coding Scheme and Code Valuehash

No enforcement

healthcareFacilityTypeCode

Coding Scheme and Code Value

healthcareFacilityTypeCodeDisplayNameMust match healthcareFacilityTypeCodelegalAuthenticator

No enforcement

languageCode

Optionally enforced by Affinity Domain

mimeType

Code ValueparentDocumentRelationship

One of three values

parentDocumentId

Existing UUID

patientId

Authority Domain Id
Patient Id (known from patient identity
feed)practiceSettingCode

Coding Scheme and Code Value

practiceSettingCode DisplayName

Must match practiceSettingCode

serviceStartTime

No enforcement

serviceStopTime

Verifies serviceStartTime <=serviceStopTime

size

No enforcement

sourcePatientId

No enforcement

sourcePatientInfo

No enforcement

Title

No enforcement

typeCode

No enforcement

typeCodeDisplayName

Must match typeCode__________________________________________________________________________
119
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
uniqueId

No identical existing uniqueId in
registry (assigned to
XDSDocumentEntry,
XDSSubmissionSet, or XDSFolder)

URI

No enforcement
Table 3.14.4.1-9 SubmissionSet Metadata Attribute Enforcement

XDSSubmissionSet Attribute

Registry Enforcement

authorInstitution

No enforcement

authorPerson

No enforcement

authorSpecialty

No enforcement

comments

No enforcement

contentTypeCode

Coding Scheme and Code value

contentTypeCodeDisplayName

Must match contentTypeCodepatientId

Authority Domain Id
Patient Id (known from patient identity
feed)sourceId

Coding Scheme and Code value

submissionTime

No enforcement

uniqueId

No identical existing uniqueId in
registry (assigned to
XDSDocumentEntry,
XDSSubmissionSet, or XDSFolder)

Table 3.14.4.1-10 Folder Metadata Attribute Enforcement

XDSFolder Attribute

Registry Enforcement

codeList

Coding Scheme and Code value

codeListDisplayName

Must match codeList

comments

No enforcement__________________________________________________________________________
120
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
lastUpdateTime

No enforcement

patientId

The value of the patientId shall be thesame for all new documents of a Folder.

uniqueId

No identical existing uniqueId in registry(assigned to XDSDocumentEntry,
XDSSubmissionSet, or XDSFolder)

2370
3.14.4.1.2.11 Protocol Requirements
SOAP with Attachments shall be used as the protocol between the Document Repository and theDocument Registry when these two actors are implemented separately. The protocol is specified
in ITI TF-2 : 3.15.4.1.2.3.1 (On-line protocol binding).
2375

2380

2385

2390

2395

3.14.4.1.2.12 XDS Registry Adaptor
The XDS Registry Adaptor is a set of functionality that is not provided for in the ebXML
registry standard, but is instead specified by XDS to support integration into the healthcare
environment. This adaptor has the following responsibility:
Validate patient ID – patient IDs (XDSDocumentEntry.patientId attribute) shall be a known
patient ID and registered against the Patient ID Domain of the XDS Affinity Domain
managed by the patient Identity Source Actor.
Validate submitted metadata – the adaptor shall verify that submitted metadata meets XDS
Registry metadata specification
Verify coded values – the adaptor shall verify that coded fields (ebXML externalclassifications) contain valid XDS specified values or where the Affinity Domain
constrains code values, to verify them (See Section 3.14.4.1.2.10).
Ensure submissions are atomic - The adaptor shall make submission to registry an atomic
operation – see section 3.14.4.1.2.3.3 Atomicity Requirements for Submission
Requests for atomicity requirements.
• If the registry submission is successful then the adaptor shall label all Document
Entry, Folder, and Submission Set objects as Approved. The ebRIM specification
provides the ApproveObjectsRequest for this purpose.
• If the registry submission fails then the adaptor shall remove from the registry all
objects stored as part of this submission set. The ebRIM specification provides theRemoveObjectsRequest for this purpose.

__________________________________________________________________________
121
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2400

2405

2410

2415

2420

2425

Support document replacement - When a Submission Request includes a ‘RPLC’ or‘XFRM_RPLC’ association indicating that a document is being replaced, thefollowing shall be true:• The association’s sourceObject attribute shall contain the id (UUID or symbolicid) of an ExtrinsicObject representing an XDSDocumentEntry included in the
Submission Set.
• The association’s targetObject attribute shall contain the UUID of an
ExtrinsicObject (XDSDocumentEntry) already in the registry.
When the ‘RPLC’ or ‘XFRM_RPLC’ association is detected by the Registry Adaptor
it shall:• Verify the ExtrinsicObject pointed to by the Association’s targetObject attribute ispresent in the registry. An error shall be thrown if this object is not contained in
the registry.
• Submit the Submission Request to the registry.
• If the submission is successful, label the replacement document as Approved andthe replaced document as Deprecated. The ebRIM requests
ApproveObjectsRequest and DeprecateObjectsRequest are available to do this.
Validate patientIDs in Folders - The adaptor shall verify that all documents in a folder are
for the same patient. Specifically, verify that the patientId attribute of the folder
matches the patientId attribute of each document in the folder.
Validate MIME types - The adaptor shall validate that the mimeType document attribute forall documents received is on the approved list for this Affinity Domain.
Maintain Folder attribute ‘lastUpdateTime’ - The XDS Folder attribute lastUpdateTime
shall be updated by the adaptor every time a new document is added to an XDS
Folder.
Validate patientID on documents being added to a Folder - The patientId attribute of an
XDSDocumentEntry object shall match the patientId attribute on any folder that
holds it.
Validate coding - The adaptor shall enforce the number of classifications offered against a
document. Code lists are allowed to be multiples. Codes are required to be singular.
3.14.4.1.2.13 General Metadata Issues
This section documents ebXML Registry issues that are confusing, underdocumented, or are in
conflict between various versions of the registry specification.

__________________________________________________________________________
122
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.14.4.1.2.13.1

Association Type naming

2430

XDS requires that Association names be specified as text names and not UUIDs. This isconsistent with version 2.0 and 2.1 of ebRIM. XDS requires the use of the following standard
Associations:
HasMember – for linking RegistryPackage objects to their contents
ExternallyLinks – for binding an ExternalLink object to an ExtrinsicObject.

2435

In addition, XDS defines a collection of Association types defined in section 3.14.4.1.2.6
Document Relationships and Associations.
3.14.4.1.2.13.2

2440

2445

Assigning Codes to Documents

Many attributes of XDSDocumentEntry, XDSSubmissionSet, and XDSFolder (Tables 3.14.4.13, 3.14.4.1-4, and 3.14.4.1-5) are coded attributes defined as ebRIM Classifications. Three
details are required to describe a coded value:2.

The value of the code4.

The display name of the code (raw codes are not human-friendly)

5.

The name of the coding scheme that the code comes from.

These three values combine to define a single coded element.
As described in ebXML Registry metadata, a coded attribute looks like:

2450

2455

2460

<!--++++++++++++++++++++++++++++++++++++++++++++++++++--XdsDocumentEntry.classCode-++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="theDocument"
nodeRepresentation="My Class Code"><!-- +++++++++++++++++++++++++++++++++++++++++++++++++
XdsDocumentEntry.classCodeDisplayName++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Name><rim:LocalizedString value="Display Name for My Class Code"/></rim:Name>

2465<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++
Coding scheme for classCode__________________________________________________________________________
123
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2470

2475

++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Name of the Coding Scheme (LOINC for
example)</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

A code is constructed as a Classification object. The relevant parts of this classification are:

2480

2485

2490

2495

Classification – this element wraps the definition
classificationScheme attribute – this UUID references a Classification Scheme object
already present in the registry. This Classification Scheme object and its UUID are
predefined by XDS and serve as the defining ‘type’ for the code.
classifiedObject attribute – this references the object in metadata being classified. This canbe specified as a UUID or as a symbolic name as shown in the example above.
nodeRepresentation attribute – this is the value of the code.
Name element - this is the display name for the code.
codingScheme Slot (Value sub-element) - this is the name of the coding scheme.
The Affinity Domain defines the local configuration for each coding scheme. Specifically, itdefines:Name of the coding scheme – which must be used in the codingScheme Slot
Values for the code – one of which must be used in the nodeRepresentation attributeName for each code – which must be used in the Name element and must match the value
for the code.
Some code types allow multiple values. EventCodeList is an example. These codes contain theletters ‘List’ in their name. These codes are XML coded identically to the above example with
one exception. The entire Classification element may be repeated to specify additional values.
The Registry Adaptor Function is responsible for validating codes against the configuration of
the Affinity Domain.
Note: the attribute XDSDocumentEntry.languageCode is not encoded as shown above. See Tables 3.14.4.1-3 fordetails.

2500

3.14.4.1.2.14 Sequencing Requirements
The Repository actor shall:
3.

Make a new document available for retrieval via the Retrieve Document transaction
before it initiates the Register Document Metadata transaction with the Registry actor.

This is necessary because:__________________________________________________________________________
124
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
2505

2510

4.

The Document Registry actor may choose to validate URIs contained in metadata
before acknowledging the Register Document Metadata transaction.

6.

The Document Consumer actor may retrieve the document before the Register
Document Metadata Acknowledgement is received by the Repository actor.

3.14.4.1.2.15 Security Requirements
This profile requires all actors be grouped with a Secure Node Actor as defined in the IHE Audit
Trail and Node Authentication Integration profile. This use of the ATNA profile in an XDS
Affinity Domain does not require a centralized affinity domain Audit Repository Actor.

2515

2520

2525

2530

2535

The use of ATNA along with XDS does require that each member of the Affinity Domain does
have audit and security mechanisms in place. See appendix ITI TF-1: Appendix G and ITI-TF-2:
Appendix K.
The individual actors involved are often members of different secure domains, as illustrated in
Figure 3.14.4.1-2. The data transfers between different secure domains need different protection
than transfers within a secure domain. They shall be either:• Encrypted, with TLS authentication of both hosts, for online transfers, or• Encrypted, using S/MIME secure encoding and digital signature by the sender, for offlinetransfers.
Transfers within a single secure domain may choose to omit encryption if it is unnecessary, so it
is recommended that the online transfer security mechanisms be configurable. Certificate
management and exchange is defined as part of the affinity domain business relationships and no
IHE Integration Profile is specified at this time, see ITI TF-1: Appendix L.
Each transaction will result in audit records describing the transaction. Each secure domain has
its own audit server to capture the records for the actors that are within that domain. Access toaudit records by other enterprises within the affinity domain is managed and controlled by thebusiness relationship terms of the affinity domain. There is no automatic IHE transaction forsuch access.
The audit records that should be generated (references IHE ATNA Integration Profile) by normal
XDS activities are:
• For the Register Document Set, and the Provide and Register Document Set Transactions:• The Source Actor shall generate “Export” events describing the export of PHI from theSource to the Registry Actor. There should be one report for each transaction.
• The Registry Actor shall generate “Import” events describing the import of PHI from theSource to the Registry Actor. There should be one report for each transaction.
• For the Query Documents Transaction:__________________________________________________________________________
125
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
•

2540
•

2545

2550

The Registry Actor shall generate a “Query” event describing the query, and shallgenerate an “Export” event if the query results in a reply that contains PHI.
For the Retrieve Document Transaction:• The Repository Actor shall generate an “Export” event. This may be an event for each
Retrieve Document Transaction, or multiple transactions for the same patient may beheuristically combined. The heuristics for this combination are not specified by IHE. It
is intended to reduce the volume of audit records. Combination is permitted when theactive participants and patient are the same, and the time difference is consideredinsignificant.
• The Document Consumer Actor shall generate an “Import” event. This may be one event
per transaction, or multiple transactions may be reported as a single event using aheuristic for combining transactions. Combination is permitted when the active
participants and patient are the same, and the time difference is considered insignificant.
Figure 3.14.4.1-2 - Example Security Domain Relationships

Security Domain B
RepositoryyRegistry
Encrypted,
S/MIME, Signed
if Offline
Security Domain A
SourceEncrypted,
TLS,
Authenticated if
OnlineSecurity Domain C
Comsumer

Repositoryy

All Actors are part of the same Clinical Affinity Domain

2555__________________________________________________________________________
126
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.14.4.1.3

Expected Actions

Upon receipt of a Register Document Metadata message, the Document Registry with the aid of
the Registry Adaptor shall do the following:
2560

Accept all valid SubmitObjectsRequests.
Perform validations
Update the registry with the contained metadata
Return a RegistryResponse message given the status of the operation.
If the registry rejects the metadata, then, the following occurs:

2565

An error is returned
The error status includes an error message
The request is rolled back3.14.4.2 Register Document Metadata Acknowledgment
3.14.4.2.1

2570

Trigger Events

The Document Registry finishes processing a Register Document Metadata request and shall
respond with:
Register Document Metadata Acknowledgment
This message corresponds to the ebXML RequestResponse message.
3.14.4.2.2

2575

The ebXML RequestResponse message carries the status of the requested operation and an error
message if the requested operation failed. The conditions of failure and possible error messages
are given in the ebRS standard.
3.14.4.2.3

2580

Message Semantics

Expected Actions

The Document Repository now knows that the transaction succeeded/failed and can continue.
The metadata added to the registry as a result of this transaction is now available for discovery
via query transactions.

__________________________________________________________________________
127
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.15 Provide and Register Document Set
2585

2590

2595

This section corresponds to Transaction ITI-15 of the IHE Technical Framework. Provide andRegister Document Set is used by the Document Source to provide a set of documents to theDocument Repository, and to request that the repository store these documents and then registerthem with the Document Registry.
The Provide and Register Document Set transaction describes only the interaction between theDocument Source and Document Repository actors. The interaction between the Document
Repository and the Document Registry is described separately in the Register Document Set
Transaction (ITI-14).
This transaction aligns with the Registry Services standard (ebRS). The ebRS standard covers theinteraction with a service that includes a registry with integrated repository. From the point ofview of the Document Source, the separate nature of the XDS Document Registry andRepository actors is hidden. This transaction exactly matches the registry service for submitting
registry/repository content found in ebRS.
By specifying separate registry and repository actors, XDS offers additional flexibility of having
a single registry index content for multiple repositories. The ebRIM portion of the registry
standard supports this possibility though the ExternalLink object type.

2600

2605

The documents and metadata go to the repository actor and then the metadata is forwarded on to
the registry actor. They move in this direction for several reasons:• Allows best reuse of ebXML Registry specified protocols• Document Source only needs to know the identity of the Document Repository. Repository
knows the identity of the registry. If Provide and Register Document Set transaction weresent to the registry then routing decisions for documents would be more complex.
• Resulting protocols are simpler• Simplifies the common case where the Document Source and the Document Repository aregrouped.
3.15.1 Scope

2610

The Provide Register Document Set transaction passes a Repository Submission Request (see ITI
TF-2: 3.14.4.1.2.3.2) from a Document Source to a Document Registry.
A Provider and Register Document Set transaction carries:
Metadata describing zero or more new documents

2615

Submission Set definition along with the linkage to new documents and references to existing
documents
Zero or more XDS Folder definitions along with linkage to new or existing documents__________________________________________________________________________
128
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Zero or more documents
3.15.2 Use Case Roles
Document
SourceDocument
Repository

Provide andRegisterDocuments

2620

Actor: Document Source
Role: A system that submits documents and associated metadata to a Document Repository.
Detail requirements for this actor are discussed in section 3.15.5.1.
Actor: Document Repository
Role: A document storage system that receives documents and associated metadata and:

2625

Stores the documents
Enhances submitted metadata with repository information to enable later retrieval of documents
Forwards the enhanced metadata to the Document Registry.
3.15.3 Referenced Standards
ebMS OASIS/ebXML Messaging Services Specifications v2.0

2630

ebRIM OASIS/ebXML Registry Information Model v2.0
ebRS OASIS/ebXML Registry Services Specifications v2.0
HTTP HyperText Transfer Protocol HTTP/1.1 (IETF RFC2616)
MIME Multipurpose Internet Message Extensions (RFC 2045 to RFC 2049)
SMTP Simple Mail Transfer Protocol (RFC2821)

2635

multipart/related The MIME Multipart/Related Content-type (RFC2387)__________________________________________________________________________
129
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.15.4 Interaction Diagram
Document
SourceDocument
Repository

Provide and Register Document Set

Provide and Register Document Set
Acknowledgment

3.15.4.1 Provide and Register Document Set Message
2640

A Document Source sends documents and associated metadata to a Document Repository thathas an associated Document Registry. This message corresponds to an ebRS
SubmitObjectsRequest with associated documents.
3.15.4.1.1

Trigger Events

The Document Source, based on a human decision or the application of a certain rule ofautomatic operation, wants to submit
2645•

A set of one or more documents to the Document Repository and•

The associated metadata to the Document Registry.

3.15.4.1.2

Message Semantics

Message semantics are discussed as follows:
1. Metadata2650

2. Security Requirements
3. Protocol Selection (On-Line Protocol binding and Off-Line Protocol binding)
3.15.4.1.2.1 Metadata

2655

The Register Document Set message shall include the metadata attributes (as defined in section
3.14.4.1.2.7) that will be forwarded by the Document Repository to the Document Registry using
the Register Document Set Transaction (ITI-14).
The Document Source supplies all necessary registry object attributes with the exception of the
URI attribute of an XDSDocumentEntry that must be assigned by the Document Repository.
__________________________________________________________________________
130
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Therefore, the Document Repository must add this attribute to the metadata before initiating theRegister Document Set transaction to the registry.
2660

3.15.4.1.2.2 Security Requirements
Relevant security requirements are discussed in the Register Document transaction (see ITI TF1: 3.14.4.1.2.14).
3.15.4.1.2.3 Protocol Selection

2665

There are two types of network relationships between the Document Source and Document
Repository:On-line – the Document Source constructs a direct connection (i.e, socket) to the Document
Repository.
Off-line – the Document Source connects to the Document Repository via SMTP.

2670

3.15.4.1.2.3.1

On-Line Protocol Binding

3.15.4.1.2.3.1.1

General structure and header

This is a MIME multipart/related message. The first attachment inside the payload of the SOAP
request bears the registry metadata in an XML file containing the SubmitObjectsRequest.
Protocol encapsulation in HTTP POST
SOAP with MIME attachments
text/xml SubmitObjectRequest (ebXML Registry Message)
Document 1.
.
.

Document n

2675

Figure 3.15.4.1-1 General Diagram of the Main message composing the On-Line Provide
and Register Document Set Transaction__________________________________________________________________________
131
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.15.4.1.2.3.1.2

Associated Documents

The next attachments will contain the document(s) to be provided and registered, as MIME parts.
There are one or more parts that contain byte streams representing documents5.
2680

2685

2690

2695

The multipart packaging transmits the MIME-type of each part. The metadata part shall be oftype text/xml. Parts containing documents destined for the Document Repository can have any
MIME type, either single part or multipart. Each part containing a document has associated withit a document ID that is unique within the scope of this message. The Registry Metadata
contained within one part of this message uses these document IDs to bind pieces of metadata to
documents.
The registry metadata will be valid according to ebRIM and will contain the definition of one ormore ebXML ExtrinsicObjects. An ExtrinsicObject is a registry object that represents a
repository document within the registry. Each ExtrinsicObject will contain an id attribute. The
format of this id follows the ebXML Registry definition. It is either a valid UUID or a symbolic
name.
The value of this id attribute is used to link an ExtrinsicObject (XDSDocumentEntry) to a single
part of the multipart that contains the attachments to the message. The header of the relevant partof the multipart will have a Content-Id header whose value is this id attribute surrounded byangle brackets as in the following example.
The metadata includes:<ExtrinsicObject id="myDocument" ...

which links to the following MIME multipart part:2700--------Boundary
Content-Type: text/xml
Content-Id: <myDocument>This sentence is the value of the document.
--------Boundary

2705

2710

3.15.4.1.2.3.2

Off-Line Protocol Binding

3.15.4.1.2.3.2.1

General structure and header

As shown on Figure 3.15.4.1-2, the Off-Line transaction will be based on the ebXML Message
Service Binding, as defined in the ebXML Registry Service (ebRS), with an Asynchronous
Message and responses as defined in ebXML Messaging Services (ebMS). The re-use of ebXML
enables implementers to integrate the Provide and Register Document Set transaction into a
server which supports more comprehensive services, including some using CollaborationProtocol Profiles (CPP) and Collaboration-Protocol Agreement (CPA) as supported by ebXML.

5This section is written independent of which protocol binding is used to package this multipart message. The
protocol choice is documented elsewhere in this profile.

__________________________________________________________________________
132
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2715

Because IHE is aiming to specify such as plug-and-play mechanisms, the Off-Line Protocol
Binding is entirely defined into the present document. This specification does not mandate theuse of a CPA between the Document Repository acting as "ebRS Registry" and the Document
Source acting as "ebRS Registry Client". Such protocol agreement aspects are beyond the scopeof the XDS Profile. The Document Source has only to know the Document Repository e-mailaddress to be able to provide and register a document set.
Protocol encapsulation in SMTP/ESMTP
SOAP with MIME attachments
text/xml SOAP:Envelope
SOAP:Header, with Service=LifeCycleManager and Action=submitObjects
SOAP:Body, with Manifest=list of attachments (e.g. ebXML Reg. Msg + Documents)

text/xml SubmitObjectRequest (ebXML Registry Message)
Document 1.
.
.

Document n

2720

2725

2730

Figure 3.15.4.1-2 General Diagram of the Main message composing the Off-Line Provide
and Register Document Set Transaction

The message is an e-mail message (which the ebXML Messaging Services can split into several
messages if a single message would be too big) containing the following fields:• The From: e-mail address of the sender (Document Source).
• Optionally, a Reply-to: address if the Document Source wants the response messages to besent to another e-mail address.
• The To: e-mail address of the recipient (Document Repository). In case the Document
Repository is able to register a document set to more than one Document Registry, it will
have a different e-mail address for each one of the Repository-Registry peer.
• Date: is the date and time of the Provide and Register Document Set Transaction.
• Subject: XDS/1.0/PnR/ (followed optionally by indication of XDS "subprofile" name. It
SHALL NOT contain any Patient related information)• MIME-Version: 1.0.
• SOAPAction: "ebXML".
__________________________________________________________________________
133
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2735

This is a MIME multipart/related message. The first attachment is the text/xml SOAP:Envelope
part containing the ebMS header. The character set of the ebMS header is UTF-8.
The Header is described in the ebMS standard. It contains the following ebRS tag values:• The header of the message, in /SOAP:Envelope/ SOAP:Header/eb:MessageHeader/ as shownin the table below.
Table 3.15.4.1-1 ebXML Message Header

Location ("@" for attributes)

Description

eb:From/eb:PartyId

Identification of the message sender (its email address,
preceded by mailto:)

eb:From/eb:Role

String indicating the authorized role of the sender formatted
as a URI per ebXML messaging specification:
http://www.ihe.net/roles/iti/xds/DocumentSource

eb:To/eb:PartyId

Identification of intended recipient of the message (its email
address, preceded by mailto:)

eb:To/eb:Role

String indicating the authorized role of the sender formatted
as a URI per ebXML messaging specification:
http://www.ihe.net/roles/iti/xds/DocumentRepository

eb:CPAId

Identification of a Collaboration Protocol Agreement
between the sender and receiver. This shall contain the
trading partner agreed CPA text reference, if it exists (e.g.,the URI of the XML file describing the partnershipagreement). If there is no CPA, this element shall be theconcatenation of eb:From/eb:PartyId and theeb:To/eb:PartyId, separated by the hyphen character (-).

eb:ConversationId

In the absence of a local trading partner agreement, shall be
CCYYMMDD-HHMMSS-mmmmm based upon thesending ebXML message generation. When generating
responses the eb:ConversationID is taken from the original
message.

eb:Service

Shall be LifeCycleManager

eb:Action

Shall be submitObjects

eb:MessageData/eb:MessageId

A unique message identifier generated by the sender: either
a concatenation of message elements to create a globallyunique identifier, or a single message element if thatelement is globally unique.

__________________________________________________________________________
134
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
eb:MessageData/eb:Timestamp

UTC Time that the message header was created in
XMLSchema dateTime format. Example: 2004-1225T23:50:50

eb:DuplicateElimination

If present, duplicate messages should be eliminated.

eb:Description

Description of the Submission Set (equivalent to the
XDSSubmissionSet.comments attribute).

eb:AckRequested

Optional in ebMS, required here to indicate that therepository shall acknowledge the message. This element has
the following attributes: SOAP:mustUnderstand="1"
eb:version="2.0"eb:signed="false"

2740•

List of references to document, in /SOAP:Envelope/ SOAP:Body/eb:Manifest/eb:Reference
as shown in the table below.
Table 3.15.4.1-2 ebXML Message References

2745

Location("@" forattributes)

Description@eb:idIdentification of the document, which is the OID of the XDSDocument.
However, the first reference shall be to the SubmitObjectsRequest XML file,with id set to SubmitObjectsRequest.

@xlink:href

The relative URI of the document in the payload of the ebMS message, cid:followed by the OID. Used only for a newly submitted XDS Document.

@xlink:role

Shall be present only for the first reference, and be set to
http://www.ihe.net/roles/iti/xds/SubmitObjectsRequest

eb:Schema

Shall be present only for the first reference, and has following attributes:
eb:location=http://www.ihe.net/schemas/iti/xds/SubmitObjectsRequest
eb:version=1.0

eb:Description

To be set to the XDSDocumentEntry.title. However, for the first reference,shall be set to the meaning of SubmitObjectsRequest in the local language(i.e. lang="en-US", "Provide and Register Document Set Metadata").

The following attachment inside the payload of the SOAP request bears the registry metadata inan XML file containing the SubmitObjectsRequest.
__________________________________________________________________________
135
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.15.4.1.2.3.2.2

2750

See the subsection "Associated Documents" in the On-Line Binding section (ITI TF-2:
3.15.4.1.2.3.1.1). Any document that has a reference xlink:href and contains a URI that is acontent id (URI scheme "cid") shall be included in the payload.
3.15.4.1.3

2755

Associated Documents

Expected Actions

The Document Repository will receive this message. Each document within the message will be
stored into the repository as an octet stream with an associated MIME type. A detected failure
will result in an error result message being returned to the Document Source thus terminating
this transaction.
The Document Repository will modify the received registry metadata adding:

2760

•

A URI identifier (xdsDocumentEntry.URI) must be created that can be used by aDocument Consumer to reference the document.

•

A hash value (xdsDocumentEntry.hash)• A size (xdsDocumentEntry.size).
A Register Document Set transaction with this modified metadata will be issued to the XDS
Document Registry.
2765

The repository will ensure that any Document Retrieve Transaction received including the URI
identifying the XDS Document, this document shall be provided to the Document Consumer
unchanged from the octet stream that was submitted (full fidelity repository).
3.15.4.2 Provide and Register Document Set Acknowledgment

2770

The Document Repository sends a Provide and Register Document Set Acknowledgment when
the processing of a Provide and Register Document Set is complete. This message is identical to
the RegistryResponse message specified in ebRS. It shall be conveyed in the same protocol as
the request.
3.15.4.2.1

Trigger Events

The following events can trigger this message:
2775

Documents stored to repository successfully and metadata stored to registry successfully (Theregistry part is carried out as part of a Register Document Set transaction)
Documents stored to repository successfully but an error occurred in storing the metadata to theregistry__________________________________________________________________________
136
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Documents were not successfully stored to the repository
2780

3.15.4.2.2

Message Semantics

An ebRS RegistryResponse message is returned containing status and an error message ifnecessary.
Additional relevant semantics for both the repository and registry are described in the Register
Document Set transaction.
2785

3.15.4.2.3

Expected Actions

The Document Source now knows that the transaction succeeded/failed and continue. The
metadata added to the registry as a result of this transaction is now available for discovery via
query transactions. The document(s) added to the repository are now available for retrieval.
3.15.5 Actor Requirements
2790

This section summarizes the capabilities of one or more actors relevant to this transaction. The
details regarding how to perform these operations are documented elsewhere in this transaction
or possibly in other transactions.
3.15.5.1 Document Source
An implementation of the Document Source Actor shall be capable of the following operations:

2795

1.

Submit a single document2.

Submit a document as a replacement for another document already in theregistry/repository

An implementation of the Document Source Actor may support one or more of the following
XDS Options:
2800

1.

Multiple Documents Submission Option. In this option the Document Source offers
the ability to include multiple documents in a single Submission Request.

2.

Document Life Cycle Management In this option the Document Source offers theability to perform the following operation:•

Submit a document as an addendum to another document already in theregistry/repository•

Submit a document as a transformation of another document already in theregistry/repository

2805

Note: In order to support document replacement/addendum/transformation grouping with the Document
Consumer may be necessary in order to Query the registry (e.g. for UUIDs of existing document entries)__________________________________________________________________________
137
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
2810

2815

3.

Folder Management Option. In this option the Document Source offers the ability toperform the following operation:•

Create a folder•

Add one or more documents to a folder

Note: In order to support document addition to an existing folder, grouping with the Document
Consumer may be necessary in order to Query the registry (e.g. for UUIDs of existing folder).

These operations are discussed in section 3.14.4.1.2.3.4 Other Properties of Submission Requests.
3.15.5.2 Document Repository
A Document Repository may validate the following metadata elements received as part of aProvide and Register transaction:
2820

XDSDocumentEntry.uniqueId – a submission may be rejected if not unique within therepository.
XDSSubmissionSet.sourceId – a repository may choose to accept submissions only fromcertain sources and use this field to perform the filtering.

__________________________________________________________________________
138
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2825

3.16 Query RegistryThis section corresponds to Transaction ITI-16 of the IHE Technical Framework. Transaction
ITI-16 is used by the Document Consumer to query the Document Registry for information
about documents indexed in the registry.

2830

Note: This is a very general query mechanism that allows very broad use. Future extensions to XDS may
introduce restrictions or specified the use of canned queries. Proposals for restricting the searchmechanism are requested.

3.16.1 Scope
The Query Registry Transaction supports a variety of types of queries. Examples include thefollowing:
2835

Query by patient (Id) for a time interval, by document type(s), by practice setting(s), by author
personQuery by Document Source
Query for XDS Folders updated during a time interval
Query for all documents in a Folder or Submission Set

2840

Query by time of submission
The list of XDS registry entries attributes that can be the target of a query are defined in Section
3.14.4. This transaction will document the basic syntax and semantics of XDS Document
Registry queries.

2845

All queries return:• Metadata for one or more registry objects, or• Object references for one or more registry objects (registry UUIDs).
3.16.2 Use Case Roles

Document
ConsumerDocument
Registry

Query Registry2850__________________________________________________________________________
139
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Actor: Document Consumer
Role: Generates Query Registry messages and sends them to the Document Registry.
Actor: Document Registry2855

Role: Receives Query Registry messages and executes a query against registry metadata to
select and return matching data to the Document Consumer.
3.16.3 Referenced Standard
ebRS

OASIS/ebXML Registry Services Specifications v2.0

SQL

ISO/IEC 9075 Database Language SQL

3.16.4 Interaction Diagram
Document
ConsumerDocument
Registry

Query Registry

Query Registry
Acknowledgment2860
3.16.4.1 Query RegistryThis is the query request to the registry from a Document Consumer.
3.16.4.1.1

Trigger Events

This message is initiated when the Document consumer wants to retrieve document metadata.
2865

3.16.4.1.2

Message Semantics

XDS specifies the use of SQL as a query language to the registry. There are 2 significant
parameters to an AdHocQueryRequest (HTTP-SOAP):

2870

•

returnType•

SQL query text

3.16.4.1.2.1 Parameter returnType
XDS supports the following values for the parameter returnType:__________________________________________________________________________
140
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•

ObjectRef – a list of object UUIDs (references)•

LeafClass – list of XML elements representing the leaf class of the object returned

3.16.4.1.2.2 SQL query text
2875

2880

SQL queries submitted to an XDS Document Registry shall conform to the ebRS Registry
Services specification, which maps elements of the information model (ebRIM) into a collectionof SQL views.
The next sections show the details of several useful queries. This is not an exhaustive list. Any
valid SQL query written against the registry information model (ebRIM+XDS specialization)
may be used. The specific SQL subset used by registry is specified in Appendix D of ebRS.
3.16.4.1.2.3 Security Requirements
Relevant security requirements are discussed in the Register Document transaction (see ITI TF1: 3.14.4.1.2.14).
3.16.4.1.3

2885

Expected Actions

The registry returns a Query Registry Acknowledgment message.
3.16.4.1.4

Minimum Query Catalog

The queries documented in this section form a minimal set of queries needed by Document
Consumers to discover documents in XDS.
2890

It is the responsibility of the Document Consumer to package the SQL from any of these
Minimum Queries listed below into a Query transaction.

2895

All implementations of the Registry actor shall support all queries, including parts labeled
optional, that are documented in this section. Document Consumer actors shall be able to dependon these queries to be supported by XDS Registry actors. XDS Registry actors may reject queries
not in this query catalog. For example, XDS Registry actors may reject queries using the SQL
keyword ‘LIKE’ except where noted in the following queries.
Each query is documented as a pseudo-function showing a simple name and a list of arguments.
Many parameters end in ‘|*’ indicating that the parameter is optional. Each parameter isnumbered. The tables showing the SQL are labeled with these numbers so individual lines of
SQL can be associated with a parameter of the pseudo-function defining the query.

2900

Queries whose names start with ‘Find’ are broad, keyword-based searches focused on a single
patient ID. Queries whose names start with ‘Get’ are simpler retrieval-style searches.
Query Parameters__________________________________________________________________________
141
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

2905

2910

Each query is represented as a function with parameters. The parameters are numbered and theParm column in each query definition table indicates which parameter a particular row of thetable supports. Additionally, each query parameter is supported by one or more detail parameters.
For example, the query parameter fromDateTime is supported by detail parameters $timeSlot,$lowerTime, and $uppertime where $timeSlot indicates the name of the slot (there are 3) that isbeing tested and $lowerTime and $upperTime give the time range of interest. If a queryparameter like fromDateTime is used then all of its detail parameters must be filled in. If thisquery parameter is not used, then all rows with a Parm showing that query's number are to be
removed from the query.
All DateTime values are formatted as YYMMDDHHMMSS. All time comparisons are:LowerDateTime <= DateTime < UpperDateTime

2915

Some parameters are labeled as being in 'value list' format. A value list has the format:( 'value1', 'value2' )The single quotes around the list items are required. The list format, parentheses and comma
separation are required.
All values (constants) are set into single quotes, for example a dateTime value of '200412252359'.

2920

When using the LIKE clause, the wildcard character is ‘%’.

3.16.4.1.4.1 FindDocuments

2925

FindDocuments((1)patientId, (2)classCode|*, (3)dateTimeRange|*,(4)practiceSettingCode|*, (5)healthcareFacilityTypeCode|*,(6)eventCodeList|*, (7)status)

Find documents (XDSDocumentEntry) objects in the registry for a given patientID given a hostof parameters to match.
Query Parameter

Detail Parameters(1) patientID$patientId – patientID including domain(2) classCode$classCodes – value list of classCodes(3) dateTimeRange$dateTimeAtt – slot name of dateTime attribute$dateTimeFrom – lower dateTime bound$dateTimeTo – upper dateTime bound__________________________________________________________________________
142
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________(4) practiceSettingCode$psCodes – value list of practiceSettingCodes(5) healthcareFacilityTypeCode$hcftCodes – value list ofhealthcareFacilityTypeCodes(6) eventCodeList$evCodes – value list of eventCodes(7) status$status – value list – choose either(‘Approved’)OR(‘Approved’, ‘Deprecated’ )OR(‘Deprecated’)

2930•

Returns a sequence of XDSDocumentEntry metadata for documents.

•

Date/Time based on serviceStartTime or serviceStopTime or creationTime.

•

Query can target documents that are Approved or Deprecated or both

Parm

SQL

Opt

Comments
Returns ExtrinsicObjects

SELECT doc.id
FROM ExtrinsicObject doc,
ExternalIdentifier patId
2, Classification clCode

Yes

Required only if usingclassCode3, Slot dateTime

Yes

Required if selecting on a
DateTime attribute5, Classification psc

Yes

Required if using
XDSDocumentEntry.practiceSettin
gCode

6

, Classification hftc

Yes

Required if using
XDSDocumentEntry.healthcareFaci
lityTypeCodes

7, Classification ecl

Yes

Required if using
XDSDocumentEntry.eventCodeList

WHERE
doc.objectType = 'urn:uuid:7edca82f054d-47f2-a032-9b2a5b5186c1'

Select XDSDocumentEntry objects
only__________________________________________________________________________
143
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1

Select on patientIDAND (doc.id = patId.registryobject AND
patId.identificationScheme='urn:uuid:58a6f841-87b3-4a3e-92fda8ffeff98427'
AND patId.value = $patientId )

2

AND (

Yes

Select on classCode.

Yes

Select on dateTimeRange

Yes

Select on practiceSettingCodes

Yes

Select on
healthcareFacilityTypeCodes

Yes

Select on eventCodeList

clCode.classifiedobject = doc.id
AND clCode.classificationScheme ='urn:uuid:41a5887f-8865-4c09-adf7e362475b143a'
AND clCode.nodeRepresentation IN$classCodes )3AND( dateTime.parent = doc.id
AND dateTime.name = $dateTimeAtt
AND dateTime.value >= $dateTimeFrom
AND dateTime.value &lt;
$dateTimeTo )

4

AND (
psc.classifiedObject = doc.id
AND psc.classificationScheme='urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead'
AND psc.nodeRepresentation IN$psCodes )

5

AND (
hftc.classifiedObject = doc.id AND
hftc.classificationScheme ='urn:uuid:f33fb8ac-18af-42cc-ae0eed0b0bdb91e1'
AND hftc.nodeRepresentation IN$hcftCodes )

6

AND (
ecl.classifiedObject = doc.id
AND ecl.classificationScheme ='urn:uuid:2c6b8cb7-8b2a-4051-b291b1ae6a575ef4'
AND ecl.nodeRepresentation IN__________________________________________________________________________
144
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________$evCodes )7

AND doc.status IN $status

Select on document status

2935
3.16.4.1.4.2 FindSubmissionSets
FindSubmissionSets((1)patientId, (2)sourceId|*,(3)dateTimeRange|*, (4)authorPerson|*, (5)contentTypeCode|*)

2940

Find submission sets (XDSSubmissionSet objects) in the registry for a given patientID given ahost of parameters to match.
Query Parameter

Detail Parameters(1) patientID$patientId – patientID including domain(2) sourceId$sourceIds – value list of sourceId(3) dateTimeRange$dateTimeAtt – slot name of dateTime attribute$dateTimeFrom – lower dateTime bound$dateTimeTo – upper dateTime bound(4) authorPerson$authorPattern – LIKE pattern for authorPerson(5) contentTypeCode$contentTypeCodes – value list of contentTypeCode

•
2945
Parm

This query returns XDSSubmissionSet metadata only. Use GetSubmissionSetContents ()to drill down.
SQL

Opt

SELECT ss.id

Comments
Returns SubmissionSets

FROM RegistryPackage ss,
ExternalIdentifier patId,
Classification c
2, ExternalIdentifier sid

YessourceId3, Slot dateTime

Yes

dateTime range

4, Slot ap

Yes

authorPerson

5, Classification ctc

Yes

contentTypeCode

WHERE__________________________________________________________________________
145
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Select XDSSubmissionSet object
only

c.classifiedObject = ss.id
AND c.classificationNode ='urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd'

1

AND ss.status = 'Approved'

Select only Approved submission
sets

AND (

Select on patientID

ss.id = patId.registryobject
AND patId.identificationScheme='urn:uuid:6b5aea1a-874d-4603-a4bc96a0a7b38446'
AND patId.value = $patientId )
2

AND (

Yes

Select on sourceId

Yes

Select on dateTimeRange

Yes

Select on authorPerson

Yes

Select on contentTypeCodesid.registryobject = ss.id
AND sid.identificationScheme ='urn:uuid:554ac39e-e3fe-47fe-b233965d2a147832'
AND sid.value IN $sourceIds )3AND( dateTime.parent = ss.id
AND dateTime.name = $dateTimeAtt
AND dateTime.value >= $dateTimeFrom
AND dateTime.value &lt;
$dateTimeTo )

4

AND (
ap.parent = ss.id
AND ap.name = 'authorPerson'
AND ap.value LIKE $authorPattern )

5

AND (
ctc.classifiedObject = ss.id
AND ctc.classificationScheme='urn:uuid:aa543740-bdda-424e-8c96df4873be8500'
AND ctc.nodeRepresentation IN$contentTypeCodes )__________________________________________________________________________
146
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.16.4.1.4.3 FindFolders
FindFolders((1)patientId, (2)updatedSince|*, (3)codeList|*)2950

Find folder (XDSFolder object) in the registry for a given patientID given a host of parameters tomatch.
Query Parameter

Detail Parameters(1) patientID$patientId – patientID including domain(2) updatedSince$lastUpdateTime – dateTime value(3) codeList$codes – value list from codeList•

This query returns XDSFolder object only.

2955
Parm

SQL

Opt

Comments
Returns Folders

SELECT fol.id
FROM RegistryPackage fol,
ExternalIdentifier patId,
Classification c
2, Slot lut

Yes

lastUpdateTime

3, Classification cl

YescodeList

WHERE
Select XDSFolder objects only

( c.classifiedObject = fol.id
AND c.classificationNode ='urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2' )1AND fol.status = ‘Approved’

Select only Approved folders

AND (Select on patientID

patId.registryobject = fol.id
AND patId.identificationScheme ='urn:uuid:f64ffdf0-4b97-4e06-b79fa52b38ec2f8a'
AND patId.value = $patientId )
2

AND (

Yes

Select on lastUpdateTime

lut.parent = fol.id
AND lut.name = 'lastUpdateTime'__________________________________________________________________________
147
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________AND lut.value >= $lastUpdateTime )
3

Yes

AND (

Select on codeList

cl.classifiedObject = fol.id
AND cl.classificationScheme ='urn:uuid:1ba97051-7806-41a8-a48b8fce7af683c5'
AND cl.nodeRepresentation IN$codes )3.16.4.1.4.4 GetAll
GetAll((1)patientId, (2)status)

2960

Get all XDSSubmissionSet, XDSDocumentEntry, and XDSFolder instances associated with thespecified patient ID.
Query Parameter

Detail Parameters(1) patientID$patientId – patientID including domain(2) status$status – value list – choose either(‘Approved’)OR(‘Approved’, ‘Deprecated’ )OR(‘Deprecated’)

2965

•

Query can target documents that are Approved or Deprecated or both•

Association objects are included

Parm

SQL
SELECT roAndAss.id
FROM RegistryObject ro,

Opt

Comments
Returns RegistryObjects(submisson sets, folders, docs,
associations)

ExtrinsicObject doc, RegistryPackage__________________________________________________________________________
148
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
ss, RegistryPackage fol, Association
ass
WHERE
doc.id IN (Select documents on patientId

SELECT doc.id FROM ExtrinsicObject
doc, ExternalIdentifier patId
WHERE
doc.objectType = 'urn:uuid:7edca82f054d-47f2-a032-9b2a5b5186c1' AND
patId.registryObject = doc.id AND
patId.identificationScheme ='urn:uuid:58a6f841-87b3-4a3e-92fda8ffeff98427' AND
patId.value = $patientId)
AND ss.id IN (SELECT ss.id FROM RegistryPackage
ss, Classification ssCl,
ExternalIdentifier patId

Select submission sets onpatientId

WHERE
ssCL.classifiedObject = ss.id AND
ssCL.classificationScheme ='urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd' AND
patId.registryObject = ss.id AND
patId.identificationScheme ='urn:uuid:6b5aea1a-874d-4603-a4bc96a0a7b38446' AND
patId.value = $patientId)
AND fol.id IN (Select folders on patientId

SELECT fol.id FROM RegistryPackage
fol, Classification folCl,
ExternalIdentifier patId
WHERE
folCL.classifiedObject = fol.id AND
folCL.classificationScheme ='urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2' AND__________________________________________________________________________
149
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
patId.registryObject = fol.id AND
patId.identificationScheme ='urn:uuid:f64ffdf0-4b97-4e06-b79fa52b38ec2f8a' AND
patId.value = $patientId)
AND ro.id IN ( ss.id, fol.id,
doc.id )Collect submission sets,folders, and documents

AND ro.status IN $status

Status is appropriate

AND ass.id IN (Collect associations linking
the above documents, submission
sets, and folders

SELECT ass.id FROM Association ass
WHERE
ass.sourceObject IN ( ro.id ) AND
ass.targetObject IN ( ro.id ))AND roAndAss in ( ro.id, ass.id )Combine submission sets,folders, documents, andassocations

3.16.4.1.4.5 GetDocument
GetDocument((1)XDSDocument.UUID|*, (2)XDSDocument.uniqueId|*)
2970

This query returns the specified document given either the entry UUID or uniqueId of the
document.
Query Parameter

Detail Parameters(1) UUID$uuid – UUID of document(2) uniqueId$uniqueId – uniqueId of document•

Parameter 1 OR 2 must be specified.

2975
Parm

SQL

Opt

Comments

SELECT doc.id
FROM ExtrinsicObject doc__________________________________________________________________________
150
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
WHERE
doc.id IN (
1

$uuid

Yes

Select by UUID

2

SELECT doc.id FROM ExtrinsicObject
doc, ExternalIdentifier uniqId

Yes

Select by uniqueId

WHERE
uniId.registryobject = doc.id AND
uniId.identificationScheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab' AND
uniId.value=$uniqueId)

3.16.4.1.4.6 GetSubmissionSetContents
GetSubmissionSetContents((1)XDSSubmissionSet.UUID,(2)XDSSubmissionSet.uniqueId)
2980

This query returns the specified submission set, all contained documents and folders, and theassociations that relate these elements.
Query Parameter

Detail Parameters(1) UUID$uuid – UUID of submission set(2) uniqueId$uniqueId – uniqueId of submission set•

Parameter 1 OR 2 must be specified.

2985
Parm

SQL
SELECT roAndAss.id
FROM RegistryObject ro,

Opt

Comments
Returns RegistryObjects(submisson sets, folders, docs,
associations)

ExtrinsicObject doc, RegistryPackage
ss, RegistryPackage fol, Association
ass
WHERE
ss.id IN (Select submission set__________________________________________________________________________
151
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1

$uuid

Yes

2

SELECT ss.id FROM RegistryPackage
ss, ExternalIdentifier uniqId

Yes

WHERE
uniqId.registryObject = ss.id AND
uniqId.identificationScheme ='urn:uuid:96fdda7c-d067-4183-912ebf5ee74998a8' AND
uniqId.value = $uniqueId) AND doc.id IN (Select documents

SELECT doc.id FROM ExtrinsicObject
doc, Association aWHEREa.associationType = 'HasMember' AND
a.sourceObject = ss.id AND
a.targetObject = doc.id AND
doc.objectType = 'urn:uuid:7edca82f054d-47f2-a032-9b2a5b5186c1')
AND fol.id IN (Select folders

SELECT fol.id FROM RegistryPackage
fol, Classification folCl,
Association aWHEREa.associationType = 'HasMember' AND
a.sourceObject = ss.id AND
a.targetObject = fol.id AND
folCL.classifiedObject = fol.id AND
folCL.classificationScheme ='urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2') AND
ro.id IN ( ss.id, fol.id, doc.id )AND

Collect submission sets,folders, and documents

ass.id IN (Collect associations linking
the above documents, submission
sets, and folders

SELECT ass.id FROM Association ass__________________________________________________________________________
152
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
WHERE
ass.sourceObject IN ( ro.id ) AND
ass.targetObject IN ( ro.id )) AND
roAndAss in ( ro.id, ass.id )Combine submission sets,folders, documents, andassocations

3.16.4.1.4.7 GetFolderContents
GetFolderContents((1)XDSFolder.UUID, (2)XDSFolder.uniqueId)
2990

This query returns an XDSFolder, the XDSSubmissionSet it is associated with and the collectionof documents currently associated with the folder.
Query Parameter

Detail Parameters(1) UUID$uuid – UUID of folder(2) uniqueId$uniqueId – uniqueId of folder•

This query only retrieves metadata for Approved documents.

2995
Parm

SQL

Opt

Comments

SELECT ro.id
FROM RegistryObject ro,
RegistryPackage fol, RegistryPackage
ss, ExtrinsicObject docEnt
WHERE
1

fol.id = $uuid

Yes

Use only if selecting by UUID

2

fol.id IN (SELECT fol.id

Yes

Use only if selecting by
uniqueId

FROM RegistryPackage fol,
ExternalIdentifier uniId
WHERE__________________________________________________________________________
153
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
AND fol.id = uniId.registryObject
AND uniId.identificationScheme ='urn:uuid:75df8f67-9973-4fbe-a900df66cefecc5a'
AND uniId.value = $uniqueId )AND ss.id IN (SELECT ss.id

Select XDSSubmission Set

FROM RegistryPackage ss, Associationass, ExternalIdentifier uniqId
WHERE
ss.id = ass.sourceObject
AND ass.associationtype='HasMember'
AND ass.targetObject = fol.id
AND uniqId.registryObject = ss.id
AND uniqId.identificationScheme='urn:uuid:96fdda7c-d067-4183-912ebf5ee74998a8')
AND docEnt.id IN (SELECT docEnt.id
FROM ExtrinsicObject docEnt,
Association ass, ExternalIdentifier
uniqIdSelect XDSDocuments in
XDSFolder

WHERE
fol.id = ass.sourceObject
AND ass.associationtype='HasMember'
AND ass.targetObject = docEnt.id
AND uniqId.registryObject =docEnt.id
AND uniqId.identificationScheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab' )AND ro.id IN (fol.id, ss.id,
docEnt.id)

Gather Folder, Submission Set,
and Documents

AND ro.status = 'Approved'

Approved object only

3.16.4.1.4.8 GetFoldersForDocument
GetFoldersForDocument((1)XDSDocument.UUID|*,(2)XDSDocument.uniqueId|*)
3000

Return a list of XDSFolder metadata for each folder associated with a specified document.
__________________________________________________________________________
154
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Query Parameter

Detail Parameters(1) UUID$uuid – UUID of document(2) uniqueId$uniqueId – uniqueId of document•
Parm

This query can identify the document by UUID or uniqueId.
SQL

Opt

Comments

SELECT fol.id
FROM RegistryPackage fol,
Association ass, Classification
class, ExtrinsicObject doc
WHERE
1

doc.id = $uuid

Yes

Use only if selecting by UUID.

2

doc.id IN

Yes

Use only if selecting by
uniqueId.

(SELECT doc.id
FROM ExtrinsicObject doc,
ExternalIdentifier uniId
WHERE uniId.registryobject = doc.id
AND uniId.identificationscheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab'
AND uniId.value = $uniqueId)
AND (ass.associationtype = 'HasMember'

Linkage from document toRegistryPackage.

AND ass.sourceobject = fol.id
AND ass.targetObject = doc.id )AND (class.classifiedObject = fol.id
AND class.classificationnode ='urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2' )Verify RegistryPackage is
XDSFolder.

AND fol.status = 'Approved'3005__________________________________________________________________________
155
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.16.4.1.4.9 GetAddendums
GetAddendums((1)documentUUID, (2)documentUniqueId)

3010

Query Parameter

Detail Parameters(1) UUID$uuid – UUID of document(2) uniqueId$uniqueId – uniqueId of document

Given a document UUID or uniqueId, return all addendums for this document.
Parm

SQL
SELECT add.id
FROM ExtrinsicObject add,
ExtrinsicObject doc, Association a

Opt

Comments

WHERE
1

doc.id = $uuid

Yes

Select document by UUID

2

doc.id IN (Yes

Select document by uniqueId

SELECT ExtrinsicObject doc,
ExternalIdentifier uniqId
WHERE
uniId.registryobject = doc.id AND
uniId.identificationScheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab' AND
uniId.value=$uniqueId)
AND (a.associationType = 'APND'
AND a.sourceObject = add.id
AND a.targetObject = doc.id )3.16.4.1.4.10 GetHistory
GetHistory((1)documentUUID, (2)documentUniqueId)__________________________________________________________________________
156
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3015

Given a document UUID or uniqueId, return the document linked to this document by a RPLC
association if it exists.
Query Parameter

Detail Parameters(1) UUID$uuid – UUID of document(2) uniqueId$uniqueId – uniqueId of document

The document identified in this query need not be an Approved document.
3020
Parm

SQL
SELECT rplc.id
FROM ExtrinsicObject rplc,
ExtrinsicObject doc, Association a

Opt

Comments

WHERE
1

doc.id = $uuid

Yes

Select document by UUID

2

doc.id IN (Yes

Select document by uniqueId

SELECT ExtrinsicObject doc,
ExternalIdentifier uniqId
WHERE
uniId.registryobject = doc.id AND
uniId.identificationScheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab' AND
uniId.value=$uniqueId)
AND (a.associationType = 'RPLC'
AND a.targetObject = rplc.id
AND a.sourceObject = doc.id )3.16.4.1.4.11 GetTransformations
GetTransformations((1)documentUUID, (2)documentUniqueId)
Given a document UUID or uniqueId, return all transformations for the document.
3025__________________________________________________________________________
157
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Query Parameter

Detail Parameters(1) UUID$uuid – UUID of document(2) uniqueId$uniqueId – uniqueId of document

Parm

SQL
SELECT xfrm.id
FROM ExtrinsicObject xfrm,
ExtrinsicObject doc, Association a

Opt

Comments

WHERE
1

doc.id = $uuid

Yes

Select by UUID

2

doc.id IN (Yes

Select by uniqueId

SELECT ExtrinsicObject doc,
ExternalIdentifier uniqId
WHERE
uniId.registryobject = doc.id AND
uniId.identificationScheme ='urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab' AND
uniId.value=$uniqueId)
AND (a.associationType = 'XFRM'
AND a.sourceObject = xfrm.id
AND a.targetObject = doc.id )3.16.4.2 Query Registry Acknowledgement
This is the response to the Query Registry message.
3030

3.16.4.2.1

Trigger Events

Completion of query initiated by a Query Registry message.
3.16.4.2.2

Message Semantics

The Query Registry Acknowledgement (AdhocQueryResponse) is returned in one of threeforms:__________________________________________________________________________
158
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3035

1. List of ObjectRefs
2. Registry metadata describing objects found by query
3. Error message
3.16.4.2.3

3040

Expected Actions

The Document Consumer may process the returned registry data, retrieve documents based on
the metadata if the necessary metadata was returned, or handle returned errors__________________________________________________________________________
159
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.17 Retrieve Document
This section corresponds to Transaction ITI-17 of the IHE Technical Framework. The Document
Consumer and Document Repository actors use transaction ITI-17.
3.17.1 Scope
3045

This transaction is used by the Document Consumer to retrieve a document from the Document
Repository. The Document Consumer has already obtained the URI information from theDocument Registry by means of the Query Registry transaction.
3.17.2 Use Case Roles
Document
ConsumerDocument
Repository

Retrieve
Document

3050

Actor: Document Consumer
Role: Obtains document.
Actor: Document Repository
Role: Provides documents.
3.17.3 Referenced Standard
HTTP

Hyper Text Transfer Protocol HTTP 1.1 (RFC 2616)

MIME

Multipurpose Internet Message Extensions (RFC 2045 to RFC 2049)

SMTP

Simple Mail Transfer Protocol (RFC 2821)

Multipart/Related

The MIME Multipart/Related Content-type (RFC 2387)

3055__________________________________________________________________________
160
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.17.4 Interaction Diagram
Document
ConsumerDocument
Repository

Retrieve Document Request

Retrieve Document Response

3.17.4.1 Retrieve Document Request
3.17.4.1.1
3060

Trigger Events

The Document Consumer obtains document URIs via theQuery Registry transaction.
3.17.4.1.2

3065

Message Semantics

The URI specifies the protocol and protocol parameters that are to be used to retrieve thedocument. The Document Repository shall support the following parameters for protocol in the
URI:
•
HTTP
The details of URI handling are specified in the HTTP standard (RFC 2616).
The Document Repository shall fully implement support for any protocol parameters that are
required by the HTTP standard.

3070

3.17.4.1.2.1 Request Headers

3075

The HTTP Protocol specifies a variety of request headers that can affect the result returned by
the server. Document Consumers may use any request header allowed by the HTTP Protocol6.
However, XDS Repositories are not required to acknowledge or support of these headers not
required by the protocol, and may be required in certain cases to ignore certain headers. See thetable below for details.
Request Header
6

Repository

Comments

Ed Note: To allow common web browsers to be used without restriction.

__________________________________________________________________________
161
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
SupportAcceptAccept-Charset
Accept-Language

AlwaysIgnored

These headers, if used by the Repository could in fact alter
the content returned from the repository, and so must be
ignored by the repository. [inconsistent with RID].

Accept-Encoding

O

This header requests that an encoded form the data be
returned [e.g., gzip or compress]. Repositories may support
this header, but are not required to. Document Consumers
must support responses that ignore this content header.

Authorization

O

This header may be sent in environments where EUA is usedwith XDS. See the EUA profile for more details.

If-Modified-Since

O

Since Repositories are not expected to change documents
once stored, they are free to ignore this header or respond as
appropriate.

3.17.4.1.2.2 Security Requirements
3080

Relevant security requirements are discussed in the Register Document transaction (see ITI TF1: 3.14.4.1.2.14).
3.17.4.1.3

Expected Actions

A Retrieve Document Response will be generated in return. Details are specified in the HTTP
standard.
3.17.4.2 Retrieve Document Response
3085

3.17.4.2.1

Trigger Events

This message is triggered by the:Retrieve Document Request.
3.17.4.2.2

Message Semantics

XDS Repositories are required to return the following values:
3090
Response Code

When to Return

Support200 – OK

If the request is valid and data is available.

R

304 – Not Modified

If the request is a valid conditional GET [see HTTP O__________________________________________________________________________
162
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
specification], and the document has not been
modified since the requested modification date.
400 – Bad Request

If the request is not valid.

R

401 – Authorization Required

If the request requires authentication, and an
Authorization header is not present, or is not valid.
Used in conjunction with EUA.

O

403 – Forbidden

If access needs to be denied for reasons other thanauthentication failure [e.g., because the request
comes from a Node that is not allowed access tothe document].

R

404 – Not Found

If the request is syntactically valid, but the
document cannot be located, or does not otherwise
exist [see RID].

R

410 – Gone

If the request is valid, and the document once
existed, but is no longer available [e.g., thedocument may have been removed at the patients
request].

O

5XX – Server Error

The server may return any error code beginningwith the digit 5 to indicate a server error.

O

3.17.4.2.2.1 Response Headers
The HTTP Protocol specifies a variety of response headers that provide more information about
the response. The use of these headers is described in the table below:
3095
Response Header

Repository
SupportComments

ExpiresR

Any valid value according to RFC2616, or 0 [c.f. RID
volume ]Content-EncodingO

If the Document consumer requested encoding of the
response, and the repository is able to fulfill that request,
it must return the appropriate value in this header.

Content-TypeR

These headers correspond to the mimeType,languageCode, and size attributes of the__________________________________________________________________________
163
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Content-Language
Content-LengthO

XDSDocumentEntry. Content-Type is required in the
response7. The other two are optional, but if present,
must be the same as the values provided to the registry.

Last-Modified

R

This header should correspond to the date the document
was first stored in the repository [if known], or the dateof document creation[XDSDocumentEntry.creationTime].

WWW-AuthenticateO

If the XDS Repository requires authentication and therequest did not contain valid credentials, this header must
be returned in the 401 response.

3.17.4.2.2.2 Security Requirements
Relevant security requirements are discussed in the Register Document transaction (see ITI TF1: 3.14.4.1.2.14).
3100

3.17.4.2.3

Expected Actions

The Document Consumer now has the content of the document to process.

7

This is to allow browser-based document consumers to activate the appropriate viewer based on the type of data
present, without requiring that information to be known in advance before the request is made.

__________________________________________________________________________
164
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.18 Intentionally Left Blank (ITI-18)__________________________________________________________________________
165
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.19 Authenticate Node3105

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

3110

In addition, the Secure Node authenticates the identity of the user who requests access to thenode. This user authentication is a local operation that does not involve communication with aremote node.
3.19.2 Use Case Roles
S ecureN od eSecureN o deU ser

A uthenticate
N ode

3115

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 thenode.
Actor: User

3120

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

3.19.3 Referenced Standards
DICOM 2003 PS 3.15:
Security Profiles. Annex B1: The Basic TLS Secure Transport Connection profile.
__________________________________________________________________________
166
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3125

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

3130

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

RemoteSecure Node

Authenticate Node

Authenticate Node

Local User Authentication

3.19.5 Trigger Events

3135

The Local Secure Node starts the authentication process with the Remote Secure Node when
information exchange between the two nodes is requested. The first transaction shall be theAuthenticate Node transaction, and all other PHI transactions performed by IHE actors shall be
secure transactions. This authentication process is needed when a secure connection isestablished.
The Basic Secure Node shall always apply the Authenticate Node process to every DICOM,HTTP, or HL7 connection.

3140

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
standard that are used for the connection. HL7 and DICOM transactions are required to adhere__________________________________________________________________________
167
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3145

to the specifications in this section. All Secure Nodes shall be configurable for use on aphysically 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.

3150

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
supported:
TLS_RSA_WITH_AES_128_CBC_SHA.

3155

3160

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 isconfigured 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 theidentities of the trusted nodes. Certificates shall use the X.509 standard.

3165

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
removable media or network interchange. Implementation must support the configuration of alist of authorized nodes (see ITI TF-2: Appendix A). Connections shall only be accepted fromthe authorized nodes on the list and connections only attempted to nodes on the list.

3170

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

3175

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

__________________________________________________________________________
168
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3180

SSL connections are similar in only authenticating the server node. This is not suitable for use in thetransfer of PHI. Secured HTTP communications will require the use of either browser extensions likeapplets, modified browsers, 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
3185

3190

3195

3200

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 successfullycompleted 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 beestablished by the Secure Node actor based on methods such as:• Username with Password• 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 Nodeshall 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 ofthe 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.
3.19.7.1 Example: Team approach

3205

3210

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 theprocedure log (which may be paper or electronic), and it is assumed that all have accessed thedata even though they were not (and cannot be in most cases) actually logged on to the piece ofequipment.
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 andthat the system authenticate the new operator.
3.19.7.2 Example: Access to locked exam room, no user logon on modality.
There may be situations where the acquisition modality has no user logon features, and access tothe equipment is controlled by controlling access to the examination room. In these situations an__________________________________________________________________________
169
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3215

equipment-specific user ID will be used, and access to the room should be recorded in theprocedure log (which may be paper or electronic).
3.19.7.3 Example: Enterprise User Authentication
The healthcare enterprise may implement local user authentication using the Enterprise User
Authentication Profile (EUA). This implementation may be mixed with other non-EUA accessto the secure domain, based upon each node’s internal use an EUA availability.

__________________________________________________________________________
170
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3220

3.20 Record Audit Event
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

3225

In the Record Audit Event transaction, the IHE actor creates an entry in the Audit Log at the
Audit Record Repository.
3.20.2 Use Case Roles
Any
Application
or
Actor

Audit Record
Repository

RecordAudit Event

3230

Application or Actor: Any actor or any other application that is grouped with the Secure Node
Actor.
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

3235

IETF:

The BSD Syslog Protocol. (RFC 3164);
Reliable Delivery for Syslog (RFC 3195);
Security Audit and Access Accountability Message XML Data Definitionsfor Healthcare Applications (RFC 3881).

3240

DICOM:

Supplement 95

ASTM:

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

__________________________________________________________________________
171
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________W3C:

Recommendation: Extensible Markup Language (XML) 1.0

3.20.4 Interaction Diagram
Audit Record
Repository

Any IHE
Actor or any PHI
application

Record Audit
Event

3245

3.20.5 Record Audit Event
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

3250

3255

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
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 meansof 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 withIHE 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)“Application Activity”

Audit-Log-Used

The audit trail repository has been accessed or modified bysomething other than the arrival of audit trail messages.

DICOM (Sup 95) “Audit
Log Used”

Begin-storing-instances

Begin storing SOP Instances for a study. This may be a mix
of instances.

DICOM (Sup 95) “Begin
Transferring DICOM__________________________________________________________________________
172
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Trigger Event

Description

Source Vocabulary
Instances”

Health-service-event

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

IHE Extension (section
3.20.7.3) “Health Services
Provision Event”

Instances-deleted

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

DICOM (Sup 95)“DICOM Instances
Accessed” or “DICOM
Study Deleted”

Instances-Stored

Instances for a particular study have been stored on thissystem. One event covers all instances stored for theparticular study.

DICOM (Sup 95)“DICOM Instances
Transferred”

Medication

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

IHE Extension (section
3.20.7.3) “Medication
Event”

See note below.
Mobile-machine-event

Mobile machine joins or leaves secure domain.

DICOM (Sup 95)“Network Entry”

Node-Authentication-failure

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

DICOM (Sup 95)“Security Alert”

Order-record-event

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

DICOM (Sup 95) “Order
Record”

Patient-care-assignment

Staffing or participant assignment actions relevant to theassignment of healthcare professionals, caregivers attending
physician, residents, medical students, consultants, etc. to apatient It also includes change in assigned role orauthorization, e.g., relative to healthcare status change, andde-assignment

IHE Extension (section
3.20.7.3) “Patient Care
Resource Assignment”

Patient-care-episodeSpecific 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.

IHE Extension (section
3.20.7.3) “Patient Care
Episode”

Patient-care-protocol

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

IHE Extension (section
3.209.7.3) “Patient Care
Protocol”

Patient-record-event

Patient record created, modified, or accessed.

DICOM (Sup 95) “Patient
Record”

PHI-export

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

DICOM (Sup 95)“Export”

PHI-import

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

DICOM (Sup 95)“Import”

Procedure-record-event

Procedure record created, modified, accessed or deleted.

DICOM (Sup 95)__________________________________________________________________________
173
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Trigger Event

Description

Source Vocabulary“Procedure Record”

Query Information

Security Administration

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

Administrative actions create, modify, delete, query, anddisplay 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 theapplication functions used for patient management,
clinical processes, registry of business objects andmethods, 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 datasuch as patient management, nursing, clinical, etc.

5.

The allowable access permissions associated withfunctions 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 forrole-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.

DICOM (Sup 95) “Query”

DICOM (Sup 95)“Security Alert”

10. User authenticaton, authentication failure,authentication revocation, or signoff.
11. Configuration and other changes, e.g., software
updates, that affect any software that processes
protected information. Hardware changes may also bereported in this event.
Security administration events should always be audited.
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)“DICOM Instances
Accessed”__________________________________________________________________________
174
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Trigger Event

Description

Source Vocabulary

Study-used

3260

SOP Instances from a specific study are created, modified or
DICOM (Sup 95)
accessed. One event covers all instances used for the“DICOM Instances
particular study.
Accessed”
Note: The IHE extension has reduced the scope of many of the IETF events to remove phrases like “checking forclinical contra-indications”. This is done to highlight that the events should be reported are those that are
related 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
3265

This profile defines two transport mechanisms for the audit messages:
1. Transport utilizing the Reliable Syslog protocol in “cooked” mode as defined in RFC3195.
2. Transport utilizing the BSD Syslog protocol defined in RFC-3164.

3270

3275

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 theyalso 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 arepreserved locally until they are confirmed to have been successfully stored at the recipient. Afterdelivery they may be removed at the convenience of the local machine and local functions.
3.20.6.2 Audit Record format

3280

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.
The present list of audit record schema are:

3285

5.

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

4.

IHE Provisional Audit Record format, defined below. This was previously defined aspart of the IHE Radiology technical framework. Its use is deprecated, this implies thatno extensions will be made and new applications should use the new IHE Audit Trailformat.

__________________________________________________________________________
175
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.20.6.3

Audit Message Transports

3290

The IHE actor will create the Audit Record and transmit this to the Audit Record Repository assoon 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 beentransmitted to the Audit Record Repository.

3295

Note: The Reliable Syslog protocol has explicit support for management of occasionallyconnected and mobile devices.
3.20.6.3.1

3300

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

3305

3310

3315

Reliable Syslog

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 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 aretruncated 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
must accept UTF-8 encodings and store them without damage, e.g. preserve all 8 bits.
3.20.7 Audit Message Formats

3320

3.20.7.1 RFC-3881 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 Infrastructuretechnical framework prefers use of this schema for audit records generated by all IHE actors.
The schema can be found at:
http://www.xml.org/xml/schema/7f0d86bd/healthcare-securityaudit.xsd__________________________________________________________________________
176
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3325

The DICOM Standard, Supplement 95 Audit Trail Messages provides vocabulary and further
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.

3330

For reference, the schema elements are diagrammed below. The diagrams are read from left toright: elements to the right are part of the lefthandside element.
Required single element. A NetworkEntry element
consists of exactly one MachineAction element.

3335

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
either of a LocalUser element or of a RemoteNode element.
3340

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.
•element AuditMessage
diagram__________________________________________________________________________
177
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3345•

element AuditMessage/EventIdentification
diagram•element AuditMessage/ActiveParticipant
diagram3350•

element AuditMessage/AuditSourceIdentification
diagram•element AuditMessage/ParticipantObjectIdentification
diagram__________________________________________________________________________
178
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.20.7.2 DICOM Audit Trail
3355

3360

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 arevalid. This profile does not restrict private extensions that comply with the W3C XML encoding
rules for the use of schemas, namespaces, etc.
3.20.7.3 IHE Audit Trail

3365

The DICOM standard does not address all the kinds of security and privacy events that can takeplace 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
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-3881 schema. This profile does not restrict private
extensions to the RFC-3881 schema that comply with the W3C XML encoding rules for the useof schemas, namespaces, etc.

__________________________________________________________________________
179
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3370

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
Event

Event ID

Opt.
M

Value Constraints
EV (IHE0001, IHE, “Health Services Provision Event”)
EV:

User (1..n)Patients (1)3375“C” (create)“R” (read)“U” (update)“D” (delete)

Event Action CodeM

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCodeU

not specialized

User IDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

not specialized

Participant Object Type CodeM

EV 1 (person)

Participant Object Type CodeRole

M

EV 1 (patient)

Participant Object ID Type
CodeM

EV 2 (patient ID)

Participant Object ID

M

The patient ID

Participant Object NameU

The patient name

Participant Object DetailU

Description of the event

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.

__________________________________________________________________________
180
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3380
Field Name
Event

Event ID

Opt.
M

Value Constraints
EV (IHE0002, IHE, “Medication Event”)
EV:

User (1..n)Patients (1)“C” (create)“R” (read)“U” (update)“D” (delete)

Event Action CodeM

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCodeU

not specialized

User IDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

not specialized

Participant Object Type CodeM

EV 1 (person)

Participant Object Type CodeRole

M

EV 1 (patient)

Participant Object ID Type
CodeM

EV 2 (patient ID)

Participant Object ID

M

The patient ID

Participant Object NameU

The patient name

Participant Object DetailU

Description of the event

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.3
3385

Patient Care Resource Assignment Event

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 inassigned role or authorization, e.g., relative to healthcare status change, and de-assignment.

__________________________________________________________________________
181
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Field Name
Event

Event ID

Opt.
M

Value Constraints
EV (IHE0003, IHE, “Patient Care Resource Assignment”)
EV:

User (1..n)Patients (1)“C” (create)“R” (read)“U” (update)“D” (delete)

Event Action CodeM

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCodeU

not specialized

User IDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

not specialized

Participant Object Type CodeM

EV 1 (person)

Participant Object Type CodeRole

M

EV 1 (patient)

Participant Object ID Type
CodeM

EV 2 (patient ID)

Participant Object ID

M

The patient ID

Participant Object NameU

The patient name

Participant Object DetailU

Description of the event

3390
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.4
3395

Patient Care Episode Event

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.

__________________________________________________________________________
182
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Field Name
Event

Event ID

Opt.

Value Constraints

M

EV (IHE0004, IHE, “Patient Care Episode”)
EV:

User (1..n)Patients (1)

3400

M

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCodeU

not specialized

User IDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

not specialized

Participant Object Type CodeM

EV 1 (person)

Participant Object Type CodeRole

M

EV 1 (patient)

Participant Object ID Type
CodeM

EV 2 (patient ID)

Participant Object ID

M

The patient ID

Participant Object NameU

The patient name

Participant Object DetailU

Description of the event

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

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

Event Action CodePatient 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, andcancellation.

__________________________________________________________________________
183
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Field Name
Event

Event ID

Opt.

Value Constraints

M

EV (IHE0005, IHE, “Patient Care Protocol”)
EV:

User (1..n)Patients (1)“C” (create)“R” (read)“U” (update)“D” (delete)

Event Action CodeM

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCodeU

not specialized

User IDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

not specialized

Participant Object Type CodeM

EV 1 (person)

Participant Object Type CodeRole

M

EV 1 (patient)

Participant Object ID Type
CodeM

EV 2 (patient ID)

Participant Object ID

M

The patient ID

Participant Object NameU

The patient name

Participant Object DetailU

Description of the event

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

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-3881.
3.20.7.5 Controlled Terminology for IHE Extensions
This profile defines the following controlled terminology for use in the IHE extensions.

__________________________________________________________________________
184
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3415

Context ID ccc1
Audit Event ID
Type: Extensible
Version: 2004xxxx
CodingSchemeDesignator

3420

CodingSchemeVersionCode Value

Code Meaning

IHE

IHE0001

Health Services Provision Event

IHE

IHE0002

Medication Event

IHE

IHE0003

Patient Care ResourceAssignment

IHE

IHE0004

Patient Care EpisodeIHE

IHE0005

Patient Care Protocol

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

Code Meaning

Definition

IHE0001

Health Services Provision
Event

Health services scheduled and performed
within an instance or episode of care. This
includes scheduling, initiation, updates oramendments, performing or completingthe 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 orauthorization, e.g., relative to healthcare
status change, and de-assignment

IHE0004

Patient Care EpisodeSpecific patient care episodes or problems
that occur within an instance of care. This
includes initial assignment, updates oramendments, resolution, completion, andcancellation.

IHE0005

Patient Care Protocol

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

Notes__________________________________________________________________________
185
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.20.7.6 IHE Provisional Audit Message Form

3425

3430

3435

A provisional XML Schema was defined for the contents of the audit records generated by the
IHE actors in the deprecated Basic Security Integration Profile as part of the IHE Radiology
domain. The 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 describedabove.
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 theburden on Audit Repositories which may result from processing this alternative format.
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 healthinformation.
The IHE Provisional Audit Message Schema is described in ITI TF-2: Appendix F.

__________________________________________________________________________
186
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.21 Patient Demographics Query
3440

This section corresponds to Transaction ITI-21 of the IHE Technical Framework. Transaction
ITI-21 is used by the Patient Demographics Consumer and Patient Demographics Supplier actors.
3.21.1 Scope

3445

This transaction involves a request by the Patient Demographics Consumer Actor for information
about patients whose demographic data match data provided in the query message. The request
is received by the Patient Demographics Supplier Actor. The Patient Demographics Supplier
Actor immediately processes the request and returns a response in the form of demographic
information for matching patients.
3.21.2 Use Case Roles
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient
Demographics
Query

3450

Actor: Patient Demographics Consumer
Role: Requests a list of patients matching a minimal set of demographic criteria (e.g., ID or
partial name) from the Patient Demographics Supplier. Populates its attributes withdemographic information received from the Patient Demographics Supplier.
Actor: Patient Demographics Supplier3455

Role: Returns demographic information for all patients matching the demographic criteria
provided by the Patient Demographics Consumer.

3.21.3 Referenced Standards
HL7:
3460

Version 2.5, Chapter 2 – Control

Version 2.5, Chapter 3 – Patient Administration
Version 2.5, Chapter 5 – Query__________________________________________________________________________
187
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.21.4 Interaction Diagram
Patient
Demographics
Consumer

Patient
Demographics
Supplier
Patient Demographics
Query: QBP^Q22
Patient Demographics
Response: RSP^K22

3.21.4.1 Patient Demographics Query
3465

3.21.4.1.1

Trigger Events

A Patient Demographics Consumer’s need to select a patient based on demographic information
about patients whose information matches a minimal set of known data will trigger the Patient
Demographics Query based on the following HL7 trigger event:Q22 – Find Candidates
3470

3.21.4.1.2

Message Semantics

3475

The Patient Demographics Query is conducted by the HL7 QBP^Q22 message. The Patient
Demographics Consumer actor shall generate the query message whenever it needs to selectfrom a list of patients whose information matches a minimal set of demographic data. The
segments of the message listed below are required, and their detailed descriptions are provided in
the following subsections.
Table 3.21-1 QBP Query by Parameter
QBP

Query by Parameter

Chapter in HL7 2.5

MSH

Message Header

2

QPD

Query Parameter Definition

5

RCP

Response Control Parameter5

The receiver shall respond to the query by sending the RSP^K22 message. This satisfies therequirements of original mode acknowledgment; no intermediate ACK message is to be sent.

__________________________________________________________________________
188
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3480

3.21.4.1.2.1 3.21.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2:
Appendix C.1.2).

3485

3490

The Patient Demographics Query is always targeted at a single source of patient demographic
information (referred to in this Transaction as the patient information source). When more than
one patient information source is available, Field MSH-5-Receiving Application specifies thepatient information source that this query is targeting. The Patient Demographics Supplier shallreturn this value in MSH-3-Sending Application of the ACK message and of the RSP^K22
response. Note that, in a multi-domain environment, the patient information source identified by
MSH-5 may or may not be associated with any of the Patient ID Domains listed in QPD-8-What
Domains Returned.
A list shall be published of all Receiving Applications that the Patient Demographics Suppliersupports, for the Patient Demographics Consumer to choose from. Each query is processedagainst patient demographic information associated with one and only one Patient ID Domain.

3495

Field MSH-9-Message Type shall have at least two components. The first component shall havea value of QBP; the second component shall have a value of Q22. The third component is
optional; however, if present, it shall have a value of QBP_Q21.
3.21.4.1.2.2 3.21.4.1.2.2 QPD Segment
The Patient Demographics Consumer Actor shall send attributes within the QPD segment as
described in Table 3.21-2.

3500

Table 3.21-2. IHE Profile - QPD segment
SEQ LEN DT OPT TBL# ITEM#ELEMENT NAME

1

250

CE

R

01375

Message Query Name

2

32

ST

R+

00696

Query Tag

0471

3

QIP R

Demographics Fields

8

CX

What Domains ReturnedO

Adapted from the HL7 standard, version 2.5
3.21.4.1.2.2.1

3505

3.21.4.1.2.2.1

Populating QPD-3-Demographics Fields

Field QPD-3-Demographics Fields consists of one or more repetitions, each of which contains
two components that together contain the name and value of a distinct parameter to the query.
Acceptable segments are PID and PD1.
The first component of each parameter contains the name of an HL7 element in the form@<seg>.<field no>.<component no>.<subcomponent no>__________________________________________________________________________
189
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
The above format is populated according to common HL7 usage for specifying elements used inquery parameters, as follows:3510<seg> represents a 3-character segment ID from the HL7 Standard.
<field no> is the number of a field within the segment as shown in the SEQ column of thesegment attribute table for the segment selected.

3515

3520

<component no>, for fields whose data types contain multiple components, shall contain the
cardinal number of the component being valued. For fields whose data types do not containmultiple components, <component no> shall not be valued and its preceding period shall notappear.
<subcomponent no>, for components whose data types contain multiple subcomponents, shallcontain the cardinal number of the subcomponent being valued. For components whose datatypes do not contain multiple subcomponents, <subcomponent no> shall not be valued and its
preceding period shall not appear.
The second subcomponent of each parameter contains the value that is to be matched. If it isdesired to constrain the quality of a match within the bounds of an algorithm known to the
Supplier, the algorithm and constraint values may be specified in Fields QPD-4 through QPD-7.

3525

At a minimum, the Patient Demographics Consumer may specify, and the Patient Demographics
Supplier shall support, the fields in the following table.
Table 3.21-3. PDQ Profile – QPD-3 fields required to be supported
FLD

ELEMENT NAME

PID.3

Patient Identifier List

PID.5

Patient Name

PID.7

Date/Time of Birth

PID.8

Administrative Sex

PID.11 Patient Address
PID.18 Patient Account Number

An example of parameter expressions in QPD-3:
3530@PID.5.1^SMITH~@PID.8^F

requests all patients whose family name (first component of PID-5-Patient Name) matches thevalue SMITH and whose sex (PID-8-Sex) matches the value ‘female’.

__________________________________________________________________________
190
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.21.4.1.2.2.2
3535

3540

3.21.4.1.2.2.1

Populating QPD-8-What Domains Returned

As is specified in the discussion of the Find Candidates (Q22) Query in Chapter 3 of the HL7
Standard, field QPD-8 restricts the set of domains for which identifiers are returned in PID-3:
In a multiple-domain environment, QPD-8 may be used to identify one or more domains ofinterest to the Patient Demographics Consumer and from which the Consumer wishes to obtain avalue for PID-3-Patient Identifier. Note that the patient information source designated by MSH5 may or may not be associated with any of the Patient ID Domains listed in QPD-8-What
Domains Returned.
In a single-domain environment, QPD-8 may be ignored by the Patient Demographics Supplier.
The Supplier shall always return both identifiers from the Patient ID Domain associated with thepatient information source designated by MSH-5-Receiving Application.

3545

Within field QPD-8, only component 4 (Assigning Authority) shall be valued.
The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. A discussion of how QPD-8 is processed is included in thearchitectural discussion in the “Using Patient Data Query (PDQ) in a Multi-Domain
Environment” section (ITI TF-2: Appendix M).

3550

3.21.4.1.2.3 3.21.4.1.2.3 RCP Segment
The Patient Demographics Consumer Actor shall send attributes within the RCP segment as
described in Table 3.21-5. Fields not listed are optional and may be ignored.
Table 3.21-5. IHE Profile - RCP segment
SEQ LEN DT OPT TBL# ITEM#ELEMENT NAME

1

1

ID

R

0091

00027

Query Priority

2

10

CQ O

0126

00031

Quantity Limited Request

Adapted from the HL7 standard, version 2.53555

3.21.4.1.2.3.1

3.21.4.1.2.3.1

Populating RCP-1-Query Priority

Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is tobe returned in Immediate mode.
3.21.4.1.2.3.2
3560

3.21.4.1.2.3.2

Populating RCP-2-Quantity Limited Request

The Patient Demographics Consumer Actor may request that responses to the query be sent,
using the HL7 Continuation Protocol, in increments of a specified number of patient records. (Inthe context of the HL7 query, a patient record is defined as the PID segment and any segments
accompanying it for each patient.) It is desirable to request an incremental response if the query
could result in hundreds or thousands of matches or “hits.”__________________________________________________________________________
191
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________The Patient Demographics Supplier Actor shall support the HL7 Continuation Protocol.
3565

Field RCP-2 is of data type CQ, which contains two components. The first component contains
the number of increments, while the second component contains the kind of increment, always
RD to signify that incremental replies are specified in terms of records.
For example, 50^RD requests 50 records at a time.

3570

See the “Incremental Response Processing” section (ITI TF-2: 3.21.4.1.3.3) and the “Expected
Actions” section of the Patient Demographics Query Response message (ITI TF-2: 3.21.4.2.3)
for more information on the implementation of the continuation protocol.
3.21.4.1.3

Expected Actions

3.21.4.1.3.1 3.21.4.1.3.1 Immediate Acknowledgement
3575

3580

The Patient Demographics Supplier shall immediately return an RSP^K22 response message as
specified below in Section 3.21.4.2, “Patient Demographics Response.” The RSP^K22 response
message incorporates original mode application acknowledgment as specified in the“Acknowledgment Modes” section (ITI TF-2: C.1.3). The Supplier shall use MSH-3-Sending
Application of the RSP^K22 to return the value it received from the Patient Demographics
Consumer in Field MSH-5-Receiving Application of the QBP^Q22 message.
3.21.4.1.3.2 3.21.4.1.3.2 Query Parameter Processing
The Patient Demographics Supplier Actor shall be capable of accepting, searching on, andresponding with attributes in the QPD segment as specified in Table 3.21-2.

3585

The Patient Demographics Supplier Actor must be capable of receiving all valid combinations of
subcomponents that make up the Assigning Authority component (i.e., all valid combinations of
QPD-3.8).

3590

Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented
characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplierrather than by the Patient Demographics Consumer. The Supplier shall return at least all exact
matches to the query parameters sent by the Consumer; IHE does not further specify matchingrequirements.
3.21.4.1.3.3 3.21.4.1.3.3 Incremental Response Processing
The Patient Demographics Supplier Actor shall be capable of accepting and processing attributes
in the RCP segment as listed in Table 3.21-5. In particular, the Patient Demographics Supplier
Actor shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I).

__________________________________________________________________________
192
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3595

Also, the Patient Demographics Supplier Actor shall be able to interpret RCP-2-Quantity Limited
Request to return successive responses of partial lists of records according to the HL7Continuation Protocol, as described in Section 3.21.4.2 below and in the HL7 Standard.

3.21.4.2 Patient Demographics Response
3600

3.21.4.2.1

Trigger Events

The Patient Demographics Supplier’s response to the Find Candidates message shall be thefollowing message:
K22 – Find Candidates response
3.21.4.2.2
3605

3610

Message Semantics

The Patient Demographics Response is conducted by the RSP^K22 message. The Patient
Demographics Supplier Actor shall generate this message in direct response to the QBP^Q22
message previously received. This message satisfies the Application Level, Original Mode
Acknowledgement for the HL7 QBP^Q22 message.
The segments of the message listed without enclosing square brackets in the Table below arerequired. Detailed descriptions of all segments listed in the table below are provided in thefollowing subsections. Other segments of the message are optional.
Table 3.21-6 RSP Segment Pattern Response
RSP

Segment Pattern Response

Chapter in HL7 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2[ {ERR} ]

Error

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5[ { PID

Patient Identification

3[ QRI ] } ]Query Response Instance5[ DSC ]

Continuation Pointer2[ PD1 ]__________________________________________________________________________
193
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3615

3.21.4.2.2.1 3.21.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2:
C.1.2).

3620

Field MSH-3-Sending Application specifies the patient information source that processed thequery. The Patient Demographics Supplier shall use Field MSH-3-Sending Application of the
RSP^K22 message to return the value it received from the Patient Demographics Consumer in
Field MSH-5-Receiving Application of the QBP^Q22 message.
Field MSH-9-Message Type shall have at least two components. The first component shall havea value of RSP; the second component shall have a value of K22. The third component is
optional; however, if present, it shall have a value of RSP_K22.

3625

3.21.4.2.2.2 3.21.4.2.2.2 MSA Segment
The Patient Demographics Supplier Actor is not required to send any attributes within the MSA
segment beyond what is specified in the HL7 standard. See the “Acknowledgment Modes”
section (ITI TF-2: C.1.3) for the list of all required and optional fields within the MSA segment.
3.21.4.2.2.3 3.21.4.2.2.3 QAK Segment

3630

The Patient Demographics Supplier Actor shall send attributes within the QAK segment as
defined in table 3.21-7. For the details on filling in QAK-2 (Query Response Status) refer to the“Patient Demographics Supplier Actor Query Response Behavior” section (ITI TF-2:
3.21.4.2.2.8).

3635

Table 3.21-7. PDQ Profile - QAK segment
SEQ

LEN

DT

OPT

1

32

ST

R

2

2

ID

R+

TBL#
0208

ITEM#

ELEMENT NAME

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5

3.21.4.2.2.4 3.21.4.2.2.4 QPD Segment
3640

The Patient Demographics Supplier Actor shall echo the QPD Segment value that was sent in the
QBP^Q22 message.
3.21.4.2.2.5 3.21.4.2.2.5 PID Segment
The Patient Demographics Supplier Actor shall return one PID segment group (i.e., one PID
segment plus any segments associated with it in the message syntax shown in Table 3.21-5) for__________________________________________________________________________
194
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3645

each matching patient record found. The Supplier shall return the attributes within the PID
segment as specified in Table 3.21-8. In addition, the Patient Demographics Supplier Actor shallreturn all other attributes within the PID segment for which it is able to supply values.
Table 3.21-8. PDQ Profile - PID segment
SEQ LENDT

OPT TBL# ITEM#ELEMENT NAME

3250 CX

R

00106 Patient Identifier List

5

250 XPN

R

00108 Patient Name

7

26 TS

R2

00110 Date/Time of Birth

1 IS

R2

8

0001

00111 Administrative Sex

11

250 XAD R200114 Patient Address

18

250 CX

00121 Patient Account Number

R2

Adapted from the HL7 standard, version 2.5
3650

3655

The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. Inability to supply an identifier in a particular domain is not anerror, provided that the domain is recognized.
The PID segment and its associated PD1 and QRI segments are returned only when the Patient
Demographics Supplier Actor is able to associate the search information in QPD-3 with one ormore patient records in the patient information source associated with MSH-5-Receiving
Application. See the “Patient Demographics Supplier Actor Query Response Behavior” section(ITI TF-2: 3.21.4.2.2.8) for a detailed description of how the Patient Demographics Supplier
Actor responds to the query request under various circumstances.
3.21.4.2.2.6 3.21.4.2.2.6 QRI Segment

3660

For each patient for which the Patient Demographics Supplier Actor returns a PID Segment, it
may optionally return the QRI (Query Response Instance) segment, but is not required to do so.
Refer to the HL7 Standard, Version 2.5, Chapter 5, Section 5.5.5, for more information.
3.21.4.2.2.7 3.21.4.2.2.7 DSC Segment

3665

3670

If a number of records is specified in RCP-2-Quantity Limited Request, the Patient
Demographics Supplier Actor shall return an incremental response of that number of records
when the number of matching records it finds exceeds the number of records specified in RCP-2.
As long as the Patient Demographics Supplier Actor has records to return in addition to those
returned in the incremental response, the Supplier shall return a DSC Segment. The single fieldof the DSC Segment shall contain a unique alphanumeric value (the Continuation Pointer) that
the Patient Demographics Consumer may return in the MSH segment of its acknowledgement of
the RSP^K22 message to request the next increment of responses. The Supplier shall return__________________________________________________________________________
195
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
increments as many times as the Consumer requests them (and there are increments to return),
and shall stop when the Consumer returns an acknowledgement that does not request additional
increments (or when there are no more increments to return).
3675

3680

3.21.4.2.2.8 3.21.4.2.2.8 Patient Demographics Supplier Actor Query Response
Behavior
The Patient Demographics Supplier shall perform the matching of patient data based on thequery parameter values it receives. The information provided by the Patient Demographics
Supplier Actor to Patient Demographics Consumer Actors is a list of possible matching patientsfrom the patient information source associated with the value that the Consumer sent in MSH-5Receiving Application of the query message.
If domains are specified in QPD-8-What Domains Returned and are recognized by the Patient
Demographics Supplier, the response will also, for each patient, contain any Patient ID values
found in the specified domains.

3685

The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier Actor and are outside of the scope of this framework.
The Patient Demographics Supplier Actor shall respond to the query request as described by thefollowing 3 cases:

3690

Case 1: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. No patient identifier domains are requested in QPD-8What Domains Returned.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

3695

3700

3705

One PID segment group (i.e., one PID segment plus any segments associated with it in themessage syntax shown in Table 3.21-5) is returned from the patient information source for eachpatient record found. If the Patient Demographics Supplier Actor returns data for multiple
patients, it shall return these data in successive occurrences of the PID segment group.
Within each PID segment, field PID-3-Patient Identifier List contains one or more identifiers
from the Patient ID Domain associated with the patient data source identified by MSH-5Receiving Facility.
If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.

__________________________________________________________________________
196
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3710

Case 2: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. One or more patient identifier domains are requested in
QPD-8-What Domains Returned; the Supplier recognizes all the requested domains.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

3715

3720

3725

One PID segment group (i.e., one PID segment plus any segments associated with it in themessage syntax shown in Table 3.21-5) is returned for each matching patient record found. If
the Patient Demographics Supplier Actor returns data for multiple patients, it shall return thesedata in successive occurrences of the PID segment group.
Within each PID segment, field PID-3-Patient Identifier List contains, in successive occurrencesdelimited by the repetition separator, the identifiers from all the Patient ID Domains requested in
QPD-8. In each occurrence of PID-3, component 4 contains the assigning authority value for
one Patient ID Domain, and component 1 contains the Patient ID value in that domain (or is left
blank if an identifier does not exist in that domain).
If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.
Case 3: The Patient Demographics Supplier Actor does not recognize one or more of thedomains in QPD-8-What Domains Returned.
AE (application error) is returned in MSA-1 and in QAK-2.

3730

3735

For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

8

4

Field Repetition(see below)

5Component Number(empty)6

Subcomponent Number(empty)ERR-2.4-Field Repetition identifies the ordinal occurrence of QPD-8 that contained theunrecognized domain. As specified by HL7, ERR-2.5-Component Number and ERR-2.6Subcomponent Number are not valued because we are referring to the entire field QPD-8.
__________________________________________________________________________
197
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Demographics Supplier Actor
did not recognize the domain for QPD-8-What Domains Returned.
3.21.4.2.3
3740

Expected Actions

The Patient Demographics Consumer will use the demographic information provided by thePatient Demographics Supplier to perform the functions for which it requested the information,e.g., providing a pick list to the user.
The Consumer will return an original mode acknowledgement as described in the HL7 Standard,
populating field MSH-14-Continuation Pointer as follows.

3745

If the Supplier returned a value in DSC-1-Continuation Pointer, indicating that there are more
matching patients remaining to be sent than could be sent in a single increment, and if theConsumer wishes to receive the next increment, the Consumer shall populate MSH-14 with thevalue it received in DSC-1. The Supplier will then send the next increment of matching records,
and will again populate DSC-1 (with a new unique value) if there are yet more records to be sent.

3750

If the Supplier did not return a value in DSC-1-Continuation Pointer, or if the Supplier did return
a value in DSC-1 but the Consumer does not wish to receive the next increment, the Consumer
shall return an empty value in MSH-14.

__________________________________________________________________________
198
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3755

3.22 Patient Demographics and Visit Query
This section corresponds to Transaction ITI-22 of the IHE Technical Framework. Transaction
ITI-22 is used by the Patient Demographics Consumer and Patient Demographics Supplier actors.
3.22.1 Scope

3760

This transaction involves a request by the Patient Demographics Consumer Actor for information
about patients whose demographic and visit data match data provided in the query message. The
request is received by the Patient Demographics Supplier actor. The Patient Demographics
Supplier actor immediately processes the request and returns a response in the form of
demographic and visit information for matching patients.
3.22.2 Use Case Roles
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient
Demographics andVisit Query

3765
Actor: Patient Demographics Consumer
Role: Requests a list of patients matching a minimal set of demographic (e.g., ID or partialname) and visit criteria from the Patient Demographics Supplier. Populates its attributes withdemographic and visit information received from the Patient Demographics Supplier.
3770

Actor: Patient Demographics SupplierRole: Returns demographic and visit information for all patients matching the demographic andvisit criteria provided by the Patient Demographics Consumer.

3.22.3 Referenced Standards
3775

HL7:

Version 2.5, Chapter 2 – Control

Version 2.5, Chapter 3 – Patient Administration
Version 2.5, Chapter 5 – Query__________________________________________________________________________
199
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.22.4 Interaction Diagram

Patient
Demographics
Consumer

Patient
Demographics
Supplier
Patient Demographics andVisit Query: QBP^ZV1

Patient Demographics andVisit Response: RSP^ZV2

3780
3.22.4.1 Patient Demographics and Visit Query
3.22.4.1.1

3785

Trigger Events

A Patient Demographics Consumer’s need to select a patient based on demographic and visit
information about patients whose information matches a minimal set of known data will trigger
the Patient Demographics and Visit Query based on the following HL7 trigger event:ZV1 – Find Candidates from Visit Information
3.22.4.1.2

3790

Message Semantics

The Patient Demographics and Visit Query transaction is conducted by the HL7 QBP^ZV1
message. The Patient Demographics Consumer actor shall generate the query message wheneverit needs to select from a list of patients whose information matches a minimal set of demographic
and visit data. The segments of the message listed below are required, and their detailed
descriptions are provided in the following subsections.
Table 3.22-1. QBP Query by Parameter

3795

QBP

Query by Parameter

Chapter in HL7 2.5

MSH

Message Header

2

QPD

Query Parameter Definition

5

RCP

Response Control Parameter5

The receiver shall respond to the query by sending the RSP^ZV2 message. This satisfies therequirements of original mode acknowledgment; no intermediate ACK message is to be sent.

__________________________________________________________________________
200
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.22.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2:
C.1.2).
3800

3805

3810

The Patient Demographics and Visit Query is always targeted at a single source of patient
demographic information (referred to in this Transaction as the patient information source).
When more than one patient information source is available, Field MSH-5-Receiving Application
specifies the patient information source that this query is targeting. The Patient Demographics
Supplier shall return this value in MSH-3-Sending Application of the ACK message and of the
RSP^ZV2 response. Note that, in a multi-domain environment, the patient information source
identified by MSH-5 may or may not be associated with any of the Patient ID Domains listed in
QPD-8-What Domains Returned.
A list shall be published of all Receiving Applications that the Patient Demographics Suppliersupports, for the Patient Demographics Consumer to choose from. Each query is processedagainst patient demographic information associated with one and only one Patient ID Domain.
Field MSH-9-Message Type shall have at least two components. The first component shall havea value of QBP; the second component shall have a value of ZV1. The third component is
optional; however, if present, it shall have a value of QBP_Q21.
3.22.4.1.2.2 QPD Segment

3815

The Patient Demographics Consumer Actor shall send attributes within the QPD segment as
described in Table 3.22-2.
Table 3.22-2. PDQ Profile - QPD segment
SEQ LEN DT OPT TBL# ITEM#
1

250

CE

R

2

32

ST

R+

0471

ELEMENT NAME

01375

Message Query Name

00696

Query Tag

3

QIP R

Demographics and Visit Fields

8

CX

What Domains ReturnedO

Adapted from the HL7 standard, version 2.5
3.22.4.1.2.2.1
3820

Parameters in QPD-3-Demographics and Visit-Related Fields

Field QPD-3-Demographics and Visit-Related Fields consists of one or more repetitions, each ofwhich contains two components that together contain the name and value of a distinct parameterto the query. Acceptable segments are PID, PD1, PV1, and PV2.
The first component of each parameter contains the name of an HL7 element in the form@<seg>.<field no>.<component no>.<subcomponent no>__________________________________________________________________________
201
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3825

The above format is populated according to common HL7 usage for specifying elements used inquery parameters, as follows:<seg> represents a 3-character segment ID from the HL7 Standard.
<field no> is the number of a field within the segment as shown in the SEQ column of thesegment attribute table for the segment selected.

3830

3835

3840

<component no>, for fields whose data types contain multiple components, shall contain the
cardinal number of the component being valued. For fields whose data types do not containmultiple components, <component no> should not be valued and its preceding period should notappear.
<subcomponent no>, for components whose data types contain multiple subcomponents, shallcontain the cardinal number of the subcomponent being valued. For components whose datatypes do not contain multiple subcomponents, <subcomponent no> should not be valued and its
preceding period should not appear.
The second subcomponent of each parameter contains the value that is to be matched. If it isdesired to constrain the quality of a match within the bounds of an algorithm known to the
Supplier, the algorithm and constraint values may be specified in Fields QPD-4 through QPD-7.
At a minimum, the Patient Demographics Consumer may specify, and the Patient Demographics
Supplier must support, the fields in the following table. Support for other fields is optional.
Table 3.22-3. PDQ Profile – QPD-3 fields required to be supported
FLD

ELEMENT NAME

PID.3

Patient Identifier List

PID.5

Patient Name

PID.7

Date/Time of Birth

PID.8

Administrative Sex

PID.11 Patient Address
PID.18 Patient Account Number

3845

In addition, it is recommended that the Patient Demographics Supplier support the fields in thefollowing table. Some fields may not be relevant to particular care settings (e.g., inpatient, daypatient) and will thus not be supportable by domains in those care settings.
Table 3-22.4. PDQ Profile – QPD-3 fields recommended to be supported
FLD

ELEMENT NAME

PV1.2

Patient Class

PV1.3

Assigned Patient Location

PV1.7

Attending Doctor

PV1.8

Referring Doctor__________________________________________________________________________
202
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
PV1.9

Consulting Doctor

PV1.10 Hospital Service
PV1.17 Admitting Doctor
PV1.19 Visit Number

3850

Examples of parameter expressions in QPD-3:@PID.5.1^SMITH~@PID.8^F

requests all patients whose family name (first component of PID-5-Patient Name) matches thevalue SMITH and whose sex (PID-8-Sex) matches the value ‘female’.
3855@PV1.3.2^389~@PV1.3.3^2

requests all patients whose room number (second component of PV1-3-Assigned Patient
Location) matches the value 389 and whose bed number (third component of PV1-3-Assigned
Patient Location) matches the value 2.
3860

3.22.4.1.2.2.2

Populating QPD-8-What Domains Returned

As in the Patient Demographics Query (Transaction ITI-21), field QPD-8 restricts the set of
domains for which identifiers are returned in PID-3:

3865

3870

In a multiple-domain environment, QPD-8 may be used to identify one or more domains ofinterest to the Patient Demographics Consumer and from which the Consumer wishes to obtain avalue for PID-3-Patient Identifier. Note that the patient information source designated by MSH5 may or may not be associated with any of the Patient ID Domains listed in QPD-8-What
Domains Returned.
In a single-domain environment, QPD-8 may be ignored by the Patient Demographics Supplier.
The Supplier shall always return both identifiers from the Patient ID Domain associated with thepatient information source designated by MSH-5-Receiving Application.
Within field QPD-8, only component 4 (Assigning Authority) shall be valued.

3875

The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. A discussion of how QPD-8 is processed is included in thearchitectural discussion in the “Using Patient Data Query (PDQ) in a Multi-Domain
Environment” section (ITI TF-2: Appendix M).
3.22.4.1.2.3 RCP Segment
The Patient Demographics Consumer Actor shall send attributes within the RCP segment as
described in Table 3.22-5. Fields not listed are optional.
__________________________________________________________________________
203
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Table 3.22-5. IHE Profile - RCP segment
SEQ LEN DT OPT TBL# ITEM#

3880

ELEMENT NAME

1

1

ID

R

0091

00027

Query Priority

2

10

CQ O

0126

00031

Quantity Limited Request

Adapted from the HL7 standard, version 2.5
3.22.4.1.2.3.1

Populating RCP-1-Query Priority

Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is tobe returned in Immediate mode.
3.22.4.1.2.3.2

Populating RCP-2-Quantity Limited Request

3885

The Patient Demographics Consumer Actor may request that responses to the query be sent,
using the HL7 Continuation Protocol, in increments of a specified number of patient records. (Inthe context of the HL7 query, a patient record is defined as the PID segment and any segments
accompanying it for each patient.) It is desirable to request an incremental response if the query
could result in hundreds or thousands of matches or “hits.”

3890

The Patient Demographics Supplier Actor shall support the HL7 Continuation Protocol.
Field RCP-2 is of data type CQ, which contains two components. The first component contains
the number of increments, while the second component contains the kind of increment, always
RD to signify that incremental replies are specified in terms of records.
For example, 50^RD requests 50 records at a time.

3895

See the “Incremental Response Processing” section (ITI TF-2: 3.22.4.1.3.3) and the “Expected
Actions” section of the Patient Demographics Query Response message (ITI TF-2: 3.22.4.2.3)
for more information on the implementation of the continuation protocol.
3.22.4.1.3

Expected Actions

3.22.4.1.3.1 Immediate Acknowledgement
3900

3905

The Patient Demographics Supplier shall immediately return an RSP^ZV2 response message as
specified below in Section 3.22.4.2, “Patient Demographics Response.” The RSP^ZV2 response
message incorporates original mode application acknowledgment as specified in the“Acknowledgment Modes” section (ITI TF-2: C.1.3). The Supplier shall use Field MSH-3Sending Application of the RSP^ZV2 message to return the value it received from the Patient
Demographics Consumer in Field MSH-5-Receiving Application of the QBP^ZV1 message.

__________________________________________________________________________
204
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.22.4.1.3.2 Query Parameter Processing
The Patient Demographics Supplier Actor shall be capable of accepting, searching on, andresponding with attributes in the QPD segment as specified in Table 3.22-2.
3910

3915

The Patient Demographics Supplier Actor must be capable of receiving all valid combinations of
subcomponents that make up the Assigning Authority component (i.e., all valid combinations of
QPD-3.8).
Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented
characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplierrather than by the Patient Demographics Consumer. The Supplier shall return at least all exact
matches to the query parameters sent by the Consumer; IHE does not further specify matchingrequirements.
3.22.4.1.3.3 Incremental Response Processing

3920

The Patient Demographics Supplier Actor shall be capable of accepting and processing attributes
in the RCP segment as listed in Table 3.22-5. In particular, the Patient Demographics Supplier
Actor shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I).
Also, the Patient Demographics Supplier Actor shall be able to interpret RCP-2-Quantity Limited
Request to return successive responses of partial lists of records according to the HL7Continuation Protocol, as described in Section 3.22.4.2 below and in the HL7 Standard.
3.22.4.2 Patient Demographics and Visit Response

3925

3.22.4.2.1

Trigger Events

The Patient Demographics Supplier’s response to the Find Candidates with Visit Information
message shall be the following message:
ZV2 – Find Candidates with Visit Information response
3.22.4.2.2
3930

3935

Message Semantics

The Patient Demographics and Visit Response transaction is conducted by the RSP^ZV2
message. The Patient Demographics Supplier Actor shall generate this message in direct
response to the QBP^ZV1 message previously received. This message satisfies the Application
Level, Original Mode Acknowledgement for the HL7 QBP^ZV1 message.
The segments of the message listed without enclosing square brackets in Table 3.22-6 arerequired. Detailed descriptions of all segments listed in the table below are provided in thefollowing subsections. Other segments of the message are optional.

__________________________________________________________________________
205
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Table 3.22-6 RSP Segment Pattern Response
RSP

3940

Segment Pattern Response

Chapter in HL7 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2[ {ERR} ]

Error

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5[ { PID

Patient Identification

3[ PD1 ]

Additional Patient Demographics

3

PV1

Patient Visit

3[ PV2 ]

Patient Visit – Additional Information

3[ QRI ] } ]Query Response Instance5[ DSC ]

Continuation Pointer2

3.22.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2:
C.1.2).

3945

Field MSH-3-Sending Application specifies the patient information source that processed thequery. The Patient Demographics Supplier shall use Field MSH-3-Sending Application of the
RSP^ZV2 message to return the value it received from the Patient Demographics Consumer in
Field MSH-5-Receiving Application of the QBP^Q22 message.
Field MSH-9-Message Type shall have at least two components. The first component shall havea value of RSP; the second component shall have a value of ZV2. The third component is
optional; however, if present, it shall have a value of RSP_ZV2.

3950

3.22.4.2.2.2 MSA Segment
The Patient Demographics Supplier Actor is not required to send any attributes within the MSA
segment beyond what is specified in the HL7 standard. See the “Acknowledgment Modes”
section (ITI TF-2: C.1.3) for the list of all required and optional fields within the MSA segment.
3.22.4.2.2.3 QAK Segment

3955

The Patient Demographics Supplier Actor shall send attributes within the QAK segment as
defined in table 3.22-7. For the details on filling in QAK-2 (Query Response Status) refer to the“Patient Demographics Supplier Actor Query Response Behavior” section (ITI TF-2:
3.22.4.2.2.11).

__________________________________________________________________________
206
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3960

Table 3.22-7. IHE Profile - QAK segment
SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1

32 ST

R

2

2 ID

R+

0208

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5
3.22.4.2.2.4 QPD Segment
The Patient Demographics Supplier Actor shall echo the QPD Segment value that was sent in the
QBP^ZV1 message.
3965

3.22.4.2.2.5 PID Segment

3970

The Patient Demographics Supplier Actor shall return one PID segment group (i.e., one PID
segment plus any segments associated with it in the message syntax shown in Table 3.22-6) for
each matching patient record found. The Supplier shall return the attributes within the PID
segment as specified in Table 3.22-8. In addition, the Patient Demographics Supplier Actor shallreturn all other attributes within the PID segment for which it is able to supply values.
Table 3.22-8. PDQ Profile - PID segment
SEQ LENDT

OPT TBL# ITEM#ELEMENT NAME

3250 CX

R

00106 Patient Identifier List

5

250 XPN

R

00108 Patient Name

7

26 TS

R2

8

1 IS

R2

00110 Date/Time of Birth0001

00111 Administrative Sex

11

250 XAD R200114 Patient Address

18

250 CX

00121 Patient Account Number

R2

Adapted from the HL7 standard, version 2.5

3975

3980

The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. Inability to supply an identifier in a particular domain is not anerror, provided that the domain is recognized.
The PID segment and the PD1, PV1, PV2, and QRI segments that are associated with it are
returned only when the Patient Demographics Supplier Actor is able to associate the search
information in QPD-3 with one or more patient records in the patient information source
associated with MSH-5-Receiving Application. See the “Patient Demographics Supplier Actor
Query Response Behavior” section (ITI TF-2: 3.22.4.2.2.11) for a detailed description of how thePatient Demographics Supplier Actor responds to the query request under various circumstances.

__________________________________________________________________________
207
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.22.4.2.2.6 PD1 Segment3985

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the PD1 (Patient Additional Demographics) segment, but is not required to
do so.
3.22.4.2.2.7 PV1 Segment

3990

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
shall also return a PV1 Segment in which attributes are populated as specified in Table 3.22-9.
In addition, the Patient Demographics Supplier Actor shall return all other attributes within thePV1 segment for which it is able to supply values.
Table 3.22-9. PDQ Profile – PV1 segment
SEQ LENDT

OPT TBL# ITEM#
0004

ELEMENT NAME

2

1 IS

R

3

80 PL

R2

00132 Patient Class7250 XCN R20010

00137 Attending Doctor

8

250 XCN R20010

00138 Referring Doctor

9250 XCN R200133 Assigned Patient Location

0010

00139 Consulting Doctor

R2

0069

00140 Hospital Service

17

250 XCN R20010

00147 Admitting Doctor

19

250 CX

10

3 IS

R2

00149 Visit Number

Adapted from the HL7 standard, version 2.5
3.22.4.2.2.8 PV2 Segment3995

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the PV2 (Patient Visit – Additional Information) segment, but is not
required to do so.
3.22.4.2.2.9 QRI Segment

4000

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the QRI (Query Response Instance) segment, but is not required to do so.
Refer to the HL7 Standard, Version 2.5, Chapter 5, Section 5.5.5, for more information.
3.22.4.2.2.10 DSC Segment
If a number of records is specified in RCP-2-Quantity Limited Request, the Patient
Demographics Supplier Actor shall return an incremental response of that number of records
when the number of matching records it finds exceeds the number of records specified in RCP-2.

__________________________________________________________________________
208
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4005

4010

As long as the Patient Demographics Supplier Actor has records to return in additional to those
returned in the incremental response, the Supplier shall return a DSC Segment. The single fieldof the DSC Segment shall contain a unique alphanumeric value (the Continuation Pointer) that
the Patient Demographics Consumer may return in the MSH segment of its acknowledgement of
the RSP^ZV2 message to request the next increment of responses. The Supplier shall return
increments as many times as the Consumer requests them (and there are increments to return),
and shall stop when the Consumer returns an acknowledgement that does not request additional
increments (or when there are no more increments to return).
3.22.4.2.2.11 Patient Demographics Supplier Actor Query Response Behavior

4015

4020

The Patient Demographics Supplier shall perform the matching of patient data based on thequery parameter values it receives. The information provided by the Patient Demographics
Supplier Actor to Patient Demographics Consumer Actors is a list of possible matching patientsfrom the patient information source associated with the value that the Consumer sent in MSH-5Receiving Application of the query message.
If domains are specified in QPD-8-What Domains Returned and are recognized by the Patient
Demographics Supplier, the response will also, for each patient, contain any Patient ID values
found in the specified domains.
The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier Actor and are outside of the scope of this framework.

4025

The Patient Demographics Supplier Actor shall respond to the query request as described by thefollowing 3 cases:
Case 1: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. No patient identifier domains are requested in QPD-8What Domains Returned.

4030

AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

4035

One PID-PV1 segment group (i.e., one PID segment and one PV1 segment, plus any segments
associated with them in the message syntax shown in Table 3.22-6) is returned from the patient
information source for each patient record found. If the Patient Demographics Supplier Actor
returns data for multiple patients, it shall return these data in successive occurrences of the PIDPV1 segment group.
Within each PID segment, field PID-3-Patient Identifier List contains one or more identifiers
from the Patient ID Domain associated with the patient data source identified by MSH-5Receiving Facility.

__________________________________________________________________________
209
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4040

4045

If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records found exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.
Case 2: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. One or more patient identifier domains are requested in
QPD-8-What Domains Returned; the Supplier recognizes all the requested domains.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

4050

4055

4060

4065

One PID-PV1 segment group (i.e., one PID and one PV1 segment plus any segments associatedwith them in the message syntax shown in Table 3.22-6) is returned for each matching patient
record found. If the Patient Demographics Supplier Actor returns data for multiple patients, it
shall return these data in successive occurrences of the PID segment group.
Within each PID segment, field PID-3-Patient Identifier List contains, in successive occurrencesdelimited by the repetition separator, the identifiers from all the Patient ID Domains requested in
QPD-8. In each occurrence of PID-3, component 4 contains the assigning authority value for
one Patient ID Domain, and component 1 contains the Patient ID value in that domain (or is left
blank if an identifier does not exist in that domain).
If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.
Case 3: The Patient Demographics Supplier Actor does not recognize one or more of thedomains in QPD-8-What Domains Returned.
AE (application error) is returned in MSA-1 and in QAK-2.
For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

8

4

Field Repetition(see below)

5Component Number(empty)__________________________________________________________________________
210
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4070

4075

COMP #COMPONENT NAME

VALUE

6

Subcomponent Number(empty)ERR-2.4-Field Repetition identifies the ordinal occurrence of QPD-8 that contained theunrecognized domain. As specified by HL7, ERR-2.5-Component Number and ERR-2.6Subcomponent Number are not valued because we are referring to the entire field QPD-8.
ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Demographics Supplier Actor
did not recognize the domain for QPD-8-What Domains Returned.
3.22.4.2.3

Expected Actions

The Patient Demographics Consumer will use the demographic information provided by thePatient Demographics Supplier to perform the functions for which it requested the information,e.g., providing a pick list to the user.
4080

4085

The Consumer will return an original mode acknowledgement as described in the HL7 Standard,
populating field MSH-14-Continuation Pointer as follows.
If the Supplier returned a value in DSC-1-Continuation Pointer, indicating that there are more
matching patients remaining to be sent than could be sent in a single increment, and if theConsumer wishes to receive the next increment, the Consumer shall populate MSH-14 with thevalue it received in DSC-1. The Supplier will then send the next increment of matching records,
and will again populate DSC-1 (with a new unique value) if there are yet more records to be sent.
If the Supplier did not return a value in DSC-1-Continuation Pointer, or if the Supplier did return
a value in DSC-1 but the Consumer does not wish to receive the next increment, the Consumer
shall return an empty value in MSH-14.

__________________________________________________________________________
211
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4090

3.23 Find Personnel White Pages
This section corresponds to Transaction ITI-23 of the IHE Technical Framework. Transaction
ITI-23 is used by the Personnel White Pages Consumer and the DNS Server Actors.
3.23.1 Scope
This Transaction is used to locate the Personnel White Pages directory.

4095

3.23.2 Use Case Roles
DNS Server

Personnel White
Pages Consumer

Find Personnel
White Pages

Actor: Personnel White Pages Consumer
Role: Requests Locating information for the Personnel White Pages Directory
Actor: DNS Server
4100

Role: Provides locating information about the Personnel White Pages Directory
3.23.3 Referenced Standard
IETF:

RFC-2181 Clarifications to the DNS Specification
RFC-2219 Use of DNS Aliases for Network Services
RFC-2782 A DNS RR for specifying the location of services (DNS SRV)

4105

DICOM:DICOM Supplement 67 – Configuration Management, January 14, 2004.

Note: Normative RFC’s are frequently updated by issuance of subsequent RFC’s. The originalolder RFC is not modified to include references to the newer RFC. This profile lists theapplicable RFC’s in effect at the time of publication. Subsequent updates and clarifications tothese RFC’s should also be applied.

__________________________________________________________________________
212
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4110

3.23.4 Interaction Diagram
DNS Server

Personnel White
Pages Consumer

Request all LDAP servers

List of servers, priority, ports, etc

Select server

3.23.4.1 Request all LDAP servers

4115

The RFC-2782 DNS RR is used for specifying the location of services (DNS SRV). It specifies amechanism for requesting the names and rudimentary descriptions for machines that provide
network services. The DNS client requests the descriptions for all machines that are registered asoffering a particular service name. In this case the service name requested will be “_ldap._tcp”.
The DNS server may respond with multiple names for a single request.
3.23.4.1.1

4120

This transaction is used by the Personnel White Pages Consumer prior to any access to the
Personnel White Pages Directory.
3.23.4.1.2

4125

Trigger Events

Message Semantics

The Personnel White Pages Consumer shall request a list of all the LDAP servers available. The
Personnel White Pages Consumer shall use the priority, capacity, and location information
provided by DNS as part of the server selection process. (RFC-2782 recommends the proper useof these parameters).
Note:__________________________________________________________________________
213
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4130

Multiple LDAP servers providing access to a common replicated LDAP database is a commonly
supported configuration. This permits LDAP servers to be located where appropriate for best
performance and fault tolerance. The DNS server response information provides guidance forselecting the most appropriate server.
There may also be multiple LDAP servers providing different databases. In this situation theclient may have to examine several servers to find the one that supports the Personnel White
Pages Directory (See ITI TF-2:3.24.4.1.2.2).

4135

The client may have a mechanism for manual default selection of the LDAP server to be used if
the DNS server does not provide an LDAP server location.
3.23.4.1.3

Expected Actions

The DNS Server shall return all known LDAP servers in accordance with RFC-2782.

__________________________________________________________________________
214
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.24 Query Personnel White Pages
4140

This section corresponds to Transaction ITI-24 of the IHE Technical Framework. Transaction
ITI-24 is used by the Personnel White Pages Consumer and the Personnel White Pages Directory
Actors.
3.24.1 Scope
This Transaction is used to retrieve information from the Personnel White Pages directory.

4145

The RFC-2251 “Lightweight Directory Access Protocol (v3)” specifies a mechanism for making
queries of a database corresponding to an LDAP schema. The LDAP client can compose
requests in the LDAP query language, and the LDAP server will respond with the results for asingle request.
3.24.2 Use Case Roles
Personnel White
Pages Consumer

Personnel White
Pages Directory

Query Personnel
White Pages

4150

Actor: Personnel White Pages Consumer
Role: Requests information about a human workforce member(s)Actor: Personnel White Pages Directory
Role: Provides information about one or more human workforce member
3.24.3 Referenced Standard

4155

IETF:

RFC-2181 Clarifications to the DNS Specification
RFC 1766 Tags for the Identification of Languages
RFC 2251 - Lightweight Directory Access Protocol (v3)
RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax
Definitions

4160

RFC 2253 - Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names
RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3__________________________________________________________________________
215
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
RFC 2798 - Definition of the inetOrgPerson LDAP Object Class
RFC 2829 Authentication Methods for LDAP
4165

4170

RFC 2830 LDAPv3: Extension for Transport Layer Security
ISO:

ISO/TS 17090 directory standard for healthcare identity management

CRU:

Projet de schémas d’annuaires et de schémas de registres de resources numériques
interopérables pour les administrations Document technique – v1, novembre 2002

ASTM:

E.123: Notation for national and international telephone numbers

HL7:

HL7 Version 2.5, Chapter 2 – Control

3.24.4 Interaction Diagram
Personnel White
Pages Consumer

Personnel White
Pages Directory

LDAP Query

LDAP Response

3.24.5 LDAP Query/Response
4175

The Personnel White Pages Consumer may make a wide variety of queries and cascaded queries
using LDAP. The Personnel White Pages Consumer and Personnel White Pages Directory shallsupport the data model described here.

4180

A commonly supported configuration type has multiple LDAP servers providing access to acommon replicated LDAP database. This permits LDAP servers to be located where appropriate
for best performance and fault tolerance. The replication rules chosen for the LDAP servers
affect the visible data consistency. LDAP permits inconsistent views of the database during
updates and replications. This inconsistency may result in a consumer receiving the person’s
previous demographics or contact information. This should not be a problem for our use-cases asnone of them are life critical.

__________________________________________________________________________
216
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
3.24.5.1 Trigger Events
4185

Personnel White Pages Consumer requires some Personnel White Pages information on one ormore human workforce members.
3.24.5.2 Message Semantics
The transaction uses standard LDAP v3 query/response mechanisms.
3.24.5.2.1

4190

4195

4200

4205

4210

Some of the attributes to be retrieved using this transaction may be considered sensitive to thehealthcare personnel. It is the responsibility of the Personnel White Pages Directory to enforce
these protections. To protect records and/or attributes, the Personnel White Pages Consumer may
be called upon to provide user credentials.
Anonymous authentication shall be implemented on Personnel White Pages Directory and is
optional for Personnel White Pages Consumer. Anonymous authentication shall be implemented
as described in LDAP v3 section 4.2 Bind Operation.
Simple Authentication shall be implemented on the Personnel White Pages Directory and is
optional for the Personnel White Pages Consumer. Simple authentication shall be implemented
as described in LDAP v3 section 4.2 Bind Operation. This authentication type is notrecommended for use over networks that are not otherwise secured as the username andpassword are transferred in the clear. The use of SSL-Simple Authentication is a better choice.
SSL-Simple Authentication shall be implemented on the Personnel White Pages Directory and is
optional for the Personnel White Pages Consumer. SSL-Simple Authentication is not defined inany normative text, but is consistently implemented and often referred to as “ldaps”. The PWP
Consumer shall connect to port 636 using SSL against the PWP Directory Certificate. The LDAP
v3 conversation then continues with Simple Authentication as defined in LDAP v3 section 4.2
Bind Operation.
PWP specifies read operations on personnel demographics. The use of bi-directional TLS
authentication, such as that defined in ATNA Profile, is not necessary as this profile does notprovide access to Protected Health Information (PHI). The use of SSL to cover the authenticationand query process is sufficient in this Profile.
3.24.5.2.2

4215

User Authentication

Base DN Discovery

The Personnel White Pages represents a branch within the “LDAP” directory. Branches in LDAP
are defined by a “Base DN”. The list of Base DNs that are provided by a LDAP directory can befound by doing a LDAP Query with a NULL (i.e. “”) Base DN, and ObjectClass=”DN”. The
Personnel White Pages Directory shall contain a person object with the cn=”IHE-ITI-PWP”. The
Personnel White Pages Consumer may thus search through the list of Base DNs that the LDAP
Directory contains for this cn object. The Personnel White Pages Directory identified in this way__________________________________________________________________________
217
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4220

shall contain person/inetOrgPerson objects that conform to the Query Personnel White Pages
Directory Transaction.
Note: The first LDAP server that yields a result on the search for IHE-ITI-PWP can be used.
There is no need to search further.
3.24.5.2.3

4225

4230

4235

Query Encoding

Note that the LDAP transactions utilize UTF-8 encoding unless otherwise noted. The schemashown here is the commonly used schema found in X.500 Schema for LDAP and inetOrgPerson.
Extensions beyond this schema are not recommended. The base schema must be preserved toensure interoperability. Schema extensions shall not introduce attributes that duplicate themeaning of any attribute specified in this Profile.
These attributes are multi-valued unless explicitly defined as single-valued. At this time there isno universally implemented method to distinguish the purpose for any of the instances in a multivalued attribute. The IHE recommends that the first entry contain the preferred value, and thatapplications use the first entry whenever a single value must be selected.
The following table shows the attributes found in Person (OrganizationalPerson and
ResidentialPerson) as defined in RFC 2256 and inetOrgPerson as defined in RFC 2798. The first
three columns contain the definitions from the standards for reference. Within the table thefourth column is the IHE recommendation for use with further discussion found in the fifth
column.
KEY for IHE REQ Column:

4240

R – The Personnel White Pages Directory shall contain valid values for these attributes. These
values are critical to Healthcare workflow.
R2– The Personnel White Pages Directory shall contain valid values for these attributes if thevalue is available. These attributes are sufficiently useful that the provider should utilize it in thedefined way. Personnel White Pages Consumers should expect that the information in these
attributes are valid, but shall be robust to empty values.

4245

O – The Personnel White Paged Directory may contain values for these optional attributes. The
IHE has identified sufficiently useful purpose or defined an interoperable way to use the value.
The IHE may profile these values in future profiles.
D – Although these attributes are defined in inetOrgPerson/Person, their use is discouraged. Thisis typically due to the attribute being obsolete, poorly implemented, or not available for query.

4250
Attribute Name

Source•••Definition
Standard defined Optionality
Description

IHE
REQ

IHE Comment__________________________________________________________________________
218
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•••
RFC 2256 •
•
•

IHE
REQ

Audio

RFC 2798

D

The audio format defined
is obsolete.

businessCategory

RFC 2798

D

Not well defined

CarLicense

RFC 2798

Cn

RFC 2256departmentNumber

RFC 2798

Description

RFC 2798

destinationIndicator

RFC 2256

Attribute NamealiasedObjectName

SourceDefinition
Standard defined Optionality
Description
Alias Object Name
Optional
The aliasedObjectName attribute isused by the directory service if theentry containing this attribute is analias.
•
Audio•
Optional•
Not well defined•Business Category•
Optional•
describes the kind of businessperformed by an organization•
Vehicle license or registration
plate•
Optional•
Used to record the values of thelicense or registration plate associatedwith an individual•(e.g. 6ABC246)•
Common Name•
Required•This is the X.500 commonName
attribute, which contains a name of an
object. If the user is a person, it istypically the person's full name.
•(e.g. Barbara Jensen)•
Department Number•
Optional•
Identifies a department within an
organization. This can be numeric oralphanumeric•(e.g. Radiology)•
Description•
Optional•This attribute contains a humanreadable description of the object.
•
Destination Indicator•
Optional•This attribute is used for the
telegram service

IHE Comment

O

O

R

See 3.24.4.1.2.3.1 Use oflanguage tag and HL7
Name Data Type (XPN)

O

D

D

Originally defined aspart of telegram
addressing.

__________________________________________________________________________
219
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________IHE
REQ

displayName•••
RFC 2798 ••••

employeeNumber

RFC 2798

O

employeeType

RFC 2798

facsimileTelephoneNumber

RFC 2256

GivenName

RFC 2798

homePhone

RFC 2798

Attribute Name

SourceDefinition
Standard defined Optionality
Description
Display Name
Optional
Singular
When displaying a person’s name,especially within a one-line summary
list, it is useful to be able to identify aname to be used. Since other attributetypes such as 'cn' are multivalued, an
additional attribute type is needed.
Display name is defined for thispurpose.
•(e.g. Babs Jensen)•
Employee Number•
Optional•
Singular•
Numeric or alphanumeric
identifier assigned to a person,
typically based on order of hire orassociation with an organization.
•(e.g. 42)•
Employee Type•
Optional•
Used to identify the employer to
employee relationship. Typicalvalues used will be "Contractor","Employee", "Intern", "Temp","External", and "Unknown" but any
value may be used.
•(e.g. External)•
FAX Number•
Optional•
A value of this attribute is atelephone number for a facsimile
terminal (and, optionally, its
parameters).
•(e.g. +1 408 555 1992)•
Name•
Optional•
The givenName attribute is used tohold the part of a person's name which
is not their surname nor middle name.
•(e.g. Barbara)•
Home Phone•
Optional•(e.g. +1 408 555 1862)

IHE Comment

R

O

R2

See 3.24.4.1.2.3.3 Phone
Numbers

R2

O__________________________________________________________________________
220
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•••
RFC 2798 •
•
•

IHE
REQ

Initials

RFC 2798

R2

internationaliSDNNumber

RFC 2798

jpegPhoto

RFC 2798

L

RFC 2256

labeledURI

RFC 2798

Mail

RFC 2798

manager

RFC 2798

Attribute Name

homePostalAddress

SourceDefinition
Standard defined Optionality
Description
Home Postal Address
OptionalThis attribute contains a homeaddress used by a Postal Service toperform services for the object.
•
Initials•
Optional•
The initials attribute contains theinitials of some or all of an individuals
names, but not the surname(s).
•(e.g. BJJ)•International ISDN Number•
Optional•
JPEG Photograph•Optional•
Used to store one or more imagesof a person using the JPEG File
Interchange Format•
Locality Name•
Optional•This is the X.500 localityName
attribute, which contains the name of a
locality, such as a city, county or othergeographic region.
•
URI•
Optional•(e.g. http://www.ihe.net IHE
Home)•
E-Mail Address•
Optional•
User’s e-mail address in RFC 822
compliant form•
(e.g. bjensen@siroe.com)•
Manager•
Optional•
Distinguished Name of theManager

IHE Comment

O

D
O

O

O

R2

O

In Healthcare themanager of an individual
is not clear. The manager
attribute does not include
enough information todetermine the type ofmanager indicated.

__________________________________________________________________________
221
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Attribute Name

Mobile•••RFC 2798 •••SourceO

RFC 2798

objectClass

RFC 2256ou

RFC 2256

pager

RFC 2798

photo

Definition
Standard defined Optionality
Description
Mobile/cellular phone number
Optional
A value of this attribute is atelephone number complying withITU Recommendation E.123.
•(e.g. +1 408 555 1941)•
Organization•
Optional•
Highest-level organization name,e.g., a company name, to which ou
attribute entries belong.
•(e.g. Saint-ihe-hospital.local)•
Object Class•
Required•
The values of the objectClass
attribute describe the kind of object
which an entry represents. The
objectClass attribute is present inevery entry, with at least two values.
One of the values is either "top" or"alias".
•(e.g. top, person,organizationalPerson, inetOrgPerson)•
Organizational Unit Name•
Optional•This is the X.500
organizationalUnitName attribute,which contains the name of anorganizational unit.
•(e.g. Radiologists)•
Pager phone number•
Optional•
A value of this attribute is atelephone number complying withITU Recommendation E.123.

RFC 2798 •
•
•

Photo
Optional
Photo attribute values are encodedin G3 fax format with an ASN.1
wrapper.

IHE
REQ

IHE Comment

R2This attribute should
contain only business use
mobile phone numbers.
See 3.24.4.1.2.3.3 Phone
Numbers

R2

R

R2

R2

D

This attribute should
contain only business use
mobile phone numbers.
See 3.24.4.1.2.3.3 Phone
Numbers
The format is too
cumbersome. See
jpegPhoto.

__________________________________________________________________________
222
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•••
RFC 2256 •
•
•

IHE
REQ

postalAddress

RFC 2256

R2

postalCode

RFC 2256

postOfficeBox

RFC 2256

preferredDeliveryMethod

RFC 2798

preferredLanguage

RFC 2798

Attribute Name

physicalDeliveryOfficeName

SourceDefinition
Standard defined Optionality
Description
Post Office Name
OptionalThis attribute contains the namethat a Postal Service uses to identify apost office.
•Postal Address•
Optional•This attribute contains an addressused by a Postal Service to perform
services for the object.
•
Postal Code•
Optional•This attribute contains a code usedby a Postal Service to identify a postal
service zone, such as a US ZIP code•
Post Office Box•
Optional•This attribute contains the numberthat a Postal Service uses when acustomer arranges to receive mail at a
box on premises of the Postal Service.
•
Delivery Method•
Optional•
Singular•
Coded value (delivery-value)•(e.g. any, physical, telephone)•
Preferred Language•
Optional•
Singular•Preferred written or spoken
language for a person. Values for this
attribute type MUST conform to thedefinition of the Accept-Language
header field defined in [RFC2068]
with one exception: the sequence"Accept-Language" ":" should beomitted.
•The following example indicatesthat this person prefers French, prefers
British English 80%, and general
English 70%. (e.g. fr, en-gb;q=0.8,
en;q=0.7)

IHE Comment

R2

R2

R2

O

R2

__________________________________________________________________________
223
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•••
RFC 2256 •
•
•

IHE
REQ

roomNumber

RFC 2798

O

secretary

RFC 2798

seeAlso

RFC 2798

sn

RFC 2256st

RFC 2256

street

RFC 2256

telephoneNumber

RFC 2256

teletexTerminalIdentifier

RFC 2798

telexNumber

RFC 2798

Attribute NameregisteredAddress

SourceDefinition
Standard defined Optionality
Description
Registered Address
Optional
A postal address suitable forreception of expedited documents,
where it is necessary to have therecipient accept delivery.
•
Room Number•
Optional•
Secretary•
Optional•
Distinguished name of thesecretary•
See Also references•
Optional•
Distinguished name of otherinteresting Objects•
Surname•Required•This is the X.500 surname
attribute, which contains the familyname of a person•(e.g. Jensen)•
State or Province•
Optional•This is the X.500
stateOrProvinceName attribute, whichcontains the full name of a state orprovince•
Street Address•
Optional•This is the X.500 streetAddress
attribute, which contains the physicaladdress of the object to which theentry corresponds, such as an addressfor package delivery.
•
Telephone number•
Optional•
A value of this attribute is atelephone number complying withITU Recommendation E.123.
•
Teletex Terminal Identifier•
Optional•
Telex Number•
Optional

IHE Comment

O

O

D

R

R2

R2

R2

See 3.24.4.1.2.3.3 Phone
Numbers

D
D__________________________________________________________________________
224
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________•••
RFC 2256 •
•
•

IHE
REQ

uid

RFC 2798

R

See 3.24.4.1.2.3.2 Use ofuid

userCertificate

RFC 2798

D

The PKCS12 format
includes the private key
and shall not be publicly
available.

userPassword

RFC 2256

D

Generally Not
Accessible

userPKCS12

RFC 2798

D

The PKCS12 format
includes the private key
and shall not be publicly
available.

Attribute Name

title

SourceDefinition
Standard defined Optionality
Description
Title
OptionalThis attribute contains the title,
such as "Vice President", of a personin their organizational context. The"personalTitle" attribute would be
used for a person's title independent of
their job function.
•(e.g. manager, productdevelopment)•
User ID•
Required•
The user ID use for system login.
•(e.g. bjensen)•
User Identity Certificate•
Optional•This attribute is to be stored andrequested in the binary form, as'userCertificate;binary'.
•
User password•
Optional•
Passwords are stored using an
Octet String syntax and are notencrypted. Transfer of cleartext
passwords are strongly discouraged
where the underlying transport service
cannot guarantee confidentiality andmay result in disclosure of thepassword to unauthorized parties.
•
User PKCS #12•
Optional•
PKCS #12 [PKCS12] provides aformat for exchange of personal
identity information. When suchinformation is stored in a directory
service, the userPKCS12 attributeshould be used. This attribute is to be
stored and requested in binary form, as'userPKCS12;binary'. The attributevalues are PFX PDUs stored as binarydata.

IHE Comment

R2__________________________________________________________________________
225
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Attribute Name•••
RFC 2798 •••SourceuserSMIMECertificate

x121Address
X500uniqueIdentifier

Definition
Standard defined Optionality
Description
User S/MIME Certificate
Optional
A PKCS#7 [RFC2315]
SignedData, where the content that issigned is ignored by consumers ofuserSMIMECertificate values. It is
recommended that values have a`contentType' of data with an absent`content' field. Values of this attributecontain a person's entire certificate
chain and an smimeCapabilities field[RFC2633] that at a minimum
describes their SMIME algorithm
capabilities. Values for this attributeare to be stored and requested inbinary form, as'userSMIMECertificate;binary'. Ifavailable, this attribute is preferredover the userCertificate attribute for
S/MIME applications.
RFC 2256 •Address for X.121•
Optional
RFC 2798 •Unique identifier•
Required•
The x500UniqueIdentifier attributeis used to distinguish between objects
when a distinguished name has beenreused. This is a different attributetype from both the "uid" and"uniqueIdentifier" types.

IHE
REQ

IHE Comment

O

D
R

3.24.5.2.3.1 Use of language tag and HL7 Name Data Type (XCN)
Many people have different variations of their name to be used depending on the context andlanguage. This is easily supported in LDAP through the use of the language tag as documented
in RFC 1766. This language tag can be applied to any attribute but is most useful on names.
4255

HL7 has a well-defined format for encoding names (HL7 XCN). LDAP ‘name’ attributes marked
with a language tag of “lang-x-ihe” shall be encoded using the HL7 XCN Data Type. UTF-8
shall be used for any characters outside ASCII.
Example use of the language tag:

4260

objectclass: Top
objectclass: person
objectclass: organizationalPerson__________________________________________________________________________
226
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4265

4270

4275

objectclass: inetOrgPerson
dn: cn=Wang XiaoDong, ou=Radiologists, o=Saint-ihe-hospital.local
cn: Wang XiaoDong
cn: XiaoDong, Wang, Florida Department of Health:123456789
cn;lang-cn: 王 小東
cn;lang-x-ihe: Wang^XiaoDong^^^^^^A~王^小東^^^^^^
sn: Wang
givenname: XiaoDong
givenname;lang-cn: 小東
sn;lang-cn: 王
ou: People
uid: XiaoDongtitle: Sample HL7 person
mail: Wang.XiaoDong@foo.bar.com
telephonenumber: 555-555-5678

3.24.5.2.3.2 Use of uid.
4280

4285

The uid attribute is a multi-valued attribute that is intended to be used for User ID. It is likelythat one of the values for uid will be the enterprise User ID. Enterprises that implement the PWP
Profile shall implement the following values for the uid attribute:
1. If an enterprise has implemented both IHE ITI EUA and PWP profiles, one of the uid
attributes shall contain the IHE ITI EUA user identity in <user>@<realm> format.
2. If an enterprise has implemented a UPIN, one of the uid attributes shall contain the UPIN
value in the format <UPIN>@UPIN. Where a UPIN is the Universal Physician
Identification Number as assigned by the assigning authority in which the facility
operates (e.g. CMS in the USA).
3.24.5.2.3.3 Phone Numbers

4290

Phone numbers shall be represented in the PWP Directory using E.123 notation. E.123 is anotation for national and international telephone numbers. Recommendation E.123 defines astandard way to write telephone numbers, e-mail addresses, and web addresses. It recommends
the following formats (when dialing the area code is optional for local calling):
Telephone number:
National notation

4295(042) 123 4567

International notation +31 42 123 4567
E.123 also recommends that a hypen (-), space ( ), or period (.) be used to visually separate
groups of numbers. The parentheses are used to indicate digits that are sometimes not dialed. A
slash (/) is used to indicate alternate numbers. This information is important if you want to makesure people know how to dial a phone number in a specific country.
__________________________________________________________________________
227
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4300

The use of National notation and International notation will be a local PWP Directory policy.
PWP Consumers shall expect to receive both notations.
3.24.5.2.4

Expected Actions

4305

The Personnel White Pages Directory shall provide the appropriate response to the indicatedquery given LDAP query rules, local access control policy, and the current information it thedirectory.

4310

Note: Any attribute is valid to query on, the results of the query may be quick or may take a longtime to complete. Each Personnel White Pages Directory will be optimized differently based onarchitecture and configuration. We expect that the following attributes will be query keys more
often than others (cn, displayname, objectclass, sn, uid, givenName, initials, mail, o, ou, andemployeeNumber).
Directory shall support Anonymous, Simple, and SSL-Simple Authentications.

__________________________________________________________________________
228
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix A:

4315

4320

Web Service Definition for Retrieve SpecificInformation for Display and Retrieve Document for
Display Transaction

The following is an example WSDL definition of web services used in Transactions ITI-11 andITI-12. This code is provided as an example and is not intended to replace the formal
specification of Transactions ITI-11 and ITI-12 in Volume 2. Also, the definitions ofsummaryRequestType, listRequestType and contentType shall correspond to the capabilities of
the Information Source Actor.
<?xml version="1.0" encoding="utf8"?>

4325

4330

4335

4340

4345

4350

4355

4360

4365

<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/"><!-- Defines the types available for the parameters --><!-- May also include the return type defintiions --><types><s:schema elementFormDefault="qualified"targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"><!-- Add any items that control the returned values list or type here --><!-- Add or remove items in the actual supplied WSDL to show the available types. --><s:simpleType name="summaryRequestType"><s:restriction base="s:string"><s:enumeration value="SUMMARY" /><s:enumeration value="SUMMARY-RADIOLOGY" /><s:enumeration value="SUMMARY-CARDIOLOGY" /><s:enumeration value="SUMMARY-LABORATORY" /><s:enumeration value="SUMMARY-SURGERY" /><s:enumeration value="SUMMARY-EMERGENCY" /><s:enumeration value="SUMMARY-DISCHARGE" /><s:enumeration value="SUMMARY-ICU" /></s:restriction></s:simpleType><s:simpleType name="listRequestType"><s:restriction base="s:string"><s:enumeration value="LIST-ALLERGIES" /><s:enumeration value="LIST-MEDS" /></s:restriction></s:simpleType><!-- Please list all content types available, and remove those not available. --><s:simpleType name="contentType"><s:restriction base="s:string"><s:enumeration value="text/html" /></s:restriction></s:simpleType><!-- Indicates that this item is a returned rows restriction --><s:simpleType name="ReturnedResultCount" type="s:positiveInteger" />__________________________________________________________________________
229
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4370

4375

4380

4385

4390

4395

4400

4405

4410

4415

4420

4425

4430

<!-- Please use the string "Search" as a prefix for all search criteria, and list below --><!-- Indicates that this item is a search string --><s:simpleType name="SearchString" type="s:string" /></s:schema></types><message name="RetrieveSummaryInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><part name="requestType" type="summaryRequestType" /><part name="patientID" type="SearchString" /><part name="lowerDateTime" type="s:dateTime" /><part name="upperDateTime" type="s:dateTime" /><part name="mostRecentResults" type="ReturnedResultCount" /></message><message name="RetrieveSummaryInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s0:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveListInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><part name="requestType" type="listRequestType" /><part name="patientID" type="SearchString" /></message><message name="RetrieveListInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s0:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveDocumentHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><!-- It is recommended that one of the sub-types of SearchUID is chosen here --><!-- Especially if SearchStudyUID is allowed, then the display client can know that --><!-- it is permissable to use a dicom uid here --><part name="documentUID" type="SearchString" /><part name="contentType" type="contentType" /></message><message name="RetrieveDocumentHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s:string" /></message><portType name="IHERetrieveForDisplayHttpGet"><operation name="RetrieveSummaryInfo"><input message="s0:RetrieveSummaryInfoHttpGetIn" /><output message="s0:RetrieveSummaryInfoHttpGetOut" /></operation><operation name="RetrieveListInfo"><input message="s0:RetrieveListInfoHttpGetIn" />__________________________________________________________________________
230
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4435

4440

4445

<output message="s0:RetrieveListInfoHttpGetOut" /></operation><operation name="RetrieveDocument"><input message="s0:RetrieveDocumentHttpGetIn" /><output message="s0:RetrieveDocumentHttpGetOut" /></operation></portType><binding name="IHERetrieveForDisplayHttpGet" type="s0:IHERetrieveForDisplayHttpGet"><http:binding verb="GET" /><operation name="RetrieveSummaryInfo"><http:operation location="/IHERetrieveSummaryInfo" /><input><http:urlEncoded /></input>

4450<output><mime:content type="text/html" /></output></operation>

4455<operation name="RetrieveListInfo"><http:operation location="/IHERetrieveListInfo" /><input><http:urlEncoded /></input>

4460

4465

4470

4475

4480

4485

4490

4495

<output><mime:content type="text/html" /></output></operation><operation name="RetrieveDocument"><http:operation location="/IHERetrieveDocument" /><input><http:urlEncoded /></input><!-- The type of the output should be restricted on a per-server basis to the types --><!-- actually provided. --><output><mime:content type="text/html" /><mime:content type="application/x-hl7-cda-level-one+xml" /><mime:content type="application/pdf" /><mime:content type="image/jpeg" /></output></operation></binding><!-- Bind the actual service here --><service name="IHERetrieveForDisplay"><port name="IHERetrieveForDisplayHttpGet" binding="s0:IHERetrieveForDisplayHttpGet"><http:address location="http://localhost/" /></port></service><?xml version="1.0" encoding="utf8"?><definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/">__________________________________________________________________________
231
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4500

4505

4510

4515

4520

4525

4530

<!-- Defines the types available for the parameters --><!-- May also include the return type defintiions --><types><s:schema elementFormDefault="qualified"targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"><!-- Add any items that control the returned values list or type here --><!-- Add or remove items in the actual supplied WSDL to show the available types. --><s:simpleType name="summaryRequestType"><s:restriction base="s:string"><s:enumeration value="SUMMARY" /><s:enumeration value="SUMMARY-RADIOLOGY" /><s:enumeration value="SUMMARY-CARDIOLOGY" /><s:enumeration value="SUMMARY-LABORATORY" /><s:enumeration value="SUMMARY-SURGERY" /><s:enumeration value="SUMMARY-EMERGENCY" /><s:enumeration value="SUMMARY-DISCHARGE" /><s:enumeration value="SUMMARY-ICU" /><s:enumeration value="SUMMARY-RX" /></s:restriction></s:simpleType><s:simpleType name="listRequestType"><s:restriction base="s:string"><s:enumeration value="LIST-ALLERGIES" /><s:enumeration value="LIST-MEDS" /></s:restriction></s:simpleType><!-- Please list all content types available, and remove those not available. --><s:simpleType name="contentType"><s:restriction base="s:string"><s:enumeration value="text/html" /></s:restriction></s:simpleType><!-- Indicates that this item is a returned rows restriction --><s:simpleType name="ReturnedResultCount" type="s:positiveInteger" />4535<!-- Please use the string "Search" as a prefix for all search criteria, and list below --><!-- Indicates that this item is a search string --><s:simpleType name="SearchString" type="s:string" />4540</s:schema></types>

4545

4550

4555

<message name="RetrieveSummaryInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><part name="requestType" type="summaryRequestType" /><part name="patientID" type="SearchString" /><part name="lowerDateTime" type="s:dateTime" /><part name="upperDateTime" type="s:dateTime" /><part name="mostRecentResults" type="ReturnedResultCount" /></message><message name="RetrieveSummaryInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s0:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message>__________________________________________________________________________
232
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4560

4565

4570

4575

4580

4585

4590

4595

4600

4605

4610

<message name="RetrieveListInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><part name="requestType" type="listRequestType" /><part name="patientID" type="SearchString" /></message><message name="RetrieveListInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s0:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveDocumentHttpGetIn"><!-- Add other parameters here if they are available, using types defined above. --><!-- It is recommended that one of the sub-types of SearchUID is chosen here --><!-- Especially if SearchStudyUID is allowed, then the display client can know that --><!-- it is permissable to use a dicom uid here --><part name="documentUID" type="SearchString" /><part name="contentType" type="contentType" /></message><message name="RetrieveDocumentHttpGetOut"><!-- If a complex type is defined for the return value, then it is suggested that --><!-- it be used here instead of s:string. If a complex type is allowed as one --><!-- of the options, but an arbitrarily formatted string is also allowed, then create --><!-- a union type here that allows either option. --><part name="Body" element="s:string" /></message><portType name="IHERetrieveForDisplayHttpGet"><operation name="RetrieveSummaryInfo"><input message="s0:RetrieveSummaryInfoHttpGetIn" /><output message="s0:RetrieveSummaryInfoHttpGetOut" /></operation><operation name="RetrieveListInfo"><input message="s0:RetrieveListInfoHttpGetIn" /><output message="s0:RetrieveListInfoHttpGetOut" /></operation><operation name="RetrieveDocument"><input message="s0:RetrieveDocumentHttpGetIn" /><output message="s0:RetrieveDocumentHttpGetOut" /></operation></portType><binding name="IHERetrieveForDisplayHttpGet" type="s0:IHERetrieveForDisplayHttpGet"><http:binding verb="GET" /><operation name="RetrieveSummaryInfo"><http:operation location="/IHERetrieveSummaryInfo" /><input><http:urlEncoded /></input>

4615<output><mime:content type="text/html" /></output></operation>

4620<operation name="RetrieveListInfo"><http:operation location="/IHERetrieveListInfo" /><input><http:urlEncoded />__________________________________________________________________________
233
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4625

4630

4635

4640

4645

4650

</input><output><mime:content type="text/html" /></output></operation><operation name="RetrieveDocument"><http:operation location="/IHERetrieveDocument" /><input><http:urlEncoded /></input><!-- The type of the output should be restricted on a per-server basis to the types --><!-- actually provided. --><output><mime:content type="text/html" /><mime:content type="application/x-hl7-cda-level-one+xml" /><mime:content type="application/pdf" /><mime:content type="image/jpeg" /></output></operation></binding><!-- Bind the actual service here --><service name="IHERetrieveForDisplay"><port name="IHERetrieveForDisplayHttpGet" binding="s0:IHERetrieveForDisplayHttpGet"><http:address location="http://localhost/" /></port></service>__________________________________________________________________________
234
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4655

4660

4665

Appendix B:

Definition of Document Unique IDs

The Retrieve Information for Display Integration Profile in its Retrieve Persistent Documenttransaction relies on a globally unique identification of persistent objects. It is the Information
Source Actor’s responsibility, when a specific document instance is available for retrieval, toassign to this document instance a globally unique identifier, thus allowing Display Actors toretrieve the same document instance at different points in time and to obtain the same semantics
for its presented content.
This appendix describes how unique identifiers for documents shall be created. A unique
identifier may be created by the Information Source Actor or by any other system to which theinformation source is connected. The requirements specified in this appendix are derived fromthe common practices and definitions of OIDs in ISO 8824, HL7 V3 and CDA and UIDs in
DICOM. They guarantee uniqueness across multiple countries, sites, vendors and equipment.

B.1:

Requirements for Document UIDs

The UID identification scheme is based on the OSI Object Identification (numeric form) as
defined by the ISO 8824 standard.
4670

All Unique Identifiers, used within the context of this transaction shall be registered values as
defined by ISO 9834-3 to ensure global uniqueness. These requirements result in the following
structure for unique Ids.

B.2:
4675

4680

4685

Structure of a Document UID

Each Document UID is composed of two parts, an <org root> and a <suffix> separated by a“period”. Therefore: UID = <org root>.<suffix>
The <org root> portion of the UID uniquely identifies an organization, (e.g., manufacturer,
research organization, hospital, etc.), and is composed of a number of numeric components as
defined by ISO 8824. The <suffix> portion of the UID is also composed of a number of numericcomponents, and shall be unique within the scope of the <org root>. This implies that theorganization identified in the <org root> is responsible for guaranteeing <suffix> uniqueness byproviding registration policies. These policies shall guarantee <suffix> uniqueness for all UID's
created by that organization. Unlike the <org root>, which may be common for UID's in an
organization, the <suffix> shall take different unique values between different UID's that identify
different objects. The <org root> is used only for uniqueness and not for any other purpose.
Although a specific implementation may choose some particular structure for its generated UIDs,
it should never assume that a UID carries any semantics. A UID shall not be "parsed" to find aparticular value or component. Component definition (for the suffix) is implementation-specificand may change as long as uniqueness is maintained. Parsing UID's (including extracting theroot) may jeopardize the ability to inter-operate as implementations evolve.
__________________________________________________________________________
235
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
4690

B.3:

Document UID encoding rules

The UID encoding rules are defined as follows:• Each component of a UID is a number and shall consist of one or more digits. The first
digit of each component shall not be zero unless the component is a single digit.
4695

Note: Registration authorities may distribute components with non-significant leading zeroes. The leading zeroes
should be ignored when being encoded (ie. “00029” would be encoded “29”).

•

4700

•
•

B.4:

4705

Each component numeric value shall be encoded using the characters 0-9 of the Basic G0
Set of the International Reference Version of ISO 646:1990. This particular encoding is
the same as the UTF-8 encoding for these characters in UNICODE.
Components shall be separated by the character "." (2EH).
UIDs shall not exceed 64 total characters, including the digits of each component, andseparators between components.

How to obtain a UID registration root?

Organizations that define UIDs are responsible for properly registering their UIDs (at leastobtain a registered <Org Root>) as defined for OSI Object Identifiers (ISO 9834-3). The
organization defining the UID shall accept the responsibility of ensuring its uniqueness. IHE will
not register UIDs or issue registered organization roots. There are a large number of means to
obtain free or for a reasonable fee an organization root.
A useful resource that is often used by the DICOM community lists the many ways to obtain aregistered UID Root for a small fee or even for free, anywhere in the world.

4710

http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration
The manner in which the suffix of a Document UID is defined is not constrained by any IHE
Integration Profile. Only the guarantee of its uniqueness by the defining organization is required
by IHE.

B.5:
4715

Example of a Document UID

This example presents a particular choice made by a specific organization in defining its suffix toguarantee uniqueness. A variant is discussed.
"1.2.840.xxxxx.4076078054086.11059664469.235212"(root)(suffix)

In this example, the root is:
4720

1

Identifies ISO

2

Identifies ANSI Member Body

840

Country code of a specific Member Body (U.S. for ANSI)__________________________________________________________________________
236
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
xxxxx Identifies a specific Organization.(provided by ANSI)
4725

4730

In this example the remaining components of the suffix relate to the identification of a specificdocument instance:
4076078054086

802.3 MAC Address (004 076 078 054 086)

11059664469

Time system was booted (July 31, 2033 10:14:29)

235212

Monotonically increasing sequence number

In this example, the organization has chosen these components to guarantee uniqueness. Other
organizations may choose an entirely different series of components to uniquely identify its
documents.
Because of the flexibility allowed in creating Document UIDs, implementations should notdepend on any assumed structure of UIDs and should not attempt to parse UIDs to extract thesemantics of some of its components.

4735__________________________________________________________________________
237
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix C:
4740

4745

4750

4755

4760

HL7 Profiling Conventions

The HL7 tables included in this document have been modified from the HL7 2.5 standard
document. Such a modification is called a profile. Refer to the HL7 2.5 standard for themeanings of specific columns in the table.
The profiling tables in this document leverage the ongoing HL7 profile definition. To maintainthis specification at a generic level, the following differences have been introduced:• Message specifications do not indicate the cardinality of segments within a message.
• For fields composed of multiple components, there is no indication of the size of eachcomponent.
• Where a table containing enumerated values is referenced from within a segment profile
table, the enumerated values table is not always present.
• The number of times a repeating field can repeat is not indicated.
• The conditions that would require inclusion of conditional fields are not defined when
they depend on functional characteristics of the system implementing the transaction andthey do not affect data consistency.
The following terms refer to the OPT column, which has been profiled:R
Required
R2
This is an IHE extension. If the sending application has data for the field, it isrequired to populate the field. If the value is not known, the field may not be sent.
R+
This is an IHE extension. This is a field that IHE requires that was listed as optional
within the HL7 standard.
O
Optional
C
Conditional
IHE requires that Z-segments be present in HL7 transactions only when defined by the IHE IT
Infrastructure Technical Framework.

4765

According to the HL7 standard, if the value of a field is not present, the receiver shall not change
corresponding data in its database. However, if sender includes explicit NULL value (i.e., twodouble-quotes “”), it shall cause removal of any values for that field in the receiver’s database.
Table C-1 provides a sample profile for an imaginary HL7 segment. Tables for real segments arecopied from the HL7 2.5 standard with modifications made only to the OPT column.
Table C-1 Sample HL7 Profile
SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

1

1

ST

R

xx001

Element 1

2

4

ST

O

xx002

Element 2__________________________________________________________________________
238
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4770

3

180

HD

R2

xx003

Element 3

4

180

HD

C

xx004

Element 4

5

180

HD

O

xx005

Element 5

6

180

HD

R+

xx006

Element 6

C.1:

HL7 Implementation Notes

Network Guidelines
The HL7 2.5 standard does not define a network communications protocol. Beginning with HL7
2.2 , the definitions of lower layer protocols were moved to the Implementation Guide, but are
not HL7 requirements. The IHE Framework makes these recommendations:4775

1. Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the
HL7 Implementation Guide.
5.

An application that wants to send a message (initiate a transaction) will initiate a
network connection to start the transaction. The receiver application will respond withan acknowledgement or response to query but will not initiate new transactions on thisnetwork connection.

4780

Message Control
According to the HL7 standard, each message shall begin with the MSH (message header)segment. Table C.1-1 identifies all required fields in this message. This table shall be interpreted
according to the HL7 Standard unless otherwise noted in Appendix C.
4785

Table C.1-1 IHE Profile - MSH segment
SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

1

1

ST

R

00001

Field Separator

2

4

ST

R

00002

Encoding Characters

3

180

HD

R+

00003

Sending Application

4

180

HD

R+

00004

Sending Facility

5

180

HD

R+

00005

Receiving Application

6

180

HD

R+

00006

Receiving Facility

7

26

TS

R

00007

Date/Time Of Message

8

40

ST

O

00008

Security

9

13

CM

R

00009

Message Type

10

20

ST

R

00010

Message Control ID

11

3

PT

R

00011

Processing ID

12

60

VID

R

00012

Version ID

13

15

NM

O

00013

Sequence Number

14

180

ST

O

00014

Continuation Pointer

0076/
0003

0104

__________________________________________________________________________
239
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
15

2

ID

O

0155

00015

Accept Acknowledgment Type

16

2

ID

O

0155

00016

Application Acknowledgment Type

17

3

ID

O

0399

00017

Country Code

18

16

ID

C

0211

00692

Character Set

19

250

CE

O

00693

Principal Language Of Message

20

20

ID

O

0356

01317

Alternate Character Set Handling Scheme

21

10

ID

O

0449

01598

Conformance Statement ID #Adapted from the HL7 Standard, version 2.5 and version 2.3.1# Note: This element is only applicable in HL7 version 2.5 and thus is only applicable for those transactions basedon HL7 v2.5

4790

The IHE IT Infrastructure Technical Framework requires that applications support HL7recommended values for the fields MSH-1-Field Separator and MSH-2-Encoding Characters.
Field MSH-18-Character Set shall only be valued if the message utilizes character sets other thanISO IR-6, also known as ASCII.
Implementations supporting sequence number protocol (and using the field MSH-13-Sequence
Number) shall be configurable to allow them to perform transactions without such protocol.

4795

Acknowledgment Modes
Applications that receive HL7 messages shall conform to the acknowledgment and response
requirements using the HL7 Original Mode (versus Enhanced Acknowledgment Mode).

4800

The IHE IT Infrastructure Technical Framework provides for each HL7 message to beacknowledged by the HL7 ACK or by the appropriate HL7 Query/Response message sent by thereceiver of an HL7 message to its sender. The segment requirements for responses to queries canbe found within the respective sections for the transactions. The segments of the ACK message
listed below are required, and their detailed descriptions are provided in tables C.1-2, C.1-3 andcorresponding notes. The ERR segment is optional and may be included if the MSA-1Acknowledgment Code field identifies an error condition.

4805
ACK

Acknowledgement
Message

Chapter in HL7
2.3.1 / 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2

[ERR]

Error Comments

2

Table C.1-2 IHE Profile - MSA segment
SEQ
1

LEN
2

DT
ID

OPT
R

TBL#

ITEM#

0008

00018

ELEMENT NAME
Acknowledgment Code__________________________________________________________________________
240
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
2

20

ST

R

00010

Message Control ID

3

80

ST

O

00020

Text Message

4

15

NM

O

00021

Expected Sequence Number

5

1

ID

O

0102

00022

Delayed Acknowledgment Type

6

250

CE

O

0357

00023

Error Condition

Adapted from the HL7 standard, version 2.5 and version 2.3.1
4810

Field MSA-2-Message Control ID shall contain the Message ID from the MSH-10-Message
Control ID of the incoming message for which this acknowledgement is sent.
Table C.1-3 IHE Profile - ERR segment
SEQ
1

LEN
80

DT
ID

OPT

TBL#

R

ITEM#
00024

ELEMENT NAME
Error code and location

Adapted from the HL7 standard, version 2.5 and version 2.3.1
Common Segment Definitions
4815

The following table specifies the contents of the EVN segment that is common to several HL7based transaction messages defined in this volume.
Table C.1-4 IHE Profile - EVN segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

0003

00099

Event Type Code

1

3

ID

O

2

26

TS

R

00100

Recorded Date/Time

3

26

TS

O

00101

Date/Time Planned Event

4

3

IS

O

0062

00102

Event Reason Code

5

60

XCN

O

0188

00103

Operator ID

6

26

TS

R2

01278

Event Occurred

7

180

HD

O

01534

Event Facility #Adapted from the HL7 Standard, version 2.5 and version 2.3.1# Note: This element is only applicable in HL7 version 2.5 and thus is only applicable for those transactions basedon HL7 v2.5

4820

Field EVN-1-Event Type Code is optional; however, if present, its value shall be equal to thesecond component of the field MSH-9-Message Type.

__________________________________________________________________________
241
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix D:

4825

4830

4835

4840

4845

Cross-Profile Interactions of PIX and PSA

When the Context Manager Actor in a Patient Synchronized Application Integration Profile isgrouped with a Patient Identifier Cross-reference Consumer in a Patient Identifier Crossreferencing Integration Profile, patient identifiers must be accessible to both actors in aconsistent manner. This Appendix provides the necessary mapping rules.
The Patient Identifier Cross-Referencing (PIX) Integration Profile defines a general-purpose
mapping of a Patient ID within a Patient Identification Domain to aliases in other Patient
Identification Domains. This mapping is intended to be used across all IHE systems that requirepatient identification in transactions crossing Patient Identification Domains. The PIX
Integration Profile relies on HL7 V2 Transactions.
The Patient Synchronized Application Integration Profile relies on HL7 CCOW which,confronted with a similar need, has defined a Patient Mapping API within its architecture. The
HTTP Technology mapping for the CCOW Patient Mapping Agent API supports its operation
over a network interface, thus creating an alternative to HL7 V2 messages.
As IHE strives to avoid the inclusion in its integration profiles of incompatible but functionallyequivalent variants, it has decided to use HL7 V2 ADT messages for the Patient Identifier Crossreferencing Integration Profiles. In consequence, the combined use of the Patient Synchronized(CCOW based) Integration Profile and of the Patient Identifier Cross-referencing Integration
profiles requires that the IHE Context Manager Actor uses the services of the PIX Integration
Profile. To do so, the Patient Identifier Cross-reference Consumer Actor in communication with
the Patient Identifier Cross-reference Manager Actor operates as a substitute for the CCOW
Patient Mapping Agent. This is shown in diagram D-1 below as a dashed oval surrounding thePatient Cross-reference Manager and the Patient Identifier Cross-reference Consumer actors. As
a result it is likely that a context management solution would bundle a PMA proxy applicationthat would implement the PIX Query in support of the Patient Identifier Cross-reference
Consumer Actor.

__________________________________________________________________________
242
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Patient Mapping
Product
Grouping

Patient
ID Consumer

PIX Query

Patient CrossRef Manager

Join Context

Context
ParticipantContext
Manager

Change Context
Follow Context
Leave Context

PMA APICCOW Context Mgr

4850
Figure D-1: Actor Grouping Diagram

This Appendix provides the definition of the mapping of the CCOW Patient Mapping Agent API
methods onto the PIX Query Transaction (HL7 V2 QBP^Q23/RSP^K23) as defined by the PIX
Integration Profile.
4855

4860

Table D-1 shows the definition of the Patient Mapping Methods parameters as implemented in
Web technology. Most of these Arguments relate to the normal operations of the Patient
Mapping Agent methods that pose no mapping challenge except for the ItemNames and
ItemValues which pose some constraints. The first constraint comes from the translation ofPatient Identity Domains for both query and response from and to a CCOW defined name / value
pair. The second one comes from the fact that CCOW participant applications can set more than
one identifier in context the ability to detect when these identifiers represent the identities ofmore than one patient. IHE has taken steps to mitigate these issues by further restricting how the
IHE Context Participant implements the methods. Each of these constraints is addressed in
sections below.

4865

Table D-1 ContextChangesPending
HTTP Request Message
Argument
Name

Data
Type

Comment

Interfacestring“ContextAgent”

Methodstring“ContextChangesPending”

agentCoupon

long

“-1”

contextManager

string

URL for the Context Manager that is requesting the patient id cross-reference

itemNames

string[]One or more item names (e.g. Patient.Id.IdList)

itemValues

string[]

The patient identifiers corresponding to the domains identified in item names

contextCoupon

longContext Coupon value for pending context change transaction__________________________________________________________________________
243
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________HTTP Request Message
ArgumentNamemanagerSignature

Data
Type
stringComment
Not required

HTTP Reply Message
agentCoupon

long

“-1”

itemNames

string[]See below for valid item names for patient subject

itemValues

string[]See below for any constraints on item values

contextCoupon

long

Return the value provided in request

agentSignaturestring

Not required

Decisionstring“valid” or “invalid”

ReasonstringReason text if mapping is invalid

Adapted from the HL7 Context Management “CCOW” Standard, version 1.4

D.1:

4870

Namespace Translation from PIX Query to CCOWThe CCOW standard defines multiple identifier items that may be set into the context by an
instigating participant application. The current list of valid identifier names are listed in Table D2.
Table D-2 Patient Subject Identifiers
Patient Subject
Identifier Item Name

HL7
Meaning

HL7
Data
Type

HL7 Semantic Constraints on
ValuesCase
Sensitive

Patient.Id.MRN.Suffix

Patient medical
record number,per PID-2

ST

HL7 Table 0203
Identifier Type = MR

No

Patient.Id.MPI

Patient
identifier in the“Master Patient
Index”, per
PID-2

ST

HL7 Table 0203
Identifier Type = PT or PI (as agreed
upon by context sharing systems) andAssigning Authority represents the MPI
systemNo

Patient.Id.NationalIdNumber

Patient national
identifier
number, per
PID-2

ST

HL7 Table 0203
Identifier Type = PT and Assigning
Authority represents agreed upon
National Authority

No

Patient.Id.IdList

A list of patient
identifiers for apatient, per
PID-3

CX

May be a repeating set of CX item
values (per Section 1.7 of the HL7
Context Management “CCOW”
Standard: Subject Data Definitions
document), each of which contains an
identifier that denotes the same patientNo

Adapted from the HL7 Context Management “CCOW” Standard, version 1.4__________________________________________________________________________
244
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4875

IHE has specified in the Context Change Transaction as documented in ITI TF-2 that the Context
Participant Actor shall use the Patient.Id.IdList item. The intent is to eliminate translation as thePatient.Id.IdList value maps directly to PIX Query Transaction QPD-3.
Applications using in their identifier items Patient.Id.MRN.Suffix will need to migrate to thePatient.Id.IdList item as expected by the HL7 CCOW standard.

D.2:
4880

4885

4890

4895

Processing Multiple Identifiers

CCOW participant applications are permitted to populate as many patient identifiers as they haveavailable to them. This means that when a user selects a patient in one of these applications thecontext is populated with multiple identifiers for the selected patient. When the CCOW Patient
Mapping Agent (PMA) accepts multiple patient identifiers as input, the PMA has the
responsibility of invalidating patient mapping and causing the context change transaction to becancelled if it determines that the multiple identifiers supplied as part of the transaction identify
more than one patient.
The QPD segment as defined in the IHE PIX Query Transaction specifies a single identifier
uniquely identifying one patient within a given Patient Identification Domain. In the case wheremultiple identifiers are populated, the context manager may have to process the response to theinitial PIX Query Transaction to evaluate if the other identifiers in context are included. If so, nofurther processing is required. Otherwise, an additional PIX Query will need to be issued and theresults processed. Should a non-null result be returned, indicating the identifier uniquely
identifies a different patient for the given domain, the context manager shall assume “invalid” inthe decision field and “multiple patients identified” in the reason field.
In order to mitigate this condition, IHE specifies that all context participants supporting thePatient Synchronized Applications profile shall only set one identifier for the patient when a
Patient Identifier Cross-referencing Integration Profile is used by the context manager. Thismeans that the context participant for those applications that manage multiple patient identifiers
will need to be configurable as to which identifier item is passed in the Change Context
Transaction.

__________________________________________________________________________
245
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

4900

Appendix E:

Usage of the CX Data Type in PID-3-Patient Identifier
List

4905

The Health Level Seven Standard (HL7) uses data type CX to express various identifiers,
including the Patient ID in the third field of the PID segment. We discuss here how IHE IT
Infrastructure expects the CX data type to be populated in the PID-3-Patient Identifier List fieldsof messages that it defines.

4910

Requirements for populating the elements of PID-3-Patient Identifier List vary slightly,
depending on what actor is originating the transaction in which the PID segment is sent. If thePatient Identifier Cross-reference Manager is the source of the PID segment, the requirements(specifically, with respect to populating the Assigning Authority subcomponents) are more
rigorous than otherwise.
PID-3-Patient Identifier List permits multiple occurrences of the CX data type. Data type CX
contains 8 components as shown below. This structure allows expression of the value andcontext for each identifier that the system knows.
Table E-1: Components of HL7 Data Type CX
Cmp

Len

DT

Opt

1

15

ST

R

2

ST

O

3

ID

O

HD

R

5

ID

O

6

HD

O

Assigning facility

7

DT

O

Effective date

8

DT

O

Expiration date

4

4915

4920

227

Tbl

Name
ID
Check digit

0061

Code identifying the check digit scheme employed
Assigning authority

0203

Identifier type code

Adapted from the HL7 Standard, Version 2.5
Each occurrence of PID-3-Patient Identifier List contains, at a minimum, an identifier value in
Component 1 and an assigning authority in Component 4. The assigning authority
unambiguously provides the context for the identifier. It is also common practice to provide an
identifier type code in Component 5, but this is not required by IHE. Other components are
optional and will not be discussed here; implementers may refer to HL7 Version 2.5 for more
information.

__________________________________________________________________________
246
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Component 1 of Data Type CX, ID, is of data type ST. This data type allows a free text value ofup to 15 characters.8
4925

Component 4 of Data Type CX, Assigning Authority, is of data type HD. This data typecontains 3 components that, when implemented at the component level, become subcomponentsof Component 4. The requirements for the subcomponents of Component 4 vary by actor.

E.1:

4930

Patient Identifier Cross-reference Manager actor requirements

The Patient Identifier Cross-reference Manager Actor is expected to have access to complete
internal and external identifier information for the Assigning Authority of the patient identifier.
To facilitate interoperability, it is required that the Patient Identifier Cross-reference Manager
Actor populate all subcomponents of the Assigning Authority component. The usage of these
subcomponents will be explained in the examples below.
This requirement applies to the response portion of Transaction ITI-9 (PIX Query) and toTransaction ITI-10 (PIX Update Notification).

4935

Table E-2: Usage of HL7 Data Type CX by the PIX Manager Actor
Cmp

Sbc

Len

DT

Opt

15

ST

R

2

ST

O

3

ID

O

227

HD

R

1

4

Tbl

Name
ID
Check digit

0061

Code identifying thecheck digit scheme
employed
Assigning authority

4

1

20

IS

R

4

2

199

ST

R

4

3

6

ID

R

0301

Universal ID type

5

ID

O

0203

Identifier type code

6

HD

O

6

1

IS

O

6

2

ST

C

6

3

ID

C

Conditionality predicate

0363

Subcomponent 1 must refer to thesame entity as Subcomponents 2 and3.

Namespace ID
Universal ID

Assigning facility

0300

0301

If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID
Universal ID

Populated if, and only if,
Subcomponent 3 is populated.

Universal ID type

Populated if, and only if,
Subcomponent 2 is populated

8

As implemented in HL7 Version 2.5. Prior to Version 2.5, HL7 did not specify the length of individualcomponents. Although the profiles in IHE-ITI are based Versions 2.3.1 and 2.4 of HL7, they use the component
length constraints provided by Version 2.5 to support forward compatibility.

__________________________________________________________________________
247
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Cmp

DT

Opt

7

Sbc

Len

DT

O

Tbl

Effective date

Name

8

DT

O

Expiration dateConditionality predicate

IHE specifies that the Patient Identifier Cross-reference Manager actor must populate all 3
subcomponents of Component 4. The following rules apply:

4940

4945

4950

Subcomponent 1 of Component 4, Namespace ID, is of data type IS. HL7 specifies that whenvalued in the Patient ID field, the value in this subcomponent be a code taken from user-defined
Table 0363, Assigning Authority. Version 2.5 of HL7 provides suggested values for assigningauthorities in various local jurisdictions, such as USSSA for U.S. Social Security Administration.
Sites may add values to this table, but for interoperability must ensure that added values (andmeanings) are agreed upon by all communicating systems.
Subcomponent 2 of Component 4, Universal ID, is of data type ST. This subcomponent
contains a value from either a known external domain or a specified internal domain. The
domain is given in Subcomponent 3.
Subcomponent 3, Universal ID Type, is of data type ID. This subcomponent contains a codetaken from HL7 Table 0301, Universal ID Type. Table 0301 contains values for various known
external identifier domains such as DNS (Internet dotted name) and ISO (International Standards
Organization Object Identifier, or OID), as well as the values L, M, and N to permit the use ofinternal identifier domains.
Subcomponent 1 must refer to the same entity as Subcomponents 2 and 3.

E.2:
4955

4960

Other actor requirements

The PID segment may also appear in messages generated by other IHE Actors, including thePatient ID Cross-reference Consumer and the Information Source. These actors must also
populate the Assigning Authority.
However, IHE specifies that they need not populate all three subcomponents of Assigning
Authority. They must populate either Namespace ID (an entry from a user-defined table), or
Universal ID and Universal ID Type (allowing the use of an externally defined identifier
scheme).
This requirement applies to Transaction 8 (Patient Identity Feed), to the query portion ofTransaction ITI-9 (PIX Query), and to any other transaction (except for the response portion of
ITI-9 and for ITI-10) that populates PID-3-Patient Identifier List.
Table E-3: Usage of HL7 Data Type CX by other IHE Actors
Cmp

Sbc

1

Len

DT

Opt

15

Tbl

Name

ST

R

ID

2

ST

O

Check digit

3

ID

O

0061

Conditionality predicate

Code identifying the__________________________________________________________________________
248
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
Cmp

Sbc

Len

DT

Opt

Tbl

Name

Conditionality predicate

check digit scheme
employed
4

227

HD

R

4

1

20

IS

C

4

2

199

ST

C

0363

Assigning authority

If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID

Must be populated if Subcomponents
2 and 3 are not populated.

Universal ID

Must be populated if Subcomponent 1
is not populated.
Populated if, and only if,
Subcomponent 3 is populated.

4

3

6

ID

C

0301

Universal ID type

Must be populated if Subcomponent 1
is not populated.
Populated if, and only if,
Subcomponent 2 is populated.

4965

5

ID

O

6

HD

O

Identifier type code
Assigning facility

6

1

IS

O

6

2

ST

C

6

3

ID

C

7

DT

O

Effective date

8

DT

O

Expiration date

0300

0301

If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID
Universal ID

Populated if, and only if,
Subcomponent 3 is populated.

Universal ID type

Populated if, and only if,
Subcomponent 2 is populated.

The definitions of the subcomponents of Component 4 are as given above for the Patient
Identifier Cross-reference Manager actor. If all three subcomponents are defined, Subcomponent
1 must refer to the same entity as Subcomponents 2 and 3.

E.3:
4970

0203

E.3 Examples of use

Metropolitan Medical Center treats a patient, Jane Smith, for whom 3 identifiers are known.
(For this example, assume that the HL7 V2 default delimiters are in use: | for field separator, ^for component separator, ~ for repetition separator and & for subcomponent separator.)

3.24.6

Data sent by source systems

The source systems provide data to the Patient Identifier Cross-reference Manager. These data
are sent either in a Patient Identity Feed transaction [ITI-8] or in response to a PIX Query.
4975•

Patient Smith’s Social Security number is 999-99-4452. This number is assigned by the U.S. Social
Security Administration.

__________________________________________________________________________
249
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________The ADT system sends the Social Security number at registration, in an occurrence of
PID-3-Patient Identifier List that looks like this:999-99-4452^^^USSSA
4980•

Note that only Subcomponent 1 of Assigning Authority is assigned here, while
Subcomponents 2 and 3 are left empty.
Patient Smith’s medical record number is 9990-99497. This number is assigned by Metropolitan
Medical Center, for which no external identifier is known. Metropolitan Medical Center incorporates
the Namespace ID 99MMC for the medical record numbers it assigns.

4985

The ADT system sends the medical record number at registration, in an occurrence of
PID-3-Patient Identifier List that looks like this:999099497^^^99MMC•

4990

Note again that only Subcomponent 1 of Assigning Authority is assigned here.
Patient Smith’s medical insurance number is 99998410. This number is assigned by MLH Life &Casualty Company, whose Internet domain name is www.mlhlifecasualty.com.9

The billing system sends the medical insurance number in an occurrence of PID-3Patient Identifier List that looks like this:99998410^^^&www.mlhlife.com&DNS
Note that only Subcomponents 2 and 3 of Assigning Authority are assigned here.
Also note the value DNS in the third subcomponent of Component 4 to indicate an
Internet domain name.

4995

3.24.7

5000

Data sent by the Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager implements HL7 Table 0363, Assigning
Authority, by incorporating the values in HL7 Version 2.5 as well as the values 99MMC for
Metropolitan Medical Center and 99MLHLIFE for MLH Life & Casualty.10 It also includes aknown ISO Object Identifier for the Social Security Administration, 1.2.mm.nnnnn.555.6666.11
To send the identifiers in PID-3-Patient Identifier List, the Patient Identifier Cross-referenceManager builds and concatenates them as follows.

9

Implementers should take into account the possibility that, as with any domain identifier, Internet domain
identifiers – either fully qualified domain names (FQDNs) or IPv4 or IPv6 addresses – are liable to change.
10

The use of 99 to preface these codes is not mandated by HL7, but reflects the practice directed by Chapter 7 of
HL7 Version 2.5 for specifying local coding system values.
11This OID is fictitious. The real OID for the SSA should be substituted here.

__________________________________________________________________________
250
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
5005•

In the first occurrence, the Social Security number is sent in the first component, as well as the known
internal and external values for SSN assigning authority in the fourth component. Note the value ISO
in the third subcomponent of Component 4 to indicate an ISO Object Identifier.

999-99-4452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO
5010•

In the second occurrence, the medical insurance number is sent in the first component, as well as the
known internal and external values for insurance number assigning authority in the fourth component.

99998410^^^99MLHLIFE&www.mlhlife.com&DNS•

5015

In the third occurrence, the medical record number is sent in the first component, as well as the
known internal and external values for MRN assigning authority in the fourth component. Note thatno external value is known for MRN assigning authority, so the HIS repeats the internal value as anexternal value and uses the value L in the third subcomponent of Component 4 to indicate a locallyassigned value.

999099497^^^99MMC&99MMC&L
5020

In sending all values in a PIX Update Notification transaction [ITI-10], the Patient Identifier
Cross-reference Manager concatenates the three PID-3-Patient Identifier List values using therepetition separator:|999994452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO~99998410^^^99A
BCLIFE&www.abclife.com&DNS~999099497^^^99MMC&99MMC&|__________________________________________________________________________
251
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5025

Appendix F:

Intentionally Left Blank__________________________________________________________________________
252
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix G:
G.1:

5030

5035

5040

5045

5050

5055

5060

5065

5070

5075

Transition from Radiology Basic Security to ATNA

Message Transformation

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-3881 format. It is provided for educational
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-microsoftcom: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{
var k = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
var o = "";var c1, c2, c3, e1, e2, e3, e4 = "";var l = 0;do{c1 = i.charCodeAt(l++);c2 = i.charCodeAt(l++);c3 = i.charCodeAt(l++);e1 = c1 >> 2;
e2 = ((c1 & 3) << 4) | (c2 >> 4);e3 = ((c2 & 15) << 2) | (c3 >> 6);e4 = c3 & 63;
if (isNaN(c2))
e3 = e4 = 64;
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 = "";}while (l < i.length);
return o;}]]></msxsl:script><xsl:template match="/IHEYr4"><AuditMessage><xsl:attributename="xsi:noNamespaceSchemaLocation">http://www.xml.org/xml/schema/7f0d86bd/healthcare-securityaudit.xsd</xsl:attribute><EventIdentification><xsl:attribute name="EventDateTime"><xsl:value-of
select="TimeStamp"/></xsl:attribute><xsl:apply-templates mode="EventIdentification"/></EventIdentification><xsl:apply-templates mode="ActiveParticipant"/><xsl:apply-templates mode="AuditSourceIdentification"/><xsl:apply-templates mode="ParticipantObjectIdentification"/>__________________________________________________________________________
253
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
5080

5085

5090

5095

5100

5105

5110

5115

5120

5125

5130

5135

5140

</AuditMessage></xsl:template><!-- =========================================== --><!-- EventIdentification--><!-- =========================================== --><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><EventID><xsl:attribute name="code"><xsl:value-of
select="'ActorConfig'"/></xsl:attribute></EventID><xsl:apply-templates mode="EventTypeCode"/></xsl:template><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></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><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"/></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><xsl:attribute name="code"><xsl:value-of
select="'BeginStoringInstances'"/></xsl:attribute></EventID><xsl:apply-templates mode="EventTypeCode"/></xsl:template><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
select="'DICOMInstancesDeleted'"/></xsl:attribute></EventID><xsl:apply-templates mode="EventTypeCode"/></xsl:template><xsl:template mode="EventIdentification" match="DICOMInstancesUsed"><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>__________________________________________________________________________
254
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5145

5150

5155

5160

5165

5170

5175

5180

5185

5190

5195

5200

5205

</EventID><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><EventID><xsl:attribute name="code"><xsl:value-of
select="'DICOMQuery'"/></xsl:attribute></EventID></xsl:template><xsl:template mode="EventIdentification" match="Export"><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></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><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"/></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><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"><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><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><EventID><xsl:attribute name="code"><xsl:value-of
select="'NetworkEntry'"/></xsl:attribute></EventID>__________________________________________________________________________
255
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5210

5215

5220

5225

5230

5235

5240

5245

5250

5255

5260

5265

<xsl:apply-templates mode="EventTypeCode"/></xsl:template><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
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"/><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><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></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><EventID><xsl:attribute name="code"><xsl:value-of
select="'ProcerdureRecord'"/></xsl:attribute></EventID></xsl:template><xsl:template mode="EventIdentification" match="SecurityAlert"><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="'SecurityAlert'"/></xsl:attribute></EventID><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><EventID><xsl:attribute name="code"><xsl:value-of
select="'StudyDeleted'"/></xsl:attribute></EventID><xsl:apply-templates mode="EventTypeCode"/></xsl:template><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>__________________________________________________________________________
256
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5270

5275

5280

5285

5290

5295

5300

5305

5310

5315

5320

5325

5330

<xsl:attribute name="code"><xsl:value-of
select="'UserAuthenticated'"/></xsl:attribute></EventID><xsl:apply-templates mode="EventTypeCode"/></xsl:template><xsl:template mode="EventIdentification" match="*"/><!-- =========================================== --><!-- EventIdentification / EventTypeCode--><!-- =========================================== --><xsl:template mode="EventTypeCode" match="Action"><EventTypeCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></EventTypeCode></xsl:template><xsl:template mode="EventTypeCode" match="AlertType"><EventTypeCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></EventTypeCode></xsl:template><xsl:template mode="EventTypeCode" match="ApplicationAction"><EventTypeCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></EventTypeCode></xsl:template><xsl:template mode="EventTypeCode" match="ConfigType"><EventTypeCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></EventTypeCode></xsl:template><xsl:template mode="EventTypeCode" match="MachineAction"><EventTypeCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></EventTypeCode></xsl:template><xsl:template mode="EventTypeCode" match="*"/><!-- =========================================== --><!-- Active Participant--><!-- =========================================== --><xsl:template mode="ActiveParticipant" match="ActorConfig"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="ActorName"><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><xsl:template mode="ActiveParticipant" match="ActorStartStop"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="AET"><xsl:attribute name="AlternativeUserID"><xsl:value-of select="."/></xsl:attribute></xsl:template><xsl:template mode="ActiveParticipant" match="AuditLogUsed"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="BeginStoringInstances"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="Destination"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template>__________________________________________________________________________
257
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5335

5340

5345

5350

5355

5360

5365

5370

5375

5380

5385

5390

<xsl:template mode="ActiveParticipant" match="DICOMInstancesDeleted"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="DICOMInstancesUsed"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="DicomQuery"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="Export"><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><xsl:template mode="ActiveParticipant" match="Import"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="InstanceActionDescription"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="InstancesSent"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="InstancesStored"><ActiveParticipant><xsl:apply-templates mode="ActiveParticipant" select="RemoteNode"/><xsl:attribute name="UserIsRequestor"><xsl:value-of
select="true()"/></xsl:attribute></ActiveParticipant></xsl:template><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><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><xsl:attribute name="code"><xsl:value-of
select="'Printer'"/></xsl:attribute></RoleIDCode></ActiveParticipant></xsl:template><xsl:template mode="ActiveParticipant" match="LocalUser"><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><xsl:attribute name="UserIsRequestor"><xsl:value-of
select="true()"/></xsl:attribute></ActiveParticipant></xsl:template><xsl:template mode="ActiveParticipant" match="MediaID"><ActiveParticipant><xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute>__________________________________________________________________________
258
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5395

5400

5405

5410

5415

5420

5425

5430

5435

5440

5445

5450

<xsl:attribute name="UserIsRequestor"><xsl:value-of
select="false()"/></xsl:attribute><xsl:apply-templates mode="ActiveParticipantRoleIDCode"select="../MediaType"/></ActiveParticipant></xsl:template><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></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></ActiveParticipant></xsl:template><xsl:template mode="ActiveParticipant" match="OrderRecord"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="PatientRecord"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="ProcedureRecord"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="RemoteNode"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="Requestor"><ActiveParticipant><xsl:apply-templates mode="ActiveParticipant"/><xsl:attribute name="UserIsRequestor"><xsl:value-of
select="true()"/></xsl:attribute></ActiveParticipant></xsl:template><xsl:template mode="ActiveParticipant" match="RNode"><ActiveParticipant><xsl:apply-templates mode="ActiveParticipant"/><xsl:attribute name="UserIsRequestor"><xsl:value-of
select="false()"/></xsl:attribute></ActiveParticipant></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><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"/></xsl:template><xsl:template mode="ActiveParticipant" match="User"><ActiveParticipant><xsl:apply-templates mode="ActiveParticipant"/>__________________________________________________________________________
259
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
5455

5460

5465

5470

5475

5480

5485

5490

5495

5500

5505

5510

5515

<xsl:attribute name="UserIsRequestor"><xsl:value-of
select="true()"/></xsl:attribute></ActiveParticipant></xsl:template><xsl:template mode="ActiveParticipant" match="UserAuthenticated"><xsl:apply-templates mode="ActiveParticipant"/></xsl:template><xsl:template mode="ActiveParticipant" match="*"/><!-- =========================================== --><!-- Active Participant / RoleIDCode--><!-- =========================================== --><xsl:template mode="ActiveParticipantRoleIDCode" match="MediaType"><RoleIDCode><xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute></RoleIDCode></xsl:template><xsl:template mode="ActiveParticipantRoleIDCode" match="*"/><!-- =========================================== --><!-- AuditSourceIdentification--><!-- =========================================== --><xsl:template mode="AuditSourceIdentification" match="Host"><AuditSourceIdentification><xsl:attribute name="AuditSourceID"><xsl:value-of
select="."/></xsl:attribute></AuditSourceIdentification></xsl:template><xsl:template mode="AuditSourceIdentification" match="*"/><!-- =========================================== --><!-- ParticipantObjectIdentification--><!-- =========================================== --><xsl:template mode="ParticipantObjectIdentification" match="BeginStoringInstances"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="DICOMInstancesDeleted"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="DICOMInstancesUsed"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="DicomQuery"><ParticipantObjectIdentification><xsl:attribute name="ParticipantObjectTypeCode"><xsl:value-of
select="2"/></xsl:attribute><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></ParticipantObjectIDTypeCode><xsl:apply-templates mode="ParticipantObjectQuery" select="Keys"/><xsl:apply-templates mode="ParticipantObjectDetail" select="SyntaxUID"/></ParticipantObjectIdentification></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="Export"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="Import"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="InstanceActionDescription"><xsl:apply-templates mode="ParticipantObjectIdentification"/>__________________________________________________________________________
260
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5520

5525

5530

5535

5540

5545

5550

5555

5560

5565

5570

5575

5580

</xsl:template><xsl:template mode="ParticipantObjectIdentification" match="InstancesSent"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="InstancesStored"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="OrderRecord"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="Patient"><ParticipantObjectIdentification><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><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"/></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></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="PatientName"><ParticipantObjectName><xsl:value-of select="."/></ParticipantObjectName></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="PatientRecord"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="ProcedureRecord"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="SecurityAlert"><ParticipantObjectIdentification><xsl:attribute name="ParticipantObjectID"><xsl:value-of
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><ParticipantObjectIDTypeCode><xsl:attribute name="code"><xsl:value-of
select="12"/></xsl:attribute></ParticipantObjectIDTypeCode><xsl:apply-templates mode="ParticipantObjectDetail" select="Description"/></ParticipantObjectIdentification></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="StudyDeleted"><xsl:apply-templates mode="ParticipantObjectIdentification"/></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="SUID"><ParticipantObjectIdentification>__________________________________________________________________________
261
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5585

5590

5595

5600

5605

5610

5615

5620

5625

5630

5635

5640

<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
select="3"/></xsl:attribute><ParticipantObjectIDTypeCode><xsl:attribute name="code"><xsl:value-of
select="'9'"/></xsl:attribute></ParticipantObjectIDTypeCode><xsl:apply-templates mode="ParticipantObjectDetail"select="../AccessionNumber"/><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"/></ParticipantObjectIdentification></xsl:template><xsl:template mode="ParticipantObjectIdentification" match="*"/><!-- ========================================================= --><!-- ParticipantObjectIdentification / ParticipantObjectDetail --><!-- ========================================================= --><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
select="js:encode64(string(.))"/></xsl:attribute></ParticipantObjectDetail></xsl:template><xsl:template mode="ParticipantObjectDetail" match="CUID"><ParticipantObjectDetail><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><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></ParticipantObjectDetail></xsl:template><xsl:template mode="ParticipantObjectDetail" match="FillerOrderNumber"><ParticipantObjectDetail><xsl:attribute name="type"><xsl:value-of
select="'FillerOrderNumber'"/></xsl:attribute><xsl:attribute name="value"><xsl:value-of
select="js:encode64(string(.))"/></xsl:attribute></ParticipantObjectDetail></xsl:template><xsl:template mode="ParticipantObjectDetail" match="MPPSUID"><ParticipantObjectDetail><xsl:attribute name="type"><xsl:value-of
select="'ContainsMPPS'"/></xsl:attribute>__________________________________________________________________________
262
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5645

5650

5655

5660

5665

5670

5675

5680

5685

5690

<xsl:attribute name="value"><xsl:value-of
select="js:encode64(string(.))"/></xsl:attribute></ParticipantObjectDetail></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
select="js:encode64(string(.))"/></xsl:attribute></ParticipantObjectDetail></xsl:template><xsl:template mode="ParticipantObjectDetail" match="PlacerOrderNumber"><ParticipantObjectDetail><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><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
select="js:encode64(string(.))"/></xsl:attribute></ParticipantObjectDetail></xsl:template><xsl:template mode="ParticipantObjectDetail" match="SyntaxUID"><ParticipantObjectDetail><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><xsl:template mode="ParticipantObjectDetail" match="*"/><!-- ========================================================= --><!-- ParticipantObjectIdentification / ParticipantObjectQuery --><!-- ========================================================= --><xsl:template mode="ParticipantObjectQuery" match="Keys"><ParticipantObjectQuery><xsl:value-of select="."/></ParticipantObjectQuery></xsl:template><xsl:template mode="ParticipantObjectQuery" match="*"/><!-- =========================================== --><!-- Discard everything else--><!-- =========================================== --><xsl:template match="*"/></xsl:stylesheet>__________________________________________________________________________
263
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5695

Appendix H:
H.1:

Required Registry Initialization and Schema

Initialization

A standard ebXML Registry must be initialized with key Classification Schemes and object
types to support XDS. An ebXML Registry SubmitObjectsRequest is available to perform thisinitialization. It includes:
5700•

Classification Schemes that anchor the definition of ExternalIdentifiers•

Additions to the ObjectType ClassificationScheme that introduces a general XDS
ClassificationNode that anchors these additions. The usable new ClassificationNodes are:
XDSDocumentEntry, XDSDocumentEntryStub, XDSFolder, and XDSSubmissionSet.
XDSDocumentEntry and XDSDocumentEntryStub are used as new objectTypes for use in an
ExtrinsicObjectto create XDS specific object types. XDSFolder and XDSSubmissionSet are used
to classify RegistryPackage objects to label them as XDS Folders or XDS SubmissionSets.

•

External Classification Schemes to support attribute coding.

5705

This initialization includes the assignment of UUIDs to these definitions. These pre-assigned
UUIDs shall be used when implementing XDS.
5710

H.2:

SchemaAn XML Schema has been defined for XDS.

H.3:

5715

Location

These resources be found on the IHE website:
http://www.ihe.net
Select Resources tab (one of the tabs listed across the top of the page)
Select Integration Profiles – Supplemental Information
Navigate to the XDS section__________________________________________________________________________
264
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix I:
5720

5725

Required Initialization of the Affinity Domain

This initialization supports the operation of the Registry Adaptor. The following informationmust be provided by the Affinity Domain administrator and loaded into the Registry Adaptor.
This supports the functionality specified for the Registry Adaptor in section 3.14.4.1.2.11. How
this information is loaded into the Registry Adaptor or how the Registry Adaptor is implemented
is not defined by this profile.
1. List of acceptable mimeTypes for documents indexed by the registry.
2. PIX domain name (Assigning Authority) for XDS Affinity Domain. PatientIds attached
to metadata submitted to this registry must come from this PIX Assigning Authority.

5730

3. Acceptable values for all coded attributes represented in the registry by ebXML External
Classifications. These include classCode, eventCode, confidentialityCode,healthCareFacilityTypeCode, formatCode for XDS Document and
XDSSubmissionSet.code and XDSFolder.codeList.

__________________________________________________________________________
265
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix J:
5735

Example Submissions and Query Results

Sample submissions, queries, and query results may be found on the IHE website at:
http://www.ihe.net
Select Resources tab (one of the tabs listed across the top of the page)
Select Implementors Tools
Navigate to the XDS section__________________________________________________________________________
266
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5740

Appendix K:

XDS Security Environment

This Appendix expands on the summary provided in the XDS Volume 1 specification (ITI TF-1:
Appendix H).

5745

5750

5755

5760

The XDS operations assume that a suitable security and privacy environment has been
established. Almost all of the relevant threats will be managed by agreements, policies, andtechnologies that are external to the XDS transactions. The few that affect the XDS transactions
will be managed by generic security mechanisms that are not unique to XDS. The threats andsecurity objectives that must be addressed are described in sections 1 and 2 below. Only a few
of these have issues that are unique to the XDS application.
Section 3 discusses these few threats and objectives in terms of the agreements and policies thatneed to be established to create a suitable environment for XDS. Establishing these agreements
often involves business agreement discussions that are part of establishing the XDS affinity
group. These agreements are necessary because the exchange of documents implies agreeing to
the delegation of responsibility for maintaining the security of these documents and for providing
the necessary audit and record keeping facilities.

K.1:

Security Environment

3.24.8Threats

Specific threats to the overall XDS system are listed below. These threats are identified using
the Common Criteria nomenclature defined by ISO 17799. Most of these are mitigated bypolicies, procedures, and technologies that are not unique to XDS and do not require any special
XDS considerations. Many of these mitigations do require that the parties within the XDS
affinity group have agreement on details of how they will work together.
T.ADMIN_ERROR Improper administration may result in defeat of specific security features.
T.ADMIN_ROGUE Authorized administrator’s intentions may become malicious resulting in
TSF data to be compromised.

5765

T.AUDIT_CORRUPTA malicious process or user may cause audit records to be lost or
modified, or prevent future records from being recorded by taking actions to exhaust audit
storage capacity, thus masking an attacker’s actions.
T.CONFIG_CORRUPTA malicious process or user may cause configuration data or othertrusted data to be lost or modified.

5770

T.DISASTER System or network may failure due to disaster (e.g. fire, earthquake).
T.DOS
A malicious process or user may block others from system resources via a
resource exhaustion denial of service attack.
__________________________________________________________________________
267
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5775

T.EAVESDROP
A malicious process or user may intercept transmitted data inside oroutside of the enclave. Some of the XDS environments are not concerned with eavesdrop
exposure. They may employ external protective mechanisms such as physical network security
or VPNs to protect against eavesdropping.
T.HARDWARE

Hardware may malfunction.

T.IMPROPER_INSTALLATION XDS components may be delivered, installed, orconfigured in a manner that undermines security.
5780

T.INSECURE_START
T.INTRUSION

Reboot may result in insecure state of the operating system.

Malicious software (e.g. virus) may be introduced into the system.

T.MASQUERADE A malicious process or user on one machine on the network may
masquerade as an entity on another machine on the same network.
5785

T.OBJECTS_NOT_CLEAN
Systems may not adequately remove the data from objects
between usage by different users, thereby releasing information to a user unauthorized for thedata. This also includes swapping hard disk with PHI during service and repair.
T.POOR_DESIGN Unintentional or intentional errors in requirement specification, design ordevelopment of the TOE components may occur.

5790

T.POOR_IMPLEMENTATION Unintentional or intentional errors in implementing thedesign of the XDS environment may occur.
T.POOR_TEST
Incorrect system behavior may result from inability to demonstrate that allfunctions and interactions within the XDS operation are correct.
T.REPLAY A malicious process or user may gain access by replaying authentication (orother) information.

5795

T.SPOOFING
A hostile entity may masquerade itself as part of the XDS affinity groupand communicate with authorized users who incorrectly believe they are communicating withauthorized members.
T.SYSACC A malicious process or user may gain unauthorized access to the administrator
account, or that of other trusted personnel.

5800

T.UNATTENDED_SESSION
to an unattended session.

A malicious process or user may gain unauthorized access

T.UNAUTH_ACCESS
Unauthorized access to data by a user may occur. This includes
access via direct user interaction with the device, access via network transactions, and access via
removable electronic and printed media.
5805

T.UNAUTH_MODIFICATION
resources may occur.

Unauthorized modification or use of XDS attributes and__________________________________________________________________________
268
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

5810

T.UNDETECTED_ACTIONS
unauthorized actions may occur.

Failure of the XDS components to detect and record

T.UNIDENTIFIED_ACTIONS
unauthorized actions may occur.

Failure of the administrator to identify and act upon

T.UNKNOWN_STATE
Upon failure of XDS components, the security of the XDS
environment may be unknown.
T.USER_CORRUPT

3.24.9User data may be lost or tampered with by other users.

Security and Privacy Policy

5815

There are a wide variety of security and privacy regulations established by law and regulation.
These are interpreted and extended to create individual enterprise policies. This equipment will
be installed into a variety of enterprises that are subject to a variety of laws and regulations. The
XDS environment will provide support for the common aspects of these enterprise policies. The
policy statements whose enforcement must be provided by the XDS security mechanisms are:5820

P.ACCOUNT
the system.

The users of the system shall be held accountable for their actions within

P.AUTHORIZATIONThe system must limit the extent of each user’s abilities inaccordance with the TSPP. (See P.PATIENT_CARE)
5825

P.AUTHORIZED_USERS Only those users who have been authorized to access theinformation within the system may access the system. (See P.PATIENT_CARE)
P.CRYPTOGRAPHY
The system shall use standard approved cryptography (methods
and implementations) for key management (i.e., generation, access, distribution, destruction,
handling, and storage of keys) and cryptographic services (i.e., encryption, decryption, signature,hashing, key exchange, and random number generation services).

5830

P.DECLARATIVE_SECURITY The system shall allow the administrator to define security
related rules. Examples include defining access control policies and password expiration
restriction.
P.I_AND_A All users must be identified and authenticated prior to accessing any controlled
resources with the exception of public objects.

5835

5840

P.OBJECTAUTHORIZATION The XDS components must enforce the policy regarding
how authorization is established for protected objects. The policy determines how access control
and other policies are enforced. (This is often considered part of P.Authorization, but in the
XDS context it may make sense to consider this as a separate policy.)
P.PATIENT_CARE The security and privacy measures should not prevent patient care. In
particular, there should be emergency bypass mechanisms to override security when necessary toprovide patient care.
__________________________________________________________________________
269
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
P.SYSTEM_INTEGRITY The system must have the ability to periodically validate its correct
operation and, with the help of Administrators, Backup and Restore Operators, and Service
Personnel, it must be able to recover from any errors that are detected.
5845

5850

P.TRACEThe primary method for enforcing the security and privacy policy is the use ofauditing. The XDS components must have the ability to review the actions of individuals. The
XDS environment must provide sufficient audit information to external audit and monitoring
systems to permit the review of actions of individuals by that other system.
P.TRUSTED_RECOVERY
Procedures and/or mechanisms shall be provided to assure
that, after a system failure or other discontinuity, recovery without a protection compromise is
obtained
P.VULNERABILITY_SEARCH The XDS environment must undergo an analysis forvulnerabilities beyond those that are obvious.

3.24.10 Security Usage Assumptions
5855

Assumptions of the use of the XDS environment:
A.PHYSICAL
It is assumed that appropriate physical security is provided within thedomain for the value of the IT assets and the value of the stored, processed, and transmitted
information.

5860

A. AUDIT_REVIEW
It is assumed that there will be audit repository and review services
provided that can accept audit information from the XDS components in real time.
A.OPERATION
It is assumed that networks, firewalls, etc. are deployed andmaintained to meet appropriate network security levels.
A.PERSONNEL
It is assumed that the organization can assure IT user & otherworkforce personal integrity/trustworthiness.

5865

A.PKI It is assumed that there will be a facility to provide signed certificates as needed for nodeand user authentication. The key management maybe done manually or automatically dependingon the availability of appropriate technology.

K.2:
5870

Security Objectives

This section defines the security objectives for the XDS environment. These objectives are
suitable to counter all identified threats and cover all identified organizational security policies
and assumptions. Common Criteria nomenclature is used. The XDS component security
objectives are identified with “O.” appended to at the beginning of the name and the environment
objectives are identified with “OE.” appended to the beginning of the name.

__________________________________________________________________________
270
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
5875

3.24.11 XDS Component Security Objectives
O.ACCESS The XDS components will ensure that users gain only authorized access to it andto the resources that it controls. (See O.EMERGENCY_BYPASS)
O.ACCESS_HISTORYThe XDS components will display information (to authorizedusers) related to previous attempts to establish a session.

5880

O.ADMIN_ROLE The XDS components will provide separate administrator roles to isolate
administrative actions. These include a General Administrator role, a Backup and Restore
Operator role, a Cryptographic Administrator role, and a Service Personnel role. Additionalroles can be defined. These roles are collectively called Administrators.

5885

O.ADMIN_TRAINEDThe XDS components will provide authorized Administrators with
the necessary information for secure management and operation.

5890

O.AUDIT_GENERATIONThe XDS components will provide the capability to detectand create records of security and privacy relevant events associated with users. The XDS
components will reliably transmit this information to the central audit repository, and provide
reliable local storage of events until the central audit repository has confirmed receipt. (SeeOE.AUDIT_REVIEW)
O.AUDIT_PROTECTION Each XDS component will provide the capability to protect audit
information within its scope of control.

5895

O.AUDIT_REVIEW
If an external central audit repository is not part of the environment,
the components will be configured to provide limited capability to analyze and selectively viewaudit information. (See OE.AUDIT_REVIEW)
O.CONFIG_MGMT
be tracked and controlled.

All changes to the components and its development evidence will

O.DECLARATIVE_SECURITY The components will allow security functions and access
control to be defined by the authorized administrator.
5900

O.DISASTER_RECOVERYThe components should allow the authorized
Administrators to perform backup and restore of electronic data, and rapid configuration andreconfiguration of device operation. In addition, the TOE should support administrative
procedures to restore operation after disasters that may have substantially destroyed portions of
the hospital operation and where substitute temporary systems are in place.

5905

O.DISCRETIONARY_ACCESS The components will control accesses to resources based
upon the identity of users and the role of users. (See O.EMERGENCY_BYPASS)
O.DISCRETIONARY_USER_CONTROLThe components will allow authorized users
to specify which resources may be accessed by which users and groups of users. (SeeO.EMERGENCY_BYPASS)__________________________________________________________________________
271
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
5910

O.EMERGENCY_BYPASSThe XDS components should allow access to any secured data
during a declared medical emergency.
O.ENCRYPTED_CHANNEL
Based on the environmental policies, encryption may be
used to provide confidentiality of protected data in transit over public network.

5915

O.INSTALL The XDS components will be delivered with the appropriate installation guidancein the form of installation manuals and training to establish and maintain component security.
O.INTRUSION_DETECTION
software (e.g. virus) is detected.

The XDS components will ensure intrusion of malicious

O.MANAGE The XDS components will provide all the functions and facilities necessary tosupport the authorized Administrators in their management of the security of the TOE.
5920

O.PROTECT
resources.

The XDS components will provide means to protect user data andO.RECOVERY
Procedures and/or mechanisms will be provided to assure that recovery is
obtained without a protection compromise, such as from system failure or discontinuity.
5925

O.REMOTE_SERVICEThe XDS components will provide the means for remote service
without sacrificing security or privacy policy.
O.RESIDUAL_INFORMATION The XDS components will ensure that any information
contained in a protected resource is not released when the resource is reallocated. Informationon permanent media such as hard disk shall be secured during service and repair.
O.RESOURCE_SHARING

5930

No user will block others from accessing resources.

O.SELF_PROTECTION Each XDS component will maintain a domain for its own
execution that protects itself and its resources from external interference, tampering, or
unauthorized disclosure.
O.TRAINED_USERS
The XDS environment will provide authorized users with thenecessary guidance for secure operation.

5935

O.TRUSTED_PATHThe TOE will provide a means to ensure users are notcommunicating with some other entity pretending to be the TOE. This covers entity
authentication. (See O.USER_AUTHENTICATION.)O.TRUSTED_SYSTEM_OPERATION
maintains security.

5940

The XDS components will function in a manner that

O.USER_AUTHENTICATION The XDS components will verify the claimed identity of
the interactive user. (See O.ENTITY_AUTHENTICATION.)
O.USER_IDENTIFICATION
users.

The XDS components will uniquely identify the interactive__________________________________________________________________________
272
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

3.24.12 Environment Security Objectives
5945

5950

OE.PHYSICAL
Physical security will be provided within the domain for the value of the
IT assets protected by the XDS environment and the value of the stored, processed, andtransmitted information.
OE.AUDIT_REVIEW
There may be an audit repository and review service provided that
can accept audit information from the XDS environment in real time. This facility will provide
review and analysis functions. (See O.AUDIT_GENERATION, O.AUDIT_REVIEW)
OE.OPERATION
Networks, firewalls, etc. are deployed and maintained to meet
appropriate network security levels.
OE.PERSONNEL
integrity/trustworthiness.

5955

OE.PKI
There will be a facility to provide signed certificates as needed for node and user
authentication.

K.3:

5960

Assure IT user & other workforce personal

Functional Environment

The XDS can be modelled as having four different organizations that have a delegatedresponsibility relationship where each organization has a different functional responsibility. In
some configurations a single organization is responsible for two or more of these functions,which makes delegation much easier. This section discusses the major areas that must be solved.
The four functions are:Creator – This functional organization has created the PHI and is legally responsible to thepatient and others for providing healthcare and for protecting this data.

5965

5970

Repository – This functional organization is responsible for providing access to persistent
documents to readers. The creator has delegated responsibility to the repository to provide
adequate protection for a subset of the PHI. This subset is called the document.
Registry - This functional organization is responsible for providing query services to readers.
The creator has delegated responsibility to the to the registry to provide adequate protection for asubset of the PHI. This subset is called the metadata.
Reader – This functional organization is providing healthcare services that make use of data thatis contained in the metadata and the documents.
There are three levels of difficulty in delegation.

5975“Trivial” delegation is that where it is not necessary to delegate the responsibility for
implementing the threat mitigation. In those cases it does not matter whether the organizations
have the same policy or mitigations. For example, if the registry provides adequate mitigation__________________________________________________________________________
273
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
against the threat of disaster, it need not be concerned with the disaster related policies of thereader.
5980

5985

5990

5995

6000

6005

“Easy” delegation is that where the two organizations have the equivalent policies. In thosecases there is an initial difficult phase of discovering that the policies are the same and evaluatingthat the mitigation strategies are acceptable. This results in a simple binary decision to approveor disapprove a business relationship permitting the exchange of data. With the exception of thethree policy classes described as “hard” below, the details of policies are likely to differ, but thegoals are sufficiently uniform that a simple business decision can be made.
For the “easy” delegation, the IHE transactions must provide adequate mitigations for the threatsso that the business decision to exchange data can be made based simply on review of thepartners policies and mitigations. This means that some IHE transactions will have additional
security requirements attached. For example, encryption to avoid the threat of eavesdropping
may be required. These requirements are not unique to XDS and will be able to use standardized
security features like TLS and VPN tools. These requirements may be significantly different
from the usual practice within an enterprise, because of the differences in the environment.
“Hard” delegation is that where the two organizations have different policies orinconsistent/incompatible mitigation strategies. These are likely to occur for the following
policies, where organizations often disagree on the details of the policy goals, and where policies
often change:
P.Authorization – The authorized access policies and authorized modification policies often
differ, and are often subject to change. The changes that occur are often at a detailed level, e.g.
access rights to a particular patient information may change. This means that either there is anagreed mechanism to propogate changes, or an acceptance that policy changes may not be
enforced, or there will be restrictions on the data exchange to avoid delegating responsibility fordata that is subject to change.
P.Account and P.trace – The policies for accountability and traceability often differ. These aremuch less subject to change, but it is often difficult to reconcile delegation when these policies
differ. This will be an especially difficult issue for repository and registry functions that support
multiple different creator organizations.
P.ObjectAuthorization – The policies regarding creation and modification of access rights often
differ.

6010

6015

In addition, any of the policy and threat mitigations may be determined to be unacceptable bycreator, registry, or repository. In the simple situation where there are only four real world
participants this simply means that there is no business relationship. In the more complex world
where the registry or repository are in many relationships with many creators and readers it
introduces a serious problem. Either the registry and repository must limit its relationship to that
small set of creators and readers that mutually accept all the policies and mitigations of all the__________________________________________________________________________
274
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
other organizations, or there must be a mitigation strategy so that creators can restrict delegations
by the registry and repository to only those readers that have policies and mitigations that are
acceptable to the creator.
Mitigations for differences include the following:
6020

6025

Limit the data exchange to that data where the differences are not significant. For example,
highly sensitive data like psychiatric notes might not be shared, while relatively insignificant
data like allergy information is shared.
Provide a revocation mechanism to deal with policy changes, so that future delegations can beprohibited. It is often impractical to revoke past delegations because the PHI has already been
disclosed. But the revocation mechanism can stop further delegation from taking place. This
revocation mechanism must be part of the P.Authorization and P.ObjectAuthorization policies
and must be mutually acceptable for this mitigation to be effective.
Trusted third party inspections and audits can sometimes deal with reconciliation of differencesin P.Account and P.Trace.

6030

6035

6040

6045

An “approved delegation” list identifying acceptable and unacceptable creator/reader pairs canmitigate the repository and registry issues when the reader has incompatible policies with thecreator. This does require the creator to accept the approved delegation policy andimplementation of the repository and registry, but it reduces the combinatorial explosion ofpolicy combinations between creators, repositories, registries, and readers into a linear growth incomplexity.
The “approved delegation” may go further into identification of persons, but this is only a viable
path when all parties have policies the easily support delegation of personal responsibility.
Persons are usually required to comply with organizational policies, and organizations generally
use roles rather than persons to establish policies. The often viable exception is the special caseof the “deny access to person X”. This can be a viable means of dealing with situations
involving a conflict of interest. This kind of access denial may be applicable to just a particularsubset of the PHI exchanged, (e.g. denying access to an ex-spouse).
These mitigations do not directly change the technical requirements for the XDS transactions.
They are policy decisions that may affect how particular actors are configured. The
implementation of XDS actors will need to be aware that this kind of site-specific configuration
management and policy control will be routinely required.

__________________________________________________________________________
275
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix L:
6050

6055

Relationship of Document Entry Attributes andDocument Headers

XDS Document Entry attributes, placed in the XDS Document Registry by Document Sources,
may be derived from header data present in the document content. Although the XDS
Integration Profile does not mandate a strict relationship, this appendix illustrates sample
mappings of XDS Document Entry attributes to header fields of some standard document
formats. This relationship does not imply that values are mapped or copied directly astransformations may be needed between conventions in the EHR-CR and EHR-LR (e.g.
vocabulary mappings).
Table L-1 Relationship of XDS Document Attributes to Document header fields

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOM

patientIdlevelone

ClinicalDocument>clinical_document_header>recordTarget

Class:
EHR_EXTRACT>>patient>>>id

serviceStartTime>>patientRole>>>idmapped into XDS Affinity
Domain patient id domain

mapped into XDS
Affinity Domain
patient id domain

levelone

ClinicalDocument>clinical_document_header>>patient_encounter>documentationOf>>>encounter_tmr>>>effectiveTime>>event

attribute:subject_of_care[1]: IImapped into XDS
Affinity Domain
patient id domain
Class:
CLINICAL_SESSION
attribute:session_time[1]:
IVL<TS>

low=
serviceStopTimelevelone

ClinicalDocument>clinical_document_header >>patient_encounter>documentationOf>>>encounter_tmr>>>effectiveTime>>eventhigh=__________________________________________________________________________
276
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOM

classCodeInferred from

Inferred fromlevelone

ClinicalDocument

Class
COMPOSITION>clinical_document_heade
r

>code

>>document_type_cd

Attribute: to be added.

codeSystem=
code=

RT=
EX=
classCodeDispla Inferred fromyNamelevelone>clinical_document_header>>document_type_cd

Inferred from
ClinicalDocument>code
codeSystem=
code=

DN=
practiceSettingC leveloneode>clinical_document_header >>patient_encounter>>>practice_setting_cd
V=Inferred from
ClinicalDocument(need input from CEN
TC 251)>code
codeSystem=
code=

S=
practiceSettingC leveloneode>clinical_document_heade
DisplayNamer >>patient_encounter>>>practice_setting_cd
DN=

Inferred from
ClinicalDocument>code
codeSystem=code=__________________________________________________________________________
277
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

healthcareFacilit Inferred fromylevelone
TypeCode>clinical_document_header >>patient_encounter>>>practice_setting_cd

CDA R2 Draft Aug
2004

EHRCOM

Inferred fromClass
CLINICAL_SESSION

ClinicalDocument>code
codeSystem=

attribute:healthcare_facility[0..
1]: II

code=

V=
S=
healthcareFacilityTypeCodeDispl
ay
Name

Inferred from

Inferred fromlevelone

ClinicalDocument>clinical_document_header >>patient_encounter>code>>>practice_setting_cd

codeSystem=
code=

DN=
availabilityStatusuniqueId

N/A

N/A

N/A

(Generated and maintainedby the Registry)(Generated andmaintained by theRegistry)(Generated andmaintained by theRegistry)levelone

ClinicalDocument>clinical_document_heade
r

>id

Class
RECORD_COMPON
ENT
attribute: rc_id[1]: II>>id
typeCodelevelone

ClinicalDocument>clinical_document_heade
r

>code

>>document_type_cd

codeSystem=
code=

Class
RECORD_COMPON
ENT
attribute:meaning[0..1]: CVRT=EX=__________________________________________________________________________
278
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

typeCodeDisplayNamelevelone

ClinicalDocument>clinical_document_heade
r

>code

EHRCOM

displayName=>>document_type_cd
DN=
formatCode

ClinicalDocument>typeIdClass
EHR_EXTRACT
attribute: rm_id[1]:StringeventCodeInferred from

Inferred fromlevelone

ClinicalDocument>clinical_document_heade
r

>code

>>document_type_cd(need input from CEN
TC 251)

codeSystem=
code=

RT=
EX=
eventCodeDispl
ay
Name

Inferred from

Inferred fromlevelone

ClinicalDocument>clinical_document_heade
r

>code

>>document_type_cd(need input from CEN
TC 251)

codeSystem=
code=

RT=
EX=
title

Inferred from

ClinicalDocument

levelone>title>clinical_document_header

Class:
RECORD_COMPON
ENT
attribute: name[1]:TEXT>>document_type_cd__________________________________________________________________________
279
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOM

ClinicalDocument

Class
CLINICAL_SESSION

DN=
authorInstitution levelone>clinical_document_header>author>>assignedAuthor>>originating_organization >>>representedOrgani
zation>>>organization

attribute:healthcare_facility[0..
1]: II>>>>nameauthorPersonlevelone

ClinicalDocument>clinical_document_header>author>>originator>>>assignedAuthorChoice>>>person>>assignedAuthor

Class:COMPOSITION
attribute:composer[0..1]: II>>>>person
legalAuthenticat leveloneor>clinical_document_header>>legal_authenticator

ClinicalDocument>legalAuthenticator>>assignedEntity>>>person>>>person

URI

N/A

parentDocument levelone
Relationship>clinical_document_header>>document_relationship>>>document_relationship.type_cd

Class
FUNCTIONAL_ROL
E(association from classATTESTATION)
attribute:
performer[1]: II

N/A

N/A

ClinicalDocument>relatedDocument

IN THE CASE OF
REPLACEMENT

typeCode=Class: AUDIT_INFO
attribute:revision_status
CS_REV_STAT
IN THE CASE OF
ADDENDUM or__________________________________________________________________________
280
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOM
TRANSFORM
Class LINK
attribute nature: CVparentDocument levelone
Id>clinical_document_header>>document_relationship

ClinicalDocument>relatedDocument>>parentDocument>>>id>>>related_document

IN THE CASE OF
REPLACEMENT
attribute:previous_version[0..1]: II
This attribute uniquely
identifies theRECORD_COMPONENT of which thecurrent
RECORD_COMPONENT is a revision (nullfor the first everversion).

>>>>idIN THE CASE OF
ADDENDUM or
TRANSFORM
Class LINK
Attribute: target[1]: IIconfidentialityC
odelevelone

ClinicalDocument>clinical_document_header>confidentialityCode

Class
RECORD_COMPON
ENT
attribute:sensitivity[1]:CS_SENSITIVITY>>confidentiality_cd
RT=EX=
languageCode

xml:lang attribute

ClinicalDocument>relatedDocument

This attribute is aproperty of all text
data types in CEN,

typeCode=__________________________________________________________________________
281
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOMand so we have notdefined a separate
overall language togovern the whole
document. It might bereasonable to assume
that the natural
language used for thename attribute isconsidered to be areasonable guide to
the value of this
attribute.

patientId
AssignBySourcelevelone

ClinicalDocument>clinical_document_header>recordTarget>>patient>>patientRole

Class:
EHR_EXTRACT
attribute:subject_of_care[1]: II>>>id>>>person>>>>idpatientInfo
AssignBySourcelevelone

ClinicalDocument>clinical_document_header>recordTarget>>patient>>>person>>patientRole>>>patientPatient>>>>name>>>>person_name
size

hash

N/A

N/A

N/A

Total length of submitted
document.

Total length ofsubmitted document.

Total length ofsubmitted document.

N/A

N/A

N/A

Hash of submitted
document.

Hash of submitted
document.

Hash of submitted
document.

__________________________________________________________________________
282
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Attribute

CDA R1-2000

CDA R2 Draft Aug
2004

EHRCOM

entryUUID

N/A

N/A

N/A

Generated by registry

Generated by registry.

Generated by registry.

__________________________________________________________________________
283
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

Appendix M:
6060

M.1:

Using Patient Demographics Query in a Multi-Domain
Environment

HL7 QBP^Q22 Conformance Model

6065

The HL7 Find Candidates Query (QBP^Q22) defines a patient demographics query between aclient application and an MPI system (HL7 V2.5, Page 3-64). This implies that the server
maintains a master record of the patient demographics, but may know a number of patient
identifiers from other domains.

6070

In the QBP^Q22 Conformance Statement, QPD-8 (What Domains Returned) is defined as “theset of domains for which identifiers are returned in PID-3” (HL7 V2.5, Page 3-66, second table).
Note that this field does not cite “demographics information in some domains”, but about“identifiers issued in some domains”, and explicitly specifies that these identifiers are returned in
PID-3 (Patient ID List).

6075

In the example following the Conformance Statement in HL7 2.5, three patient records areincluded in the query response; each returned patient record includes two identifiers in PID-3(domains METRO HOSPITAL and SOUTH LAB) as requested in the query. However, one setof demographic information is returned in the remainder of the PID segment. The example does
not illustrate or assume a mechanism for returning multiple sets of demographic information.
Thus it appears that QBP^Q22 is not intended to provide a way to issue a single query for patient
demographics maintained in multiple different patient registration systems (domains).

M.2:
6080

6085

IHE PDQ Architecture

In the PDQ Integration Profile, the supplier is characterized as a Patient Demographics Supplier.
The supplier is not assumed nor required to be an MPI system. It may be holding informationfrom only a single patient identification domain, or may instead hold information from multiple
identification domains.
The latter case would apply if, for example, the Patient Demographics Supplier is grouped withan actor accepting ADT feeds from multiple patient registration systems in different domains.
Equivalently, the Patient Demographics Supplier Actor (or some other Actor with which it isgrouped) may manage a set of patient demographics sources, but is not expected to crossreference them (as a PIX Actor or an MPI system). A conceptual model embracing both multidomain concepts is shown in the following picture.

6090__________________________________________________________________________
284
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________

6095

Because of the definition of QBP^Q22, it must be determined which patient demographics
source a QBP^Q22 query is asking for, before any processing of the query request can proceed.
The identification of a need for such determination is the key difference between the IHE PDQ
transactions and the original HL7 QBP^Q22 definitions.
Three obvious alternatives exist for determining the patient demographics source.

6100

6105

6. The supplier advertises different application entities for each of the patient demographics
sources it manages. By addressing its query to a particular application entity in MSH-5Receiving Application, the consumer explicitly selects a source it is asking for.
7. The consumer is required to populate PID-3.4 in QPD-3 (Query Parameter) with thedomain name administered by the corresponding source (patient identifier domain) it isasking for.
8. The consumer includes in QPD-8 (What Domains Returned) the domain name of thecorresponding patient information source it is asking for.

6110

In selecting among these alternatives for the PDQ Profile, IHE-ITI took into account the need toconstrain the current HL7 QBP^Q22 definition while maintaining the integrity of the HL7
standard query and at the same time to model the IHE PDQ Profile properly to satisfy its realworld purpose. Based on these considerations, alternative 1 is the best selection, althoughalternative 2 is acceptable. Alternative 3 is not acceptable because it violates the definition of
QPD-8 that is stated in the HL7 Standard.

M.3:
6115

Implementing PDQ in a multi-domain architecture

There are three possible approaches in using PDQ in a multi-domain environment:__________________________________________________________________________
285
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________
1. Group the PDQ Patient Demographics Supplier Actor with a PIX Patient Identifier Crossreference Manager Actor. This allows the use of QPD-8 to request patient identifiers
from other domains to be returned in the demographics query response to the PDQ
Patient Demographics Consumer.
6120

6125

6130

6135

2. Group the PDQ Patient Demographics Supplier Actor with a PIX Patient Identifier Crossreference Consumer Actor. This allows the use of QPD-8 to request patient identifiers
from other domains to be returned in the demographics query response to the PDQ
Patient Demographics Consumer.
3. Group the PDQ Patient Demographics Consumer Actor with a PIX Patient Identifier
Cross-reference Consumer Actor. This obliges the Patient Demographics Consumer touse separate query requests to obtain patient demographics information (PDQ query) andpatient identifiers from the domains in which it is interested (PIX query).
Approach 3 is not recommended if Approach 1 or 2 is feasible. To require the Patient
Demographics Consumer to issue a separate PIX query increases complexity and might not be
permissible in the actual implementation architecture.
When Approach 1 or 2 is implemented, QPD-8 may be used by the Patient Demographics
Consumer to ask for patient identifiers from domains other than the domain administered by therequested demographics source, exactly as defined in the HL7 QBP^Q22 Conformance
Statement. If this use of QBP-8 is permitted by the implementation, it should be made clear thatthe patient demographics information returned comes from the patient demographics source thatis associated with MSH-5-Receiving Application.
In Approach 2, note that the PDQ Patient Demographics Supplier is grouped with the PIX
Patient Identifier Cross-reference Consumer. This combined actor will use a PIX Query tosatisfy the request of the client from additional patient identifiers and return them in PID-3.

6140__________________________________________________________________________
286
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-2): Transactions______________________________________________________________________________GLOSSARY
See IHE IT Infrastructure Technical Framework. Vol 1: Glossary.

__________________________________________________________________________
287
Rev. 2.0 Final Text
2005-08-11

Copyright © 2005: ACC/HIMSS/RSNA