Integrating the Healthcare Enterprise5

IT Infrastructure
Technical Framework
10

Volume 2b(ITI TF-2b)
Transactions Part B –Sections 3.29 – 3.51

15

Revision 9 – Final Text
August 31, 201220

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________CONTENTS
25

1

1.1
1.2
1.3
1.4
1.5
1.6
1.7

30
2

3

45

50

55

60

65

70

OVERVIEW OF THE TECHNICAL FRAMEWORK .................................................................................................. 5
OVERVIEW OF IT INFRASTRUCTURE TECHNICAL FRAMEWORK VOLUMES 2A, 2B, 2X, AND 3 .......................... 6
AUDIENCE ........................................................................................................................................................ 6
RELATIONSHIP TO STANDARDS ........................................................................................................................ 7
RELATIONSHIP TO REAL-WORLD ARCHITECTURES .......................................................................................... 7
COMMENTS ...................................................................................................................................................... 8
COPYRIGHT PERMISSION .................................................................................................................................. 8

CONVENTIONS ................................................................................................................................................ 9
2.1
2.2
2.3

35

40

INTRODUCTION.............................................................................................................................................. 5

THE GENERIC IHE TRANSACTION MODEL ....................................................................................................... 9
HL7 PROFILING CONVENTIONS...................................................................................................................... 10
USE OF CODED ENTITIES AND CODING SCHEMES .......................................................................................... 10

IHE TRANSACTIONS ................................................................................................................................... 11
3.29 INTENTIONALLY LEFT BLANK ......................................................................................................................... 11
3.30
PATIENT IDENTITY MANAGEMENT ............................................................................................................ 11
3.30.1
Scope ............................................................................................................................................... 11
3.30.2
Use Case Roles ............................................................................................................................... 11
3.30.3
Referenced Standards ..................................................................................................................... 123.30.4
Message sets and options ................................................................................................................ 123.30.5
Common HL7 Message Segments ................................................................................................... 13
3.30.6
Interactions ..................................................................................................................................... 29
3.31
PATIENT ENCOUNTER MANAGEMENT ....................................................................................................... 37
3.31.1
Scope ............................................................................................................................................... 38
3.31.2
Use Case Roles ............................................................................................................................... 38
3.31.3
Referenced Standards ..................................................................................................................... 38
3.31.4
Definition of the concept “Movement” ........................................................................................... 38
3.31.5
Message sets and options ................................................................................................................ 39
3.31.6
Common HL7 Message Segments ................................................................................................... 46
3.31.7
Interactions ..................................................................................................................................... 47
3.32
DISTRIBUTE DOCUMENT SET ON MEDIA ................................................................................................... 84
3.32.1
Scope ............................................................................................................................................... 84
3.32.2
Use Case Roles ............................................................................................................................... 85
3.32.3 Referenced Standard ............................................................................................................................... 85
3.32.4 Interaction Diagram ............................................................................................................................... 85
3.33
INTENTIONALLY LEFT BLANK ................................................................................................................... 92
3.34 RETRIEVE FORM .............................................................................................................................................. 92
3.34.1 Scope ....................................................................................................................................................... 92
3.34.2 Use Case Roles ....................................................................................................................................... 93
3.34.3 Referenced Standards ............................................................................................................................. 93
3.34.4 Interaction Diagram ............................................................................................................................... 94
3.34.5 Protocol Requirements ............................................................................................................................ 97
3.35 SUBMIT FORM.................................................................................................................................................. 99
3.35.1 Scope ....................................................................................................................................................... 99
3.35.2 Use Case Roles .................................................................................................................................... 100
3.35.3 Referenced Standards ........................................................................................................................... 100
3.35.4 Interaction Diagram ............................................................................................................................ 101

Rev. 9.0 Final Text – 2012-08-31

2

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

75

80

85

90

95

100

105

110

115

120

3.36 ARCHIVE FORM ............................................................................................................................................. 101
3.36.1 Scope ..................................................................................................................................................... 102
3.36.2 Use Case Roles .................................................................................................................................... 102
3.36.3 Referenced Standards ........................................................................................................................... 102
3.36.4 Interaction Diagram ............................................................................................................................ 103
3.37 RETRIEVE CLARIFICATIONS ........................................................................................................................... 104
3.37.1 Scope ..................................................................................................................................................... 104
3.37.2 Use Case Roles .................................................................................................................................... 104
3.37.3 Referenced Standards ........................................................................................................................... 104
3.37.4 Interaction Diagram ............................................................................................................................ 105
3.37.5 Protocol Requirements .......................................................................................................................... 108
3 ............................................................................................................................................................................ 110.38 CROSS GATEWAY QUERY ................................................................................................................................ 110
3.38.1 Scope ..................................................................................................................................................... 110
3.38.2 Use Case Roles ..................................................................................................................................... 110
3.38.3 Referenced Standard ............................................................................................................................. 111
3.38.4 Interaction Diagram ............................................................................................................................. 111
3.38.5 Protocol Requirements .......................................................................................................................... 115
3.39 CROSS GATEWAY RETRIEVE.......................................................................................................................... 117
3.39.1 Scope ..................................................................................................................................................... 118
3.39.2 Use Case Roles ..................................................................................................................................... 118
3.39.3 Referenced Standard ............................................................................................................................. 118
3.39.4 Interaction Diagram ............................................................................................................................. 119
3.39.5 Protocol Requirements .......................................................................................................................... 120
3.40 PROVIDE X-USER ASSERTION ........................................................................................................................ 124
3.40.1
Scope ............................................................................................................................................. 124
3.40.2
Use Case Roles ............................................................................................................................. 125
3.40.3 Referenced Standards ........................................................................................................................... 125
3.40.4 Interaction Diagram ............................................................................................................................. 127
3.41
PROVIDE AND REGISTER DOCUMENT SET-B ............................................................................................ 130
3.41.1
Scope ............................................................................................................................................. 131
3.41.2
Use Case Roles ............................................................................................................................. 131
3.41.3 Referenced Standards ........................................................................................................................... 132
3.41.4 Interaction Diagrams ........................................................................................................................... 132
3.41.5 Protocol Requirements .......................................................................................................................... 136
3.41.6 Actor Requirements ............................................................................................................................... 141
3.41.7 Security Considerations ........................................................................................................................ 142
3.42
REGISTER DOCUMENT SET-B .................................................................................................................. 145
3.42.1 Scope ..................................................................................................................................................... 146
3.42.2 Use Case Roles ..................................................................................................................................... 146
3.42.3 Referenced Standards ........................................................................................................................... 147
3.42.4 Interaction Diagram ............................................................................................................................ 147
3.42.5 Protocol Requirements .......................................................................................................................... 149
3.42.6 Actor Requirements ............................................................................................................................... 152
3.42.7 Security Considerations ........................................................................................................................ 152
3.43
RETRIEVE DOCUMENT SET...................................................................................................................... 156
3.43.1 Scope ..................................................................................................................................................... 156
3.43.2 Use Case Roles .................................................................................................................................... 156
3.43.3 Referenced Standard ............................................................................................................................. 157
3.43.4 Interaction Diagram ............................................................................................................................ 157
3.43.5 Protocol Requirements .......................................................................................................................... 159
3.43.6 Security Considerations ........................................................................................................................ 166
3.44 PATIENT IDENTITY FEED HL7 V3 .................................................................................................................. 170
3.44.1 Scope ..................................................................................................................................................... 170

Rev. 9.0 Final Text – 2012-08-31

3

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
125

130

135

140

145

150

155

3.44.2 Use Case Roles ..................................................................................................................................... 170
3.44.3 Referenced Standards ........................................................................................................................... 171
3.44.4 Interaction Diagrams ............................................................................................................................ 171
3.44.5 Security Requirements........................................................................................................................... 191
3.45 PIXV3 QUERY ............................................................................................................................................... 195
3.45.1 Scope ..................................................................................................................................................... 195
3.45.2 Use Case Roles ..................................................................................................................................... 195
3.45.3 Referenced Standards ........................................................................................................................... 195
3.45.4 Interaction Diagrams ............................................................................................................................ 196
3.45.5 Security Requirements........................................................................................................................... 209
3.46 PIXV3 UPDATE NOTIFICATION ..................................................................................................................... 212
3.46.1 Scope ..................................................................................................................................................... 212
3.46.2 Use Case Roles ..................................................................................................................................... 212
3.46.3 Referenced Standards ........................................................................................................................... 213
3.46.4 Interaction Diagrams ............................................................................................................................ 213
3.46.5 Security Requirements........................................................................................................................... 220
3.47 PATIENT DEMOGRAPHICS QUERY HL7 V3 .................................................................................................... 223
3.47.1 Scope ..................................................................................................................................................... 223
3.47.2 Use Case Roles ..................................................................................................................................... 223
3.47.3 Referenced Standards ........................................................................................................................... 223
3.47.4 Interaction Diagrams ............................................................................................................................ 224
3.47.5 Security Requirements........................................................................................................................... 245
3.48
INTENTIONALLY LEFT BLANK ................................................................................................................. 249
3.49
CONVEY PRINTED REFERRAL REQUEST .................................................................................................. 249
3.50
REQUEST REFERRAL ............................................................................................................................... 249
3.51 MULTI-PATIENT STORED QUERY ................................................................................................................... 249
3.51.1 Scope ..................................................................................................................................................... 249
3.51.2 Use Case Roles ..................................................................................................................................... 249
3.51.3 Referenced Standard ............................................................................................................................. 249
3.51.4 Interaction Diagram ............................................................................................................................. 250
3.51.5 Security Considerations ........................................................................................................................ 255

Rev. 9.0 Final Text – 2012-08-31

4

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1 Introduction
160

165

170

175

180

185

190

195

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 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 alarge coalition of organizations including the European Association of Radiology (EAR) andEuropean Congress of Radiologists (ECR), the Coordination Committee of the Radiological andElectromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS
Association, Groupement pour la Modernisation du Systè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 sponsoredby the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, andWelfare; and MEDIS-DC; cooperating organizations include the Japan Industries Association ofRadiological 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 acrossdisciplinary 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 aperiod of public review, and maintained regularly through the identification and correction oferrata. The current version, Rev. 9.0 for Final Text, specifies the IHE transactions defined andimplemented as of August 2012. The latest version of the document is always available via theInternet at http://www.ihe.net/Technical_Framework.
Rev. 9.0 Final Text – 2012-08-31

5

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

200

205

210

215

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. Volume 1 (ITI TF-1) provides a high-level view of IHE functionality, showing thetransactions organized into functional units called integration profiles that highlight theircapacity to address specific IT Infrastructure requirements.
Volumes 2a, 2b, and 2x of the IT Infrastructure Technical Framework provides detailed technicaldescriptions of each IHE transaction used in the IT Infrastructure Integration Profiles. Volume 3
contains content specification and specifications used by multiple transactions. These volumes
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. For example, the following
IHE Technical Framework(s) are some of those which 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 ITI TF-2a: 1.6.3.

1.2 Overview of IT Infrastructure Technical Framework Volumes 2a,2b, 2x, and 3
220

225

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. Section 3 is divided into two parts:• Volume 2a: Sections 3.1 - 3.28 corresponding to transactions [ITI-1] through [ITI-28].
• Volume 2b: Sections 3.29 - 3.51corresponding to transactions [ITI-29] through [ITI-51].
Volume 2x contains all appendices providing technical details associated with the transactions.
Volume 3, Section 4 contains specifications that are used by multiple transactions.

230

Volume 3, Section 5 contains Content Specifications.

1.3 Audience
The intended audience of this document is:
IT departments of healthcare institutions

Rev. 9.0 Final Text – 2012-08-31

6

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

235

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
240

245

250

255

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.
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.
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 ITI TF-2x:
Appendix C for the format of IHE Integration Statements.

1.5 Relationship to Real-world Architectures
260

265

270

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, norshould the framework itself be taken to comprehensively describe the architecture of a healthcare
information system.
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

Rev. 9.0 Final Text – 2012-08-31

7

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

275

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

IHE International welcomes comments on this document and the IHE initiative. They can besubmitted using the Web-based comment form at www.ihe.net/iti/iticomments.cfm or by sending
an email to the co-chairs and secretary of the IT Infrastructure domain committees at iti@ihe.net.
280

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.

Rev. 9.0 Final Text – 2012-08-31

8

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2285

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
290

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

295

300

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:Rev. 9.0 Final Text – 2012-08-31

9

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor

Actor

Actor

MSG1
MSG2
MSG3

305

310

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 thattrigger the message, its semantics, and the actions that the message triggers in thereceiver.

2.2 HL7 Profiling Conventions
See ITI TF-2x: Appendix C for the HL7 profiling conventions as well as the networking
implementation guidelines.
315

2.3 Use of Coded Entities and Coding Schemes

320

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.

Rev. 9.0 Final Text – 2012-08-31

10

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

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.

325

3.29 Intentionally Left Blank
3.30 Patient Identity Management

330

This section corresponds to Transaction ITI-30, “Patient Identity Management” of the IHE IT
Infrastructure Technical Framework. Transaction ITI-30 is used by the actors Patient
Demographics Supplier and Patient Demographics Consumer.
3.30.1 Scope
This transaction transmits patient demographics in a patient identification domain (i.e., patient
identifiers assigned by the same assigning authority).

335

The term “patient demographics” is intended to convey the patient identification and full identityand also information on persons related to this patient, such as primary caregiver, family doctor,
guarantor, next of kin.
The transaction contains events for creating, updating, merging, linking and unlinking patients.
It enables the sending system to qualify the reliability of a patient identity, and the type ofidentity used (official name, alias for VIP, unknown patient).

340

The transaction can be used in acute care settings for both inpatients (i.e., those who are assigned
a bed at the facility) and outpatients (i.e., those who are not assigned a bed at the facility).
The transaction can also be used in a pure ambulatory environment.
3.30.2 Use Case Roles

Patient
Demographics
Supplier
Patient
Identity
Source345

Patient
Demographics
Consumer

Patient Identitifier
Cross-ReferenceManager

Patient Identity
Management

Actor: Patient Demographics SupplierRev. 9.0 Final Text – 2012-08-31

11

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Role: Adds and modifies patient demographics.
Actor: Patient Demographics Consumer
Role: Receives patient demographics.
Actor: Patient Identity Source
350

Role: Adds and modifies patient demographics.
Actor: Patient Identifier Cross-Reference Manager
Role: Receives patient demographics.
3.30.3 Referenced Standards
HL7 2.5 Chapters 2, 3, 6, 15355

3.30.4 Message sets and options
Transaction ITI-30 supports two options, “Merge” and “Link/Unlink”, in order to accommodate
the various methods used by healthcare organizations to reconcile duplicated identities.

360

Any Patient Demographics Supplier or Patient Demographics Consumer actor SHALL support at
least one of the two options “Merge” and “Link/Unlink” or both, according to the IHE national
extensions of this transaction. Any implementation framework will mandate both actors to
support the same option. See 3.30.4.1 and 3.30.4.2.
Patient Identity Source and Patient Identity Cross-Reference Manager actors may support thePediatric Demographics option. See 3.30.4.3.
3.30.4.1 Required message subset with option “Merge”

365
Trigger

Message Static definition

Create new patient

Event

A28

ADT^A28^ADT_A05

Update patient information

A31

ADT^A31^ADT_A05

Change Patient Identifier List

A47

ADT^A47^ADT_A30

Merge two patients

A40

ADT^A40^ADT_A39

3.30.4.2 Required message subset with option “Link/Unlink”
Event

Trigger

Message Static definition

Create new patient

A28

ADT^A28^ADT_A05

Update patient information

A31

ADT^A31^ADT_A05

Change Patient Identifier List

A47

ADT^A47^ADT_A30

Link Patient Information

A24

ADT^A24^ADT_A24

Unlink Patient Information

A37

ADT^A37^ADT_A37

Rev. 9.0 Final Text – 2012-08-31

12

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.30.4.3 Optionality of Pediatric Demographics Fields
370

375

380

The Pediatric Demographics option does not require Patient Identity Source Actors to include
any attributes not already required by the corresponding HL7 message (as is described in thefollowing sections). This minimal set of requirements enables inclusion of the largest range ofPatient Identity Source Actor systems.
The Pediatric Demographics option does place additional requirements on the Patient Identifier
Cross-reference Manager Actor, requiring them to accept and consider in matching* a set of HL7
attributes beyond what is required by standard PIX. See Table 3.30.4.3-1 for a description ofthese additional requirements. For example, we would expect that two patients with all furnisheddata elements identical except the First Name (e.g., “Maria” vs. “Marina”), and consecutive Birth
Order values would not be automatically linked or merged by the Patient Identifier CrossReference Manager.
3.30.5 Common HL7 Message Segments
This section describes the common HL7 message segments used in Transaction 30.

385

Each table represents a segment. Fields for which a precise usage description is needed,
particularly those having usage C (conditional), are commented on below the table. The optional
fields are usually not commented on.
3.30.5.1 MSH - Message Header Segment
Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)

390

This segment defines the intent, supplier, destination, and some specifics of the syntax of themessage. It also uniquely identifies the message itself and dates its production.

Rev. 9.0 Final Text – 2012-08-31

13

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Table 3.30-1: MSH - Message Header
SEQ

LE
N

DT

Usage

Card.

TBL
#

1

1

ST

R

[1..1]

00001

Field Separator

2

4

ST

R

[1..1]

00002

Encoding Characters

3

227

HD

R

[1..1]

00003

Sending Application

4

227

HD

R

[1..1]

00004

Sending Facility

5

227

HD

R

[1..1]

00005

Receiving Application

6

227

HD

R

[1..1]

00006

Receiving Facility

7

26

TS

R

[1..1]

00007

Date/Time of Message

8

40

ST

X

[0..0]

00008

Security

9

15

MSG

R

[1..1]

00009

Message Type

10

20

ST

R

[1..1]

00010

Message Control Id

11

3

PT

R

[1..1]

00011

Processing Id

12

60

VID

R

[1..1]

00012

Version ID

13

15

NM

O

[0..1]

00013

Sequence Number

14

180

ST

X

[0..0]

00014

Continuation Pointer

15

2

ID

X

[0..0]

0155

00015

Accept Acknowledgement Type

16

2

ID

X

[0..0]

0155

00016

Application Acknowledgement Type

17

3

ID

RE

[1..1]

0399

00017

Country Code

18

16

ID

C

[0..1]

0211

00692

Character Set

19

250

CE

RE

[0..1]

00693

Principal Language of Message

20

20

ID

X

[0..0]

01317

Alternate Character Set Handling Scheme

21

427

EI

RE

[0..*]

01598

Message Profile Identifier

0356

ITEM#

Element name395

MSH-1 Field Separator, required: This Technical Framework requires that applications support
as the recommended value specified in the HL7 standard, which is | (ASCII 124). See volume
2x: Appendix C.

400

MSH-2 Encoding Characters, required: This field contains the four characters in the following
order: the component separator, repetition separator, escape character, and subcomponent
separator. This Technical Framework requires that applications support the recommended values
for encoding characters as specified in the HL7 standard. The values are ^~\& (ASCII 94, 126,
92, and 38, respectively). See volume 2x: Appendix C.
MSH-3 Sending Application (HD) and MSH-5 Receiving Application (HD), required. See
the constrainable profile definition of data type HD.
MSH-4 Sending Facility (HD) and MSH-6 Receiving Facility (HD), required. See theconstrainable profile definition of data type HD.

405

MSH-9 Message Type (MSG), required:
Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>Rev. 9.0 Final Text – 2012-08-31

14

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Definition: This field contains the message type, trigger event, and the message structure ID forthe message. All three components are required.
MSH-10 Message Control Id (ST), required:
410

Definition: This field contains a number or other identifier that uniquely identifies the message
in the context of exchange between trading partners. Each message should be given a unique
identifier by the sending system. The receiving system will echo this ID back to the sending
system in the Message Acknowledgment segment (MSA). The combination of this identifier andthe name of the sending application (MSH-3) should be unique across the healthcare enterprise.

415

MSH-12 Version ID (VID), required:
Components: <Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version
ID (CE)>
Definition: This field is matched by the receiving system to its own version to be sure themessage will be interpreted correctly.

420

The first component SHALL be populated with the value "2.5" representing HL7 Version 2.5.
MSH-15 Accept Acknowledgment Type (ID), not supported.
MSH-16 Application Acknowledgment Type (ID), not supported.
MSH-17 Country Code (ID), required if available.

425

Definition: This field contains the country of origin for the message. The values to be used arethose of ISO 3166, using the 3-character alphabetic form. Refer to HL7 Table 0399 - Countrycode.
Examples of valid values:
JPN = Japan, USA = United States, GBR = United Kingdom, ITA = Italy, FRA = France, NLD =Netherlands.

430

MSH-18 Character Set (ID), conditional.
Definition: This field contains the character set for the entire message. Refer to HL7 table 0211
- Alternate character sets for valid values.
Examples of valid values:
ASCII: The printable 7-bit ASCII character set.

435

440

8859/1: The printable characters from the ISO 8859/1 Character set used by Western Europe.
This character set can still be used, but 8859/15 should be used by preference. This character set
is the forward-compatible version of 8859/1 and includes new characters such as the Euro
currency symbol.
ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X 02081990).
UNICODE UTF-8: UCS Transformation Format, 8-bit form.

Rev. 9.0 Final Text – 2012-08-31

15

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

445

Condition predicate: This field shall only be valued if the message uses a character set otherthan the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only
one occurrence (i.e., one character set). The character set specified in this field is used for theencoding of all of the characters within the message.
MSH-19 Principal Language of Message (CE), required if available. Coded from ISO 639.
Examples: DE = German, EN = English, ES=Spanish, JA = Japanese, FR = French, NL = Dutch,
IT = Italian450

MSH-20 Alternate Character Set Handling Scheme (ID), not supported: Character set
switching is not allowed here.
MSH-21 Message Profile Identifier (EI), required if available.
This field shall be valued in the messages for which a Message Profile has been officiallyregistered with HL7, and is recommended to be valued for all messages in accordance with IHE
Technical Framework transactions. See volume 2x: Appendix C.

455

3.30.5.2 EVN – Event Type Segment
Standard Reference: HL7 Version 2.5, Chapter 3, section 3.4.1
This segment is used to provide generic properties of the trigger event.
Table 3.30-2: EVN – Event Type segment

460

SEQ

LEN

DT

Usage

1

3

ID

X

[0..0]

Card.

TBL#

ITEM#

0003

00099

Event Type Code

2

26

TS

R

3

26

TS

4

3

5

250

6
7

Element name[1..1]

00100

Recorded Date TimeC

[0..1]

00101

Date/Time Planned Event

IS

O[0..1]

0062

00102

Event Reason Code

XCN

O

[0..*]

0188

00103

Operator ID

26

TS

C

[0..1]

01278

Event Occurred

241

HD

RE

[0..1]

01534

Event Facility

EVN-1 Event Type Code (ID): Not supported (deprecated in HL7 2.5). The Event Type Code isgiven in MSH-9 of segment MSH.
EVN-2 Recorded Date Time (TS): Required. Date/time when the event was recorded.
EVN-3 Date/Time Planned Event (TS): Conditional. Date/time when the event was planned.

465

470

Condition predicate:• This field shall be populated in events “Pending Transfer” (A15) and “Cancel Pending
Transfer” (A26), which are supported by transaction ITI-31.
• The update of a pending transfer uses message A08 and leaves this field empty. The updateof the planned date/time of the transfer is only possible through the ZBE segment in message
Z99, when using the option “Historic Movement Management” of transaction ITI-31.
• Other planned events of transaction ITI-31, such as “Pending Admit”, “Pending Discharge”
and the cancels thereof, use a specific field of segment PV2 to give the date/time of theRev. 9.0 Final Text – 2012-08-31

16

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
planned event. For consistency of use, IHE recommends that the content of the specific fieldof PV2 be also copied to EVN-3.
National extensions of this transaction may extend the condition above.
475

480

EVN-6 Event Occurred (TS): Conditional. This field contains the date/time that the event reallyoccurred.
Condition predicate:• This field shall not be populated in messages communicating pending events and theircancellations.
• In messages communicating effective events (inserts and updates), this field shall be
populated with the real date/time of the notified event.
• In messages communicating cancellations, this field shall be populated with the date/timethat was sent in the message that originally communicated the event being cancelled.
EVN-7 Event Facility (HD): Required if known to the sender. This field identifies the actual
facility where the event occurred as distinct from the sending facility (MSH-4).

485

3.30.5.3 PID - Patient Identification segment
Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.2)
The PID segment is used by all applications as the primary means of communicating patient
identification information. This segment contains permanent patient identifying anddemographic information that, for the most part, is not likely to change frequently.

490

Table 3.30-3: PID - Patient Identification segment
SEQ

LEN

DT

Usage

1

4

SI

O

[0..1]

Card.

TBL#

00104

ITEM#

Set ID - PID

Element name

2

20

CX

X

[0..0]

00105

Patient ID

3

250

CX

R

[1..*]

00106

Patient Identifier List

4

20

CX

X

[0..0]

00107

Alternate Patient ID - PID

5

250

XPN

R

[1..*]

00108

Patient Name

6

250

XPN

O

[0..1]

00109

Mother’s Maiden Name

7

26

TS

CE

[0..1]

00110

Date/Time of Birth00111

Administrative Sex

00112

Patient Alias

00113

Race

00114

Patient Address

00115

County Code00116

Phone Number - Home

(Note 1)
(Note 1)
8

1

IS

CE

[1..1]

0001(Note 1)
9

250

XPN

X

[0..1]

10

250

CE

O

[0..1]

11

250

XAD

CE

[0..*]

0005(Note 1)
12

4

IS

X

[0..1]

13

250

XTN

O

[0..*]

0289(Note 1)

Rev. 9.0 Final Text – 2012-08-31

17

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
SEQ

LEN

DT

Usage

14

250

XTN

O

[0..*]

Card.

15

250

CE

O

[0..1]

16

250

CE

O

17

250

CE

18

250

CX

19

16

20
21

TBL#

ITEM#

Element name00117

Phone Number - Business

0296

00118

Primary Language[0..1]

0002

00119

Marital Status

O[0..1]

0006

00120

ReligionO[0..1]

00121

Patient Account Number

STX[0..1]

00122

SSN Number - Patient

25

DLN

X

[0..1]

00123

Driver's License Number - Patient

250

CX

O

[0..*]

00124

Mother's Identifier

22

250

CE

O

[0..1]

00125

Ethnic Group

23

250

ST

O

[0..1]

00126

Birth Place

24

1

ID

O

[0..1]

00127

Multiple Birth Indicator

00128

Birth Order

0189
0136

(Note 1)
25

2

NM

O

[0..1]

26

250

CE

O

[0..1]

0171

00129

Citizenship

27

250

CE

O

[0..1]

0172

00130

Veterans Military Status

28

250

CE

X

[0..0]

0212

29

26

TS

C

[0..1]

30

1

ID

C

[0..1]

31

1

ID

CE

[0..1]

0136

01535

Identity Unknown Indicator

32

20

IS

CE

[0..*]

0445

01536

Identity Reliability Code

33

26

TS

CE

[0..1]

01537

Last Update Date/Time[0..1]

01538

Last Update Facility

01539

Species Code(Note 1)

0136

00739

Nationality

00740

Patient Death Date and Time

00741

Patient Death Indicator(Note 1)
34

241

HD

O
(Note 1)

35

250

36

250

CE

37

80

ST

38

250

CE

39

250

CWE

Note 1:

495

CE

CE

[0..1]

0446

C[0..1]

0447

01540

Breed CodeO

[0..1]

01541

StrainO[0..2]

01542

Production Class CodeO

[0..*]

01840

Tribal CitizenshipIf the Pediatric Demographics Option is supported, this element in the table above shall be R2 for the Patient
Identifier Cross-Reference Manager.

In accord with the HL7 Version 2.5 usage of this segment, fields PID-2 (Patient ID), PID-4(Alternate Patient ID), PID-19 (SSN patient number) and PID-20 (Driver’s license number) aresuperseded by field PID-3, as shown below; field PID-28 (Nationality) is superseded by field
PID-26 (Citizenship).
PID-3 – Patient Identifier List (CX), required. This field contains a list of identifiers (one ormore) used by the healthcare facility to uniquely identify a patient.

Rev. 9.0 Final Text – 2012-08-31

18

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

500

As shown in the constrained profile definition of data type CX at the end of this supplement,
subfields CX-1 “ID number”, CX-4 “Assigning authority”, and CX-5 “Identifier Type Code” arerequired for each identifier.
This field may be populated with various identifiers assigned to the patient by various assigningauthorities.

505

The authorized values for subfield CX-5 “Identifier Type Code” are given in HL7 Table 0203
(HL7 Version 2.5, Chapter 2A, Section 2A.14.5).
Values commonly used for Identifier Type Code in the context of PID-3 are as follows:

510

515

520

BC

Bank card number. Assigning authority is the bank.

BR

Birth Certificate number. Assigning authority is the birth state or national
government that issues the Birth Certificate.

DL

Driver’s license number. Assigning authority is the state

NH

National Health Plan Identifier. Assigning authority at the national level.

PE

Living Subject Enterprise Number. Assigning authority is the enterprise.

PI

Patient Internal Identifier assigned by the healthcare organization.

PPN

Passport number.

PRC

Permanent Resident Card Number

SS

Social Security Number.

PID-5 – Patient Name (XPN), required. This field contains one or more names for the patient.
At least one name must be provided, with at least the first subfield “Family Name” valued. See
the constrained profile definition of data type XPN.
PID-6 – Mother’s Maiden Name (XPN), conditional:
Condition predicate:This field is required if known for the Pediatrics Demographic Option. It serves to help link
records when other demographic data and search criteria are not exactly the same.

525

PID-7 – Date/Time of Birth (TS), conditional.

530

Condition predicate:• This field is required if available (i.e., known to the sender) in the following messages:
Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in ITI-31), registration ofan outpatient (A04 in ITI-31), update patient demographics (A31 in ITI-30), update patient
demographics in the context of an encounter (A08 in ITI-31).
• In all other messages, it is optional.
• If the exact date of birth is not known, it can be truncated to the year of birth (e.g., 1954) orto the year and month of birth (e.g., 195411).

Rev. 9.0 Final Text – 2012-08-31

19

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PID-8 – Administrative Sex (IS), conditional.
535

540

Condition predicate:• This field is required if available in the following messages: Creation of a new patient (A28in ITI-30), inpatient admitted (A01 in ITI-31), registration of an outpatient (A04 in ITI-31),
update patient demographics (A31 in ITI-30).
• In all other messages, it is optional.
• The authorized values are these, taken from HL7 User-defined Table 0001:
User-defined Table 0001: Administrative Sex
Value

545

Description

F

Female

M

Male

O

Other

U

Unknown

A

AmbiguousN

Not applicable

Comment

PID-10 – Race (CE), optional: This field may be further constrained in national extensions of
the PAM profile. For instance, it will be required if available (usage code RE) in the US
extension, but will not be supported (usage code X) in the French extension.
PID-11 – Patient Address (XAD), conditional:

550

Condition predicate:• This field is required if available (if known to the sender) in the following messages:
Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in ITI-31), registration ofan outpatient (A04 in ITI-31), update patient demographics (A31 in ITI-30).
• In all other messages, it is optional.
PID-13 – Home Phone Number (XTN), conditional.
Condition predicate:555This field is required if known for the Pediatrics Demographic Option. It serves to help locate
records when other demographic data and search criteria are not exactly the same.
PID-18 – Patient Account Number (CX): Optional.
HL7 Definition: This field contains the patient account number assigned by accounting to which
all charges, payments, etc., are recorded. It is used to identify the patient’s account.

560

Relationship to encounter: A patient account can span more than one enterprise encounter. At
least one of the fields PID-18 “Patient Account Number” or PV1-19 “Visit Number” shall bevalued in the messages of transaction ITI-31 that use the PV1 segment. Additional requirements

Rev. 9.0 Final Text – 2012-08-31

20

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
for the presence of value in these fields may be documented in national extensions of thistransaction.
565

PID-24 – Multiple Birth Indicator (ID), conditional.
Condition predicate:This field is required if known for the Pediatrics Demographic Option. It serves to help avoid
linking records for twins, which are often nearly identical.
PID-25 – Birth Order (NM), conditional.

570

Condition predicate:This field is required if known for the Pediatrics Demographic Option. It serves to help avoid
linking records for twins, which are often nearly identical.
PID-29 – Patient Death Date and Time (TS), conditional:

575

Condition predicate:• This field is required in the Patient Discharge message of transaction ITI-31, in the casewhen the encounter is terminated by the patient’s death. It provides the date/time of thepatient’s death.
• In all other messages, it is optional.
PID-30 – Patient Death Indicator (ID), conditional:

580

Condition predicate:• This field is required to be populated with value “Y” whenever PID-29 is populated.
PID-31 – Identity Unknown Indicator (ID), conditional:

585

Condition predicate:• This field is required if available (i.e., known to the sender) in the following messages:
Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in ITI-31), registration ofan outpatient (A04 in ITI-31), update patient demographics (A31 in ITI-30) , update patient
demographics in the context of an encounter (A08 in ITI-31).
• In all other messages, it is optional.
The possible values are “Y”, and “N” which is the default.

590

The value “Y” means that the patient identity is unknown. In this case the field PID-3 shallcontain one single patient identifier, which is a temporary identifier, and the field PID-32 willcontain the value “AL” indicating that the patient name is an alias.
PID-32 – Identity Reliability Code (IS), conditional:

595

Condition predicate:• This field is required if available (i.e., known to the sender) in the following messages:
Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in ITI-31), registration ofan outpatient (A04 in ITI-31), update patient demographics (A31 in ITI-30) , update patient
demographics in the context of an encounter (A08 in ITI-31).

Rev. 9.0 Final Text – 2012-08-31

21

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________•
600

In all other messages, it is optional.

The field is repeatable. The possible values are taken from HL7 user-defined Table 0445:
User-defined Table 0445: Identity Reliability Code
Value

Description

Comment (added by IHE for this profile)

US

Unknown/Default Social Security
NumberUD

Unknown/Default Date of BirthUA

Unknown/Default Address

AL

Patient/Person Name is an Alias

Used in case of an unidentified patient (e.g., trauma
case)

PID-33 – Last Update Date/Time (TS), conditional:
605

610

Condition predicate:• This field is required if available (i.e., known to the sender) in the following messages:
Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in ITI-31), registration ofan outpatient (A04 in ITI-31), update patient demographics (A31 in ITI-30), update patient
demographics in the context of an encounter (A08 in ITI-31).
• In the cases of messages A08 and A31, the content of this field is equal to the value in EVN6-event occurred.
Note:

This field is required if known for the Pediatrics Demographic option. The condition predicate above satisfies
this requirement. It serves to help avoid linking records for twins, which are often nearly identical. It is used inconjunction with PID-34.

PID-34 – Last Update Facility (HD), conditional.
615

Condition predicate:This field is required if known for the Pediatrics Demographic option. It serves to help avoid
linking records for twins, whose records are often nearly identical, when used in conjunction
with PID-33.

620

PID-35 – Species Code (CE) and PID-36 – Breed Code (CE), conditional:

625

Condition predicate:• Required if known to the sender, when the patient is a non-human living subject, in thefollowing messages: Creation of a new patient (A28 in ITI-30), inpatient admitted (A01 in
ITI-31), registration of an outpatient (A04 in ITI-31), update patient demographics (A31 in
ITI-30), update patient demographics in the context of an encounter (A08 in ITI-31).
3.30.5.4 PV1 - Patient Visit segment
Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.3)

630

The PV1 segment is used by Registration/Patient Administration applications to communicate
information on an account or visit-specific basis.
Rev. 9.0 Final Text – 2012-08-31

22

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Table 3.30-4: PV1 - Patient Visit segment
SEQ

LEN

DT

Usage

Card.

TBL#

1

4

SI

O

[0..1]

2

1

IS

R

[1..1]

3

80

PL

C

[0..1]

4

2

IS

O

[0..1]

5

250

CX

O

[0..1]

6

80

PL

C

[0..1]

7

250

XC
N

O

[0..*]

0010

8

250

XC
N

O

[0..*]

9

250

XC
N

X

10

3

IS

11

80

12
13

ITEM#

ELEMENT NAME

00131

Set ID - PV1

00132

Patient Class

00133

Assigned Patient Location

00134

Admission Type

00135

Preadmit Number

00136

Prior Patient Location

00137

Attending Doctor

0010

00138

Referring Doctor[0..0]

0010

00139

Consulting Doctor

O[0..1]

0069

00140

Hospital Service

PLC[0..1]

00141

Temporary Location

2

IS

O

[0..1]

0087

00142

Preadmit Test Indicator

2

IS

O

[0..1]

0092

00143

Re-admission Indicator

14

6

IS

O

[0..1]

0023

00144

Admit Supplier

15

2

IS

O

[0..*]

0009

00145

Ambulatory Status

16

2

IS

O

[0..1]

0099

00146

VIP Indicator

17

250

XC
N

O

[0..*]

0010

00147

Admitting Doctor

18

2

IS

O

[0..1]

0018

19

250

CX

O

[0..1]

20

50

FC

O

[0..*]

21

2

IS

O

22

2

IS

O

23

2

IS

24

2

IS

25

8

DT

O

[0..*]

00155

Contract Effective Date

26

12

NM

O

[0..*]

00156

Contract Amount

27

3

NM

O

[0..*]

00157

Contract Period

28

2

IS

O

[0..1]

0073

00158

Interest Code

29

4

IS

O

[0..1]

0110

00159

Transfer to Bad Debt Code

30

8

DT

O

[0..1]

00160

Transfer to Bad Debt Date

31

10

IS

O

[0..1]

00161

Bad Debt Agency Code

32

12

NM

O

[0..1]

00162

Bad Debt Transfer Amount

33

12

NM

O

[0..1]

00163

Bad Debt Recovery Amount

34

1

IS

O

[0..1]

00164

Delete Account Indicator

35

8

DT

O

[0..1]

00165

Delete Account Date

0004
0007

00148

Patient Type

00149

Visit Number

0064

00150

Financial Class[0..1]

0032

00151

Charge Price Indicator[0..1]

0045

00152

Courtesy CodeO

[0..1]

0046

00153

Credit RatingO[0..*]

0044

00154

Contract CodeRev. 9.0 Final Text – 2012-08-31

23

0021

0111

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

635

SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

36

3

IS

O

[0..1]

0112

00166

Discharge Disposition

ELEMENT NAME

37

47

DL
D

O

[0..1]

0113

00167

Discharged to Location

38

250

CE

O

[0..1]

0114

00168

Diet Type

39

2

IS

O

[0..1]

0115

00169

Servicing Facility

40

1

IS

X

[0..1]

0116

00170

Bed Status

41

2

IS

O

[0..1]

0117

00171

Account Status

42

80

PL

C

[0..1]

00172

Pending Location

43

80

PL

O

[0..1]

00173

Prior Temporary Location

44

26

TS

RE

[0..1]

00174

Admit Date/Time

45

26

TS

RE

[0..1]

00175

Discharge Date/Time

46

12

NM

O

[0..1]

00176

Current Patient Balance

47

12

NM

O

[0..1]

00177

Total Charges

48

12

NM

O

[0..1]

00178

Total Adjustments

49

12

NM

O

[0..1]

00179

Total Payments

50

250

CX

O

[0..1]

0203

00180

Alternate Visit ID

51

1

IS

O

[0..1]

0326

01226

Visit Indicator

52

250

XC
N

X

[0..*]

0010

01274

Other Healthcare Provider

General conditions of use:
• All messages of transaction ITI-30 that use this segment, actually use a pseudo-PV1, which is
empty. The only field populated is PV1-2 “Patient Class” values “N” (Not Applicable).
• The condition predicates described below only apply to the use of this segment in the context
of transaction ITI-31.
PV1-2 – Patient Class (IS), required:

640

Definition: This field is used by systems to categorize patients by site. It does not have aconsistent industry-wide definition. It is subject to site-specific variations. Refer to Userdefined Table 0004 - Patient Class for suggested values.
User-defined Table 0004: Patient Class
Value

Description

E

Emergency

I

InpatientO

OutpatientP

Preadmit

R

Recurring patient

B

Obstetrics

C

Commercial AccountRev. 9.0 Final Text – 2012-08-31

24

Comment

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Value

DescriptionN

Not ApplicableU

Unknown

Comment645
National extensions of the PAM profile may add further values to this table.
Messages of transaction ITI-31 may use any of the above values. The four first values (“E”
Emergency, “I” Inpatient, “O” Outpatient, “P” Preadmit) are in common use in most countries.
650

655

Conditions of use:
• Transaction ITI-30 uses only the value “N” (Not Applicable) in all messages that contain thePV1 segment.
• In transaction ITI-31• Change to inpatient (A06) uses value I or another value representing an inpatient.
• Change to outpatient (A07) uses value O or another value representing an outpatient(i.e., not assigned to an inpatient bed).
PV1-3 – Assigned Patient Location (PL), conditional:
Condition predicate:• This field is required in the Transfer (A02) and Cancel Transfer (A12) messages.
• In all other messages of transaction ITI-31, it is required if known to the sender.

660

PV1-6 – Prior Patient Location (PL), conditional:
Condition predicate:• This field is required in the Transfer (A02)• In all other messages of transaction ITI-31, it is optional.

665

PV1-7 – Attending Doctor (XCN), optional. It is recommended that when this field ispopulated, the segment PV1/PV2 be followed by a ROL segment containing the details on therole assumed by the attending doctor.
PV1-8 – Referring Doctor (XCN), optional. It is recommended that when this field ispopulated, the segment PV1/PV2 be followed by a ROL segment containing the details on therole assumed by the referring doctor.

670

PV1-9 – Consulting Doctor (XCN), not supported (deprecated by HL7). The consulting
doctor(s) are entirely described in the appropriate ROL segments following the PV1/PV2.
PV1-11 – Temporary Location (PL), conditional:
Condition predicate: This field is used by the option “Temporary Patient Transfers Tracking” oftransaction ITI-31 (messages A09, A10, A32, A33).

675

PV1-19 – Visit Number (CX), Optional. This fields contains the unique identifier assigned tothe encounter. At least one of the fields PID-18 “Patient Account Number” or PV1-19 “Visit
Number” shall be valued in the messages of transaction ITI-31 that use the PV1 segment.

Rev. 9.0 Final Text – 2012-08-31

25

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Additional requirements for the presence of values in these fields may be documented in national
extensions of this transaction.
PV1-42 – Pending Location (PL), conditional.

680

Condition predicate:• This field is required in the Pending Transfer (A15) and Cancel Pending Transfer (A26)
messages.
• In all other messages of transaction ITI-31, it is optional.
PV1-44 – Admit Date / Time (TS), required if available. This field contains the date/time of the
beginning of the encounter.

685

PV1-45 – Discharge Date / Time (TS), required if available. This field contains the date/time ofthe discharge (end of the encounter).
3.30.5.5 MRG – Merge segment
690

Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.9)
This segment contains the supplier patient identifiers list to be merged.
Table 3.30-5: MRG - Merge segment
SEQ

LEN

DT

Usage

Card.

1

250

CX

R

2

250

CX

3

250

4

TBL#

ITEM#

Element name[1..*]

00211

Prior Patient Identifier List

X

[0..0]

00212

Prior Alternate Patient ID

CXO[0..1]

00213

Prior Patient AccountNumber

250

CX

X[0..0]

00214

Prior Patient ID

5

250

CX

X

[0..0]

01279

Prior Visit Number

6

250

CX

X

[0..0]

01280

Prior Alternate Visit ID

7

250

XPN

O

[0..*]

01281

Prior Patient Name

Each of the patient identifiers appearing in the MRG-1 is to be merged with a target patient
identifier of the same type in the PID-3.
695

The type of identifier is a code given by the 5th component of the CX data type. See thecommonly used identifier types in the description of the PID segment above. See also thedefinition of data type CX in the “Common Data Types” section.
3.30.5.6 ROL – Role segment
Standard Reference: HL7 Version 2.5, Chapter 15 (Section 15.4.7)

700

The ROL segment communicates information on persons related to the patient.
Table 3.30-6: ROL Segment
SEQ

LEN

DT

Usage

Card.

1

60

EI

C

[0..1]

Rev. 9.0 Final Text – 2012-08-31

TBL
#

ITEM
#
01206

26

ELEMENT NAME
Role Instance ID

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
SEQ

LEN

DT

Usage

Card.

TBL
#

ITEM
#

2

2

ID

R

[1..1]

0287

00816

Action Code

3

250

CE

R

[1..1]

0443

01197

Role-ROL

4

250

XC
N

R

[1..*]

01198

Role Person

5

26

TS

O

[0..1]

01199

Role Begin Date/Time

6

26

TS

O

[0..1]

01200

Role End Date/Time

7

250

CE

O

[0..1]

01201

Role Duration

8

250

CE

O

[0..1]

01205

Role Action Reason

9

250

CE

O

[0..*]

01510

Provider Type

10

250

CE

O

[0..1]

01461

Organization Unit Type

11

250

XA
D

O

[0..*]

00679

Office/Home Address/Birthplace

12

250

XT
N

O

[0..*]

00678

Phone

0406

ELEMENT NAME

ROL-1 – Role Instance ID (EI), optional. This field is in fact optional in the context of ADT
messages.
705

ROL-2 – Action Code (ID), required
ROL-3 – Role-ROL (CE) , required. This field defines the functional involvement of theperson. Values are given in User-defined table 0443:
User-defined Table 0443: Provider role
Value

710

Description

Used withAD

AdmittingPV1-17 Admitting doctor

AT

AttendingPV1-7 Attending doctor

CP

Consulting Provider

FHCP

Family Health Care Professional

PP

Primary Care Provider

RP

Referring Provider

RT

Referred to Provider

PV1-8 Referring doctor

ROL-4 – Role Person (XCN), required. Identification of the person playing the role.
3.30.5.7 OBX – Observation/Result segment
Standard Reference: HL7 Version 2.5, Chapter 7 (Section 7.4.2)

715

In transactions ITI-30 and ITI-31, the OBX segment is primarily used to convey patient heightand patient weight. For this reason, this segment is described in this section, although it always
appears as optional in transactions ITI-30 and ITI-31.

Rev. 9.0 Final Text – 2012-08-31

27

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.30-7: OBX Segment
SEQ

LEN

DT

Usage

Card.

1

4

SI

O

[0..1]

2

2

ID

R

[1..1]

3

250

CE

R

4

20

ST

5

99999

Varies

6

250

7
8
9

TBL#

ITEM#

Element name00569

Set ID – OBX

00570

Value Type

[1..1]

00571

Observation IdentifierO[0..1]

00572

Observation Sub-ID

R[1..1]

00573

Observation Value

CEO[0..1]

00574

Units

60

ST

O

[0..1]

00575

References Range

5

IS

O

[0..1]

00576

Abnormal Flags

5

NM

O

[0..1]

00577

Probability

10

2

ID

O

[0..1]

0080

00578

Nature of Abnormal Test

11

1

ID

R

[0..1]

0085

00579

Observation Result Status

12

26

TS

O

[0..1]

00580

Effective Date of Reference Range

13

20

ST

O

[0..1]

00581

User Defined Access Checks

14

26

TS

O

[0..1]

00582

Date/Time of the Observation

15

250

CE

O

[0..1]

00583

Producer's ID

16

250

XCN

O

[0..1]

00584

Responsible Observer

17

250

CE

O

[0..1]

00936

Observation Method

18

22

EI

O

[0..1]

01479

Equipment Instance Identifier

19

26

TS

O

[0..1]

01480

Date/Time of the Analysis

0125

0078

OBX-2 Value Type (ID), required.
This field contains the type of observation.
Example: “NM” for a numeric observation such as patient weight or patient height.
720

OBX-3 Observation Identifier (CE), required

725

The usage of LOINC® vocabulary is strongly recommended. Details of this free vocabulary canbe found at http://www.loinc.org. The first and third sub-fields, “Identifier” and “Name of
Coding System” are required in all transactions. The value of the “Name of Coding System” inthe case of LOINC is “LN”.
Example of the code used with the patient weight: 3142-7^BODY WEIGHT (STATED)^LN
OBX-5 Observation Value (Varies), required.
This field contains the value of the observation itself.
OBX-11 Observation Result Status (ID), required.

730

This field contains the status of the results. In messages of transactions ITI-30 and ITI-31, thisstatus is most commonly “F” (Final).
Example of use of the OBX segment to carry the patient weight and height:
OBX|1|NM|3142-7^BODY WEIGHT (STATED)^LN||62|kg|||||F

OBX|2|NM|8303-0^BODY HEIGHT^LN||1.70|m|||||F

Rev. 9.0 Final Text – 2012-08-31

28

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.30.5.8 AL1 – Patient Allergy Information segment
735

Standard Reference: HL7 Version 2.5, Chapter 3, Section 3.4.6
In transactions ITI-30 and ITI-31, the AL1 segment is used to inform the receiver of patientallergies. For this reason, this segment is described in this section, although it always appears as
optional in transactions ITI-30 and ITI-31.
Table 3.30-8: AL1 Segment

740

SEQ

LEN

DT

Usage

Card.

1

4

SI

R

[1..1]

2

250

CE

O

[0..1]

3

250

CE

R

[1..1]

4

250

CE

O

[0..1]

5

15

ST

O

6

8

DT

X

ITEM#

Element name00203

Set ID – AL1

00204

Allergen Type Code00205

Allergen Code/Mnemonic/Description

00206

Allergen Severity Code[0..*]

00207

Allergen Reaction Code[0..0]

00208

Identification Date

0127
0128

One or more AL1 segments may appear in the messages of transactions ITI-30 and ITI-31 if any
allergies have been identified for the patient at time of registration.
3.30.6745

TBL#

Interactions

All messages of this transaction shall be acknowledged by the ACK message as stated in ITI TF2x: Appendix C. For better readability, the acknowledgement messages are not shown on theinteraction diagrams of this transaction.

Rev. 9.0 Final Text – 2012-08-31

29

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.30.6.1 Interaction diagram
Patient
Demographics
SourcePatient
Demographics
Consumer

Create a newpatient

ADT^A28^ADT_A05

Update patient
information

ADT^A31^ADT_A05

Merge twopatients

ADT^A40^ADT_A39

Change patient
identifier list

ADT^A47^ADT_A30

Link patient
information

ADT^A24^ADT_A24

Unlink patient
information

ADT^A37^ADT_A37

Figure 3.30-1: Interactions of transaction ITI-30

750

3.30.6.2 Create New Patient - ADT^A28^ADT_A05
3.30.6.2.1

Trigger Event

This message is sent by a Patient Demographics Supplier to a Patient Demographics Consumer
to communicate the demographics of a new patient, as well as related information.
MSH-9 is valued ADT^A28^ADT_A05.
755

3.30.6.2.2

Message Static Definition
Table 3.30-9: Static definition of ADT^A28^ADT_A05

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

Rev. 9.0 Final Text – 2012-08-31

30

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Usage

Card.

HL7 chapter

ROL

Segment
Role

O[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

X

[0..0]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

3.30.6.2.3

760

Meaning

6

Comments on segment usage

The ROL segment following the PID/PD1 segments is used to communicate “person level”
providers having an ongoing relationship with the patient, such as “family health care provider”
and “primary care provider”.
The PV1 segment in this message is required in the HL7 message structure, but it is a pseudo
PV1 carrying the only required field PV1-2 “Patient Class” with the value “N” meaning “Notapplicable”. This message does not convey any visit information.
The PV2 segment is not supported here, for the same reason.

765

The ROL segment following the PV1/PV2 segments is not supported here, for the same reason.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
The ROL segment following the IN1/IN2/IN3 segments serves to communicate providers related
to a specific insurance carrier.

Rev. 9.0 Final Text – 2012-08-31

31

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
770

3.30.6.2.4

Expected actions

The receiver shall add this new patient to its database, and shall report the result of this operation(success / error) in an acknowledgment message returned to the sender.
3.30.6.3 Update patient information - ADT^A31^ADT_A05
3.30.6.3.1
775

Trigger Event

This message is sent by a Patient Demographics Supplier to a Patient Demographics Consumer
to update the demographics of an existing patient.
MSH-9 is valued ADT^A31^ADT_A05.
3.30.6.3.2

Message Static Definition
Table 3.30-10: Static definition of ADT^A31^ADT_A05

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

Rev. 9.0 Final Text – 2012-08-31

32

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

780

Usage

Card.

HL7 chapter

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

3.30.6.3.3

Meaning

Comments on segment usage

To accommodate the situation in which the receiver does not know the patient, this message ispopulated with complete up-to-date demographics for the patient.

785

The ROL segment following the PID/PD1 segments is used to communicate “person level”
providers having an ongoing relationship with the patient, such as “family health care provider”
and “primary care provider”.
The PV1 segment in this message is required in the HL7 message structure, but it is a pseudo
PV1 carrying the only required field PV1-2 “Patient Class” with the value “N” meaning “Notapplicable”. This message does not convey any visit information.
The PV2 segment is not supported here, for the same reason.

790

The ROL segment following the PV1/PV2 segments is not supported here, for the same reason.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
The ROL segment following the IN1/IN2/IN3 segments serves to communicate providers related
to a specific insurance carrier.

795

3.30.6.3.4

Expected actions

The receiver shall update the patient record in its database, and shall report the result of thisoperation (success / error) in an acknowledgment message returned to the sender. If the receiver
did not previously have a record for this patient, it shall insert this patient into its database.
3.30.6.4
800This message is to be supported with the “Merge” option of Transaction ITI-30.
3.30.6.4.1

805

Merge two patients - ADT^A40^ADT_A39

Trigger Event

The Patient Demographics Supplier notifies to a Patient Demographics Consumer, the merge ofrecords for a patient that was incorrectly filed under two different identifiers. This message isonly used to merge two patient identifiers of the same type, or two lists of patient identifiers. It is
not used to update other patient demographics information. The A31 trigger event should be used
for this purpose.
MSH-9 is valued ADT^A40^ADT_A39.

Rev. 9.0 Final Text – 2012-08-31

33

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.30.6.4.2

Message Static Definition

810

Table 3.30-11: Static definition of ADT^A40^ADT_A39
Usage

Card.

HL7 chapter

MSH

Segment

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2------ PATIENT beginR[1..1]

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3

PV1

Patient Visit

X[0..0]

3---

3.30.6.4.3

Comments on segment usage

This transaction makes unrepeatable the PATIENT segment group: The message cancommunicate only one merge operation for one patient.
815

The “incorrect supplier identifier” identified in the MRG segment (MRG-1 - Prior Patient
Identifier List) is to be merged with the required “correct target identifier” of the same ”identifier
type code” component identified in the PID segment (PID-3 - Patient Identifier List). The“incorrect supplier identifier” would then logically never be referenced in future transactions.
The PV1 segment is not supported by IHE in this message.
3.30.6.4.4

820

Expected actions

The receiver shall merge the two patients in its database, and shall report the result of thisoperation (success / error) in an acknowledgment message returned to the sender.
If the receiver does not recognize the target patient identifiers, it shall perform a Change Patient
Identifier List instead of a Merge. This situation is not an error.

825

If the receiver does not recognize the supplier patient identifiers to be merged, it shall take noaction. This situation is not an error.
If the receiver does not support the Merge option of this transaction, it shall application-reject themessage (see ITI TF-2x: C.2.3).
3.30.6.5 Change Patient Identifier List - ADT^A47^ADT_A30
3.30.6.5.1

830

Trigger Event

The Patient Demographics Supplier notifies the change of a patient identifier list for a patient.
That is, a single PID-3-patient identifier list value has been found to be incorrect and has beenchanged.

Rev. 9.0 Final Text – 2012-08-31

34

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This message is not used to update other patient demographics information. The A31 trigger
event should be used for this purpose.
835

MSH-9 is valued ADT^A47^ADT_A30.
3.30.6.5.2

Message Static Definition
Table 3.30-12: Static definition of ADT^A47^ADT_A30

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2------ PATIENT beginR[1..1]

PID

Patient IdentificationR[1..1]

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

33---

3.30.6.5.3
840

Comments on segment usage

The “incorrect supplier identifier” value is stored in the MRG segment (MRG-1-Prior Patient
Identifier List) and is to be changed to the “correct target patient ID” value stored in the PID
segment (PID-3–Patient Identifier List).
3.30.6.5.4

Expected actions

The receiver shall correct the identifier in its database, and shall report the result of this operation(success / error) in an acknowledgment message returned to the sender.
845

If the receiver already associates the target patient identifiers with another patient in its database,this is an error condition: A merge (A40) should have been sent instead of a change.
If the receiver does not recognize the supplier patient identifiers to be merged, no further action
is required and no error condition exists.
3.30.6.6 Link Patient Information List - ADT^A24^ADT_A24

850

This message is to be supported with the “Link/Unlink” option of Transaction ITI-30.
3.30.6.6.1

855

Trigger Event

The Patient Demographics Supplier notifies the link of one patient identifier list (the first PID
segment) to another one (the second PID segment). Linking two or more patients does not
require the actual merging of patient information; following a link event, the affected patient data
records should remain distinct.
This message is not used to update other patient demographics information. The A31 trigger
event should be used for that purpose.

Rev. 9.0 Final Text – 2012-08-31

35

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
MSH-9 is valued to ADT^A24^ADT_A24.
3.30.6.6.2

Message Static Definition

860

Table 3.30-13: Static definition of ADT^A24^ADT_A24
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

X[0..1]

3

PV1

Patient Visit

X[0..1]

3

DB1

Disability Information

X[0..1]

3

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

X[0..1]

3

PV1

Patient Visit

X[0..1]

3

DB1

Disability Information

X[0..1]

3

3.30.6.6.3

Comments on segment usage

The patient identifier list stored in the first PID segment (PID-3–Patient Identifier List) is to belinked with the patient identifier list stored in the second PID segment (PID-3–Patient Identifier
List).
865

Transaction ITI-30 restricts the use of this message to only the purpose of linking two patient
identifier lists. This is why segments PD1, PV1 and DB1 are not supported in this message.
3.30.6.6.4

870

Expected actions

The receiver links the identifier lists in its database, and reports the result of this operation(success / error) in an acknowledgment message returned to the sender. In case of success, eachpatient record persists with all its associated information (encounter, clinical, care, insurance,next of kin, etc.).
In case the receiver did not recognize one or both of the patient identifier lists, the linking is still
performed (the receiver will record the link without creating any missing patient record) and noerror condition exists.

875

If the receiver does not support the Link/Unlink option of this transaction, it shall applicationreject the message (see ITI TF-2x: C.2.3).
3.30.6.7 Unlink Patient Information List - ADT^A37^ADT_A37
3.30.6.7.1

880

Trigger Event

The Patient Demographics Supplier notifies the receiving system of the unlinking of one patient
identifier list (the first PID segment) from another one (the second PID segment).

Rev. 9.0 Final Text – 2012-08-31

36

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
MSH-9 is valued ADT^A37^ADT_A37.
3.30.6.7.2

Message Static Definition
Table 3.30-14: Static definition of ADT^A37^ADT_A37

Segment

885

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

X[0..1]

3

PV1

Patient Visit

X[0..1]

3

DB1

Disability Information

X[0..1]

3

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

X[0..1]

3

PV1

Patient Visit

X[0..1]

3

DB1

Disability Information

X[0..1]

3

3.30.6.7.3

Comments on segment usage

The patient identifier lists stored in the two PID segments (PID-3–Patient Identifier List) are to
be unlinked.
Transaction ITI-30 restricts the use of this message to only the purpose of unlinking two patient
identifier lists. This is why segments PD1, PV1 and DB1 are not supported in this message.
3.30.6.7.4

890

Expected actions

The receiver unlinks the identifier lists in its database, and reports the result of this operation(success / error) in an acknowledgment message returned to the sender.
In case of success the two patient records are unlinked, each of them keeping its own related
information (encounter, clinical, next of kin, insurance…).

895

In case the receiver did not recognize the link between these two patient identifier lists, no action
is performed and no error condition exists.
If the receiver does not support the Link/Unlink option of this transaction, it shall applicationreject the message (see ITI TF-2x: C.2.3).

3.31 Patient Encounter Management
900

This section corresponds to Transaction ITI-31 “Patient Encounter Management” of the IHE IT
Infrastructure Technical Framework. Transaction ITI-31 is used by the actors Patient Encounter
Supplier and Patient Encounter Consumer.

Rev. 9.0 Final Text – 2012-08-31

37

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.1 Scope

905

This transaction enables systems to share encounter information within acute care settings forboth inpatients (i.e., those who are assigned an inpatient bed at the facility) and outpatients (i.e.,
those who are not assigned an inpatient bed at the facility).
The transaction carries events for creating, updating, and canceling patient encounters as well as
the movements that take place within these encounters.

910

The capabilities of this transaction are organized into several optional subsets to address a wide
range of needs from the simplest one that only shares the basic encounter information to the mostsophisticated one that tracks all patient temporary moves in the healthcare facility.
3.31.2 Use Case Roles

Patient
Encounter Source

Patient
Encounter
Consumer

Patient Encounter
Management
Actor: Patient Encounter SupplierRole: Sends inserts, cancels and updates of patient encounters and movements.
915

Actor: Patient Encounter Consumer
Role: Receives patient encounters and movement messages, and takes the appropriate actions.
3.31.3 Referenced Standards
HL7 2.5 Chapters 2, 3, 6, 15
3.31.4 Definition of the concept “Movement”

920

925

As stated in Volume 1, a “Movement” is any change of the situation of the patient (location,
patient class, attending doctor, etc.) in the context of the encounter.
The concept of “Movement” is a superset of the concept of “Transfer”. Like a transfer, amovement is an event that can be planned (pending) and executed (effective). Errors detected in
the recording of these pending and effective events can later be corrected through cancellations
or updates, which are distinct events. Three actions are associated with Movements:• Insert: This action is the first recording of the Movement.
• Update: This action corrects some attributes of a Movement formerly inserted. This action ispossible only with the option “Historic Movement Management” of transaction ITI-30.

Rev. 9.0 Final Text – 2012-08-31

38

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

930

935

940

945

•

Cancel: This action cancels a Movement that was erroneously recorded, and requests thereceiver to delete this Movement from its database. Only the current Movement can becancelled.

In some acute care settings, both the billing process and care provision process require precise
knowledge of the movements of the inpatient during his or her stay in the hospital. Applications
acting as Patient Encounter Supplier or Patient Encounter Consumer, divide the period of theencounter into “sub-encounters” delimited by the Movements. Each of these “sub-encounters”
provides a specific context to record and invoice the acts produced within this period. However,
if applications on both ends manage sub-encounters, which are periods of time, the messages oftransaction ITI-31 communicate Movements as events. Hence, applications manage periods oftime, but the messages carry the discrete events that delimit these periods of time.
Illustration:
1.

Patient received at Emergency room by attending doctor U. (A04 / patient class E).

2.

Doctor U admits the patient (A06 / patient class = I), into location BB, referring him toattending Doctor X.

3.

The patient is moved to location GG (A02Transfer), keeping X for attending doctor.

4.

The patient is healed and leaves the hospital (A03: Discharge).

These 4 real world events are expressed with 5 trigger events / messages, two of which occur atthe same time (step 2). Here the encounter will be divided into 3 sub-encounters:
A04

A06

Emergency &attending
doctor U

A02
Location BB& attending
doctor X

A03
Location GG& attending
doctor X

3.31.5 Message sets and options
950

All messages of this transaction shall be acknowledged by the ACK message as described in ITI
TF-2x: Appendix C. For better readability, the acknowledgement messages are not shown on theinteraction diagrams of this transaction.
3.31.5.1 Basic subset
Table 3.31-1: Message basic subset for transaction ITI-31
Trigger / Action

Category of event

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

Rev. 9.0 Final Text – 2012-08-31

39

cancelA11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Trigger / Action

Category of event955

insertUpdate patient
information

A08

ADT^A08^ADT_A01

Merge patient identifier
list

A40

ADT^A40^ADT_A39

cancelThe basic subset of transaction ITI-31 is composed of the above events and related messages. A
system implementing either Patient Encounter Supplier or Patient Encounter Consumer, without
any further option, shall support these 7 trigger events and messages.
Patient Encounter
Supplier
Admit inpatient

Patient Encounter
Consumer
ADT^A01^ADT_A01

Discharge
patient

ADT^A03^ADT_A03

Registeroutpatient

ADT^A04^ADT_A04

Canceladmit/visit

ADT^A11^ADT_A09

Canceldischarge

ADT^A13^ADT_A01

Update patient
information

ADT^A08^ADT_A01

Merge patient
identifier lists

ADT^A40^ADT_A39

Figure 3.31-1: Interaction diagram for the basic subset

960

3.31.5.2 Inpatient/Outpatient Encounter Management Option
This option adds support for management of patient class (Outpatient, Emergency, Inpatient,Pre-admitted, etc.) and of patient location (point of care, room, bed, etc.).
The following is the required message set to support the “Inpatient/Outpatient Encounter
Management” option:

965

Rev. 9.0 Final Text – 2012-08-31

40

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Table 3.31-2: Message subset for inpatient/outpatient encounter management option
Trigger / Action

Category of event

970

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

Update patient
information

A08

ADT^A08^ADT_A01

Merge patient identifier
lists

A40

ADT^A40^ADT_A39

Pre-admit patient

A05

ADT^A05^ADT_A05

Change patient class to
inpatient

A06

ADT^A06^ADT_A06

Change patient class to
outpatient

A07

ADT^A07^ADT_A06

Transfer patient

A02

ADT^A02^ADT_A02

cancelA11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

A38

ADT^A38^ADT_A38

A12

ADT^A12^ADT_A12

A system implementing this option shall support these 13 trigger events and messages.
Figure 3.31-2 depicts the messages added by this option to the basic subset.
Patient Encounter
Supplier

Patient Encounter
ConsumerPre-admit
inpatient

ADT^A05^ADT_A05

Cancelpre-admit

ADT^A38^ADT_A38

Change toinpatient

ADT^A06^ADT_A06

Change tooutpatient

ADT^A07^ADT_A07

Transferpatient

ADT^A02^ADT_A02

Cancel patienttransfer

ADT^A12^ADT_A12

Figure 3.31-2: Additional interactions for “Inpatient/Outpatient Encounter Management”
optionRev. 9.0 Final Text – 2012-08-31

41

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
975

3.31.5.3 Pending Event Management Option
This option adds support for management of pending events. This option also requires the“Inpatient/Outpatient Encounter Management” option.
The following is the required message set to support the “Pending Event Management” option:

980

Table 3.31-3: Message subset for Pending Event Management option
Trigger / Action

Category of event

insertcancelAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

Update patient information

A08

ADT^A08^ADT_A01

A11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

A38

ADT^A38^ADT_A38

Merge patient identifier lists

A40

ADT^A40^ADT_A39

Pre-admit patient

A05

ADT^A05^ADT_A05

Change patient class to inpatient

A06

ADT^A06^ADT_A06

Change patient class to outpatient

A07

ADT^A07^ADT_A06

Transfer patient

A02

ADT^A02^ADT_A02

A12

ADT^A12^ADT_A12

Pending admit

A14

ADT^A14^ADT_A05

A27

ADT^A27^ADT_A21

Pending transfer

A15

ADT^A15^ADT_A15

A26

ADT^A26^ADT_A21

Pending discharge

A16

ADT^A16^ADT_A16

A25

ADT^A25^ADT_A21

A system implementing this option shall support these 19 trigger events and messages.

985

990

Rev. 9.0 Final Text – 2012-08-31

42

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
995

Figure 3.31-3 below depicts the messages added by this option to the basic subset and theInpatient/Outpatient Encounter Management option.
Patient Encounter
SourcePatient Encounter
Consumer

Pending admitof a inpatient

ADT^A14^ADT_A05

Cancelpending admit

ADT^A27^ADT_A21

Pendingtransfer

ADT^A15^ADT_A15

Cancel pendingtransfer

ADT^A26^ADT_A21

Pendingdischarge

ADT^A16^ADT_A16

Cancel pending
discharge

ADT^A25^ADT_A21

Figure 3.31-3: Additional interactions for “Pending Event Management” option

3.31.5.4 Advanced Encounter Management Option
1000

This option provides support to manage changes of attending doctor, leaves of absence, andaccounts.
The following is the required message set to support the “Advanced Encounter Management”
option:Table 3.31-4: Message subset for Advanced Encounter Management option
Trigger / Action

Category of event

1005

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

Update patient information

A08

ADT^A08^ADT_A01

Merge patient identifier lists

A40

ADT^A40^ADT_A39

Change attending doctor

A54

Leave of absence

A21

Return from leave of absenceMove account information

cancelA11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

ADT^A54^ADT_A54

A55

ADT^A55^ADT_A52

ADT^A21^ADT_A21

A52

ADT^A52^ADT_A52

A22

ADT^A22^ADT_A21

A53

ADT^A53^ADT_A52

A44

ADT^A44^ADT_A43

A system implementing this option shall support these 15 trigger events and messages.

Rev. 9.0 Final Text – 2012-08-31

43

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Figure 3.31-4 below depicts the messages added by this option to the basic subset.
Patient Encounter
SourcePatient Encounter
Consumer

Change attending
doctor

ADT^A54^ADT_A54

Cancel change
attending doctor

ADT^A55^ADT_A52

Leave of absence

ADT^A21^ADT_A21

Cancel leave ofabsence

ADT^A52^ADT_A52

Return from leave ofabsence

ADT^A22^ADT_A21

Cancel return fromleave of absence

ADT^A53^ADT_A52

Move accountinformation

ADT^A44^ADT_A43

Figure 3.31-4: Additional interactions for “Advanced Encounter Management” option

1010

3.31.5.5 Temporary Patient Transfers Tracking Option
This option tracks patient moves to and from temporary locations such as radiotherapy, scanner,
EKG, and dialysis.
The following is the required message set to support the “Temporary Patient Transfers Tracking”
option:1015

Table 3.31-5: Message subset for Temporary Patient Transfers Tracking option
Trigger / Action

Category of event

insertcancelAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

A11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

Update patient information

A08

ADT^A08^ADT_A01

Merge patient identifier lists

A40

ADT^A40^ADT_A39

Patient departing - Tracking

A09

ADT^A09^ADT_A09

A33

ADT^A33^ADT_A21

Patient arriving - Tracking

A10

ADT^A10^ADT_A09

A32

ADT^A32^ADT_A21

A system implementing this option shall support these 10 trigger events and messages.

Rev. 9.0 Final Text – 2012-08-31

44

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Figure 3.31-5 below depicts the messages added by this option to the basic subset.
Patient Encounter
SourcePatient Encounter
Consumer

Patient departing,tracking

ADT^A09^ADT_A09

Patient arriving,
tracking

ADT^A10^ADT_A09

Cancel patient
departing, tracking

ADT^A33^ADT_A21

Cancel patient
arriving, tracking

ADT^A32^ADT_A21

Figure 3.31-5: Additional interactions for “Temporary Patient Transfers Tracking” option

1020

3.31.5.6 Historic Movement Management
This option adds the capability to cancel or update safely any Movement.
The Movement updated can be the current Movement (currently active or pending) or a
Movement in the past (i.e., historic Movement).
The Movement canceled can only be the current Movement (currently active or pending).

1025

1030

1035

This capability is supported by the addition of segment ZBE below PV1/PV2. With this option,
this ZBE segment is required at this position in the messages associated with the following
trigger events: A01, A02, A03, A04, A05, A06, A07, A11, A12, A13, A14, A15, A16, A21,
A22, A25, A26, A27, A38, A52, A53, A54, A55, Z99. In the following sections the ZBE
segment is only shown in the message associated with trigger Z99 which is dedicated to theHistoric Movement Management option. In the other messages, this segment will appear
whenever this option is active.
This segment ZBE brings the following features:• It enables unique identification of the Movement (including admission and discharge).
• It carries an action code that describes the action to be performed on this Movement: The
three possible actions are:• INSERT: The receiver must interpret the content of this message as a new
Movement.
Rev. 9.0 Final Text – 2012-08-31

45

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________CANCEL: This action code is always associated with a “cancel” trigger event. The
receiver shall delete the corresponding Movement (matched with its unique
identifier). Only the current Movement can be cancelled.
• UPDATE: This action code is associated with the dedicated trigger event Z99
described in ITI TF-2b: 3.31.7.30. The receiver shall update the corresponding
Movement (matched with its unique identifier), which can be the current Movement
or a historic Movement.
In the case of UPDATE or CANCEL, the ZBE segment carries the code of the original
trigger event that was associated with the action INSERT of the related Movement.
It carries an indicator “Historic Movement” informing whether the action to perform is about
the current Movement or a Historic one.
It provides the starting date/time of the “sub-encounter” that this Movement initiates.
It carries the ward to which this patient is assigned during this sub-encounter.
•

1040

1045

•
•

1050

•
•

This option may apply to any combination of the previous subsets, except Temporary Patient
Transfers Tracking (Temporary Patient Transfers do not need to be uniquely identified).
Implementation note: The Patient Encounter Consumer must support transaction log update tomaintain integrity of the Movement records.
1055

3.31.6 Common HL7 Message Segments
Messages in Transaction 31 use the same common HL7 message segments as those inTransaction 30; refer to ITI TF-2b: 3.30.5. In addition, messages in Transaction 31 use the ZBE
segment, described below.
3.31.6.1 ZBE – Movement Action segment

1060

1065

The ZBE segment was introduced in the German extension of the IHE Radiology Technical
Framework. It is extended here with three additional fields: ZBE-5, ZBE-6 and ZBE-7. ThisZBE segment is required with the “Historic Movement” option of transaction ITI-31.
The purpose of this segment is to uniquely identify any movement at creation time (action
INSERT), so that any further correction brought to this movement (action UPDATE) or
cancellation of it (action CANCEL) can be achieved safely and consistently between the two
actors Patient Encounter Supplier and Patient Encounter Consumer.
Another security feature offered by this segment is to clearly distinguish current events fromevents that address a historic (past) movement to avoid any misinterpretation on the part of thereceiving application.

1070

Table 3.31-6: ZBE segment description
SEQ

LEN

DT

Usage

Card.

1

EI

R

[1..*]

Movement ID

2

TS

R

[1..1]Start Movement Date/Time

3

TS

O

[0..1]End Movement Date/Time

4

ID

R

[1..1]

Movement Action (INSERT / UPDATE / CANCEL)

Rev. 9.0 Final Text – 2012-08-31

46

ELEMENT NAME

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
DT

Usage

Card.

5

SEQ

LEN

ID

R

[1..1]

Historical Movement Indicator (values: Y / N)

ELEMENT NAME

6

ID

C

[0..1]

Original trigger event code [in the case of an UPDATE of the
movement (trigger A08), this field conveys the original trigger
event that was sent with the INSERT]

7

XO
N

O

[0..1]

Responsible Ward (Medical or Nursing Ward, depending of thetrigger event of the message)

ZBE-1 – Movement ID (EI): required and repeatable to support cooperative Movement
Management. The Movement Identifier list is created with the action INSERT, and then recalledwith further actions such as UPDATE or CANCEL.
1075

ZBE-2 – Start Movement Date/Time (TS): Required. It is the date/time of the creation of theMovement, i.e., the effective date time of the event that used action INSERT with thisMovement.
ZBE-3 – End Movement Date/Time (TS): Optional.

1080

1085

ZBE-4 – Action (ID): Required. Three possible values:• INSERT: With any trigger event that inserts a movement.
• UPDATE: With trigger event Z99• CANCEL: With any “cancel” trigger event.
ZBE-5 –Historic Indicator (ID): Required. Values:• ‘Y’ when the message is related to a Historic Movement.
• ‘N’ when the message is related to the current (last or next) movement.
ZBE-6 – Original Trigger (ID): Conditional.
Condition predicate: This field shall be populated when ZBE-4 contains action UPDATE or
CANCEL. In this case, this field is populated with the trigger event that inserted (action
INSERT) the movement being currently updated or canceled.

1090

ZBE-7 – Responsible Ward (XON): Optional. This field may be further constrained in national
extensions of this transaction. It will, for example, be associated with usage ‘RE’ in the Frenchextension.
3.31.7 Interactions

1095

The following sections contain the static definitions of the messages belonging to the various
optional sets described above.
The Historic Movement Management option is not shown in these message tables. The reader isreminded that this option adds the ZBE segment below PV1/PV2.

Rev. 9.0 Final Text – 2012-08-31

47

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.1 Admit/Visit Notification (ADT^A01^ADT_A01)
3.31.7.1.1
1100

Trigger Event

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient has arrived at a healthcare facility for an episode of care in which the patient is
assigned to an inpatient bed. Such an episode is commonly referred to as “inpatient” care.
MSH-9 is valued ADT^A01^ADT_A01.
3.31.7.1.2

1105

Message Static Definition
Table 3.31-7: Static definition of message ADT^A01^ADT_A01

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

O[0..*]

15
6

ROL

Role

---

--- PROCEDURE end

GT1

Guarantor

O[0..*]------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

O[0..*]

15

ROL

Role

---

--- INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

Rev. 9.0 Final Text – 2012-08-31

48

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.1.3

1110

Comments on segment usage

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.1.4

1115

Expected actions

The receiver shall update the patient’s status to indicate that the patient has been admitted.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1120

In case this Movement (new admission) conflicts with an existing current movement for thepatient (an admission is already opened for this patient) the message is discarded and an error
condition is raised.
3.31.7.2 Cancel Admit/Visit Notification – ADT^A11^ADT_A09
3.31.7.2.1

1125

Trigger Event

This message is sent by a Patient Encounter Supplier to cancel a previous notification to a Patient
Encounter Consumer as a notification that a patient has been admitted for an inpatient stay (via
trigger event A01) or registered for an outpatient visit (via trigger event A04). See ITI TF-2b:
3.31.5.8 for the message to be used to cancel a pre-admit notification, and ITI TF-2b: 3.31.5.14
for the message to be used to cancel a pending admit notification.
MSH-9 is valued ADT^A11^ADT_A09.
3.31.7.2.2

1130

Message Static Definition
Table 3.31-8: Static definition of message ADT^A11^ADT_A09

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

X[0..0]

6

Rev. 9.0 Final Text – 2012-08-31

49

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.2.3

Comments on segment usageNone.
3.31.7.2.4
1135

Expected actions

The receiver shall reset the patient’s status in its system to the value existing immediately before
the admit or visit notification was received.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1140

In case this Movement conflicts with the current situation of the patient (i.e., no inpatient nor
outpatient visit has been opened for this patient) the message is discarded but no error conditionis raised.
3.31.7.3 Register a Patient (ADT^A04^ADT_A01)
3.31.7.3.1

1145

Trigger Event

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient has arrived at a healthcare facility for an episode of care in which the patient is not
assigned to a bed. Examples of such episodes include outpatient visits, ambulatory careencounters, and emergency room visits.
MSH-9 is valued ADT^A04^ADT_A01.
3.31.7.3.2

Message Static Definition
Table 3.31-9: Static definition of message ADT^A04^ADT_A01

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

Rev. 9.0 Final Text – 2012-08-31

50

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

1150

Usage

Card.

PR1

Procedures

MeaningR[1..1]

6

HL7 chapter

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.3.3

Comments on segment usage

Field PV1-44-admit date/time is used to carry the date and time that the encounter started.

1155

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.3.4

1160

Expected actions

The receiver shall update the patient’s status to indicate that the visit has started.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case an inpatient encounter is already opened, the outpatient encounter is still recorded by thereceiver. This is not a situation of conflict and no error condition is raised.

1165

3.31.7.4 Discharge/End Visit (ADT^A03^ADT_A03)
3.31.7.4.1

1170

Trigger Event

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient’s stay at a healthcare facility has ended. Inpatient encounters are generally closed
by an A03. Outpatient encounters may or may not be closed by an A03, depending on thehealthcare organization policies.

Rev. 9.0 Final Text – 2012-08-31

51

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
MSH-9 is valued ADT^A03^ADT_A03.
3.31.7.4.2

Message Static Definition
Table 3.31-10: Static definition of message ADT^A03^ADT_A03

Segment

1175

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

OBX

Observation/Result

O[0..*]

7

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.4.3

Comments on segment usage

Field PV1-3-assigned patient location is used to indicate the patient’s last location prior todischarge (or end of visit).
Field PV1-45-discharge date/time is used to carry either the date and time of discharge (for an
inpatient) or the date and time that the visit ended (for an outpatient).

1180

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be

Rev. 9.0 Final Text – 2012-08-31

52

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.
1185

If the patient is deceased, fields PID-29-Patient Death Date and Time and PID-30-Patient Death
Indicator shall be populated.
3.31.7.4.4

Expected actions

The receiver shall update the patient’s status to “discharged” (or “visit ended”).
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
1190

In case this Movement conflicts with the current situation of the patient (no inpatient nor
outpatient visit opened for this patient) the message is discarded but no error condition is raised.
3.31.7.5 Cancel Discharge/End Visit – ADT^A13^ADT_A01
3.31.7.5.1

1195

Trigger Event

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A03) that a patient’s stay at a healthcare facility had
ended.
MSH-9 is valued ADT^A13^ADT_A01.
3.31.7.5.2

Message Static Definition
Table 3.31-11: Static definition of message ADT^A13^ADT_A01
Usage

Card.

MSH

Segment

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

Rev. 9.0 Final Text – 2012-08-31

53

HL7 chapter

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

1200

Usage

Card.

PR1

Procedures

MeaningR[1..1]

6

HL7 chapter

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.5.3

Comments on segment usage

Field PV1-3-patient location shall contain the patient’s location after the cancellation has beenprocessed. This may be different from the patient’s location prior to the discharge/end visit
notification.
3.31.7.5.4
1205

Expected actions

The receiver shall reset the patient’s status to its value prior to the receipt of the discharge/end
visit message, and shall update the patient’s location to the value in field PV1-3-patient location.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1210

In case this Movement conflicts with the current situation of the patient (no prior discharge
received) the message is discarded but no error condition is raised.
3.31.7.6 Update Patient Information (ADT^A08^ADT_A01)
3.31.7.6.1

1215

Trigger Event

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that some non-movement-related information (such as address, date of birth, etc.) has changed
for a patient. It is used when information about the patient has changed not related to any othertrigger event.
MSH-9 is valued ADT^A08^ADT_A01.

Rev. 9.0 Final Text – 2012-08-31

54

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.6.2

Message Static Definition
Table 3.31-12: Static definition of message ADT^A08^ADT_A01
Usage

Card.

MSH

Segment

Message Header

MeaningR[1..1]

2

HL7 chapter

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

31220

3.31.7.6.3

Comments on segment usage

1225

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.

Rev. 9.0 Final Text – 2012-08-31

55

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.6.4
1230

Expected actions

The receiver shall update the patient record in its database to contain the information in themessage.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no active encounter forthis patient, or the patient is unknown) the message is discarded but no error condition is raised.

1235

3.31.7.7 Pre-Admit (ADT^A05^ADT_A05)
3.31.7.7.1

Trigger Event

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer tocommunicate information that has been collected about a patient to be admitted as an inpatient(or to be registered as an outpatient).
1240

MSH-9 is valued ADT^A05^ADT_A05.
3.31.7.7.2

Message Static Definition
Table 3.31-13: Static definition of message ADT^A05^ADT_A05

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

Rev. 9.0 Final Text – 2012-08-31

56

6

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

1245

1250

Meaning

Usage

Card.

HL7 chapterO[0..*]

15

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.7.3

Comments on segment usage

ROL

Role

---

--- PROCEDURE end

GT1

Field PV2-8-expected admit date/time is used to carry the expected date and time when thepatient is to be admitted (or registered).
Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.7.4

1255

Expected actions

The receiver shall update the patient’s status to pre-admitted.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
There is no particular potential conflict between this Movement and any previously received
message related to the same patient.

1260

If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).

Rev. 9.0 Final Text – 2012-08-31

57

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.8 Cancel Pre-Admit – ADT^A38^ADT_A38
3.31.7.8.1
1265

Trigger Event

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A08) that a patient was to be updated to pre-admitted(or pre-registered) status.
MSH-9 is valued ADT^A38^ADT_A38.
3.31.7.8.2

Message Static Definition
Table 3.31-14: Static definition of message ADT^A38^ADT_A38

Segment

1270

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..*]

6

3.31.7.8.3

Comments on segment usageNone.
3.31.7.8.4

Expected actions

The receiver shall reset the patient’s status to its value prior to the receipt of the pre-admit
message.
1275

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no pre-admit registered
for this patient, or the patient is unknown) the message is discarded but no error condition israised.

1280

If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).

Rev. 9.0 Final Text – 2012-08-31

58

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.9 Change Outpatient to Inpatient (ADT^A06^ADT_A06)
3.31.7.9.1
1285

Trigger Event

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that it has been decided to admit a patient that was formerly in a non-admitted status, such as
Emergency.
MSH-9 is valued ADT^A06^ADT_A06.
3.31.7.9.2

Message Static Definition
Table 3.31-15: Static definition of message ADT^A06^ADT_A06

Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

MRG

Merge Information

C[0..1]

3

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

Rev. 9.0 Final Text – 2012-08-31

59

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
1290

3.31.7.9.3

Comments on segment usage

The new patient location should appear in PV1-3 - Assigned Patient Location while the oldpatient location (if different) should appear in PV1-6 - Prior Patient Location.
Condition predicate on use of the segment MRG:
1295

A change from outpatient to inpatient status may be accompanied by the closing of theoutpatient account and the opening of an inpatient account. This may be expressed bypopulating the outpatient account number into MRG-3-prior account number and theinpatient account number into PID-18-patient account number. The use of the MRG
segment in this case is strictly conventional and is not intended to communicate an actual
merge.

1300

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.

1305

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.9.4

Expected actions

The receiver shall update the patient’s class to “inpatient,” and if necessary shall update thepatient’s location to the value in field PV1-3-patient location.
1310

If the MRG segment is included, the receiver shall update the patient’s account number from thevalue in MRG-3-prior account number to the value in PID-18-patient account number.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1315

In case this Movement conflicts with the current situation of the patient (no active outpatientencounter is known for this patient, or the patient is unknown) the message is still processed andinitiates a new inpatient encounter for a possibly new patient, and no error condition is raised.
If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.10

1320

Change Inpatient to Outpatient (ADT^A07^ADT_A06)

3.31.7.10.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient is no longer in an “admitted” status, but is still being seen for an episode of care.
MSH-9 is valued ADT^A07^ADT_A06.

Rev. 9.0 Final Text – 2012-08-31

60

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.10.2 Message Static Definition
1325

Table 3.31-16: Static definition of message ADT^A07^ADT_A06
Usage

Card.

MSH

Segment

Message Header

MeaningR[1..1]

2

HL7 chapter

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

MRG

Merge Information

C[0..1]

3

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

3.31.7.10.3 Comments on segment usage
The new patient location should appear in PV1-3 - Assigned Patient Location while the oldpatient location (if different) should appear in PV1-6 - Prior Patient Location.
Condition predicate on use of the segment MRG:
1330

A change from inpatient to outpatient status may be accompanied by the closing of theinpatient account and the opening of an outpatient account. This may be expressed by

Rev. 9.0 Final Text – 2012-08-31

61

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1335

populating the inpatient account number into MRG-3-prior account number and theoutpatient account number into PID-18-patient account number. The use of the MRG
segment in this case is strictly conventional and is not intended to communicate an actual
merge.

1340

Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments. Providers
specific to a particular insurance carrier may be communicated in ROL segments immediately
following the IN1/IN2/IN3 segments.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.10.4 Expected actions

1345

The receiver shall update the patient’s class to “outpatient,” and if necessary shall update thepatient’s location to the value in field PV1-3-patient location.
If the MRG segment is included, the receiver shall update the patient’s account number from thevalue in MRG-3-prior account number to the value in PID-18-patient account number.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1350

In case this Movement conflicts with the current situation of the patient (no active inpatientencounter is known for this patient, or the patient is unknown) the message is still processed andinitiates a new outpatient encounter for a possibly new patient, and no error condition is raised.
If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).

1355

3.31.7.11

Transfer a Patient (ADT^A02^ADT_A02)

3.31.7.11.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient is being transferred from one location to another. The new location will bereflected in the institution’s bed census.
1360

MSH-9 is valued ADT^A02^ADT_A02.
3.31.7.11.2 Message Static Definition
Table 3.31-17: Static definition of message ADT^A02^ADT_A02
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

Rev. 9.0 Final Text – 2012-08-31

62

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Usage

Card.

HL7 chapter

PD1

Segment

Additional Demographics

MeaningO[0..1]

3

ROL

Role

O

[0..*]

15

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.11.3 Comments on segment usage
1365

The new patient location should appear in PV1-3 - Assigned Patient Location while the oldpatient location should appear in PV1-6 - Prior Patient Location.
Providers with an ongoing relationship with the patient may be communicated in ROL segments
immediately following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments.

1370

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
Segment DG1 should be used to communicate diagnosis information only if it is necessary tocommunicate with a receiver that is using a version of HL7 prior to V2.5.
3.31.7.11.4 Expected actions
The receiver shall update the patient’s location to the value in field PV1-3-patient location.

1375

1380

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no active inpatientencounter is known for this patient, or the patient is unknown or the known patient location was
not the one declared in PV1-6) the message is still processed, the new situation is registered (theencounter and the patient are created if needed) and no error condition is raised.
If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.12

Cancel Transfer – ADT^A12^ADT_A12

3.31.7.12.1 Trigger Event
1385

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A02) that a patient was being moved from one location
to another.
MSH-9 is valued ADT^A12^ADT_A12.

Rev. 9.0 Final Text – 2012-08-31

63

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.12.2 Message Static Definition
1390

Table 3.31-18: Static definition of message ADT^A12^ADT_A12
Usage

Card.

HL7 chapter

MSH

Segment

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

X[0..0]

6

3.31.7.12.3 Comments on segment usage
Field PV1-3-patient location shall contain the patient’s location prior to the transfer.
3.31.7.12.4 Expected actions
1395

The receiver shall reset the patient’s location to the value in field PV1-11-temporary location or
to the value in field PV1-3-patient location, as appropriate.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1400

In case this Movement conflicts with the current situation of the patient (no transfer previously
notified, or encounter unknown, or patient unknown) the message is discarded, and no error
condition is raised.
If the receiver does not support the Inpatient/Outpatient Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.13

Pending Admit (ADT^A14^ADT_A05)

3.31.7.13.1 Trigger Event
1405

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that it is planned to admit a patient.
MSH-9 is valued ADT^A14^ADT_A05.
3.31.7.13.2 Message Static Definition
Table 3.31-19: Static definition of message ADT^A14^ADT_A05
Segment
MSH

Meaning
Message Header

Rev. 9.0 Final Text – 2012-08-31

64

Usage

Card.

HL7 chapter

R[1..1]

2

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

1410

Usage

Card.

HL7 chapter

SFT

Software Segment

MeaningO[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional Info

X

[0..0]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

3.31.7.13.3 Comments on segment usage
Field PV2-8-expected admit date/time is used to carry the expected date and time when thepatient is to be admitted.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.

1415

3.31.7.13.4 Expected actions
The receiver shall update the patient’s status to “pending admit”.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
Rev. 9.0 Final Text – 2012-08-31

65

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1420

There is no particular potential conflict between this Movement and any previously received
message related to the same patient.
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).
3.31.7.14

Cancel Pending Admit – ADT^A27^ADT_A21

3.31.7.14.1 Trigger Event
1425

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A14) that a patient was expected to be admitted.
MSH-9 is valued ADT^A27^ADT_A21.
3.31.7.14.2 Message Static Definition
Table 3.31-20: Static definition of message ADT^A27^ADT_A21
Segment

1430

Usage

Card.

HL7 chapter

MSH

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.14.3 Comments on segment usage
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.14.4 Expected actions

1435

The receiver shall reset the patient’s status to its value prior to the receipt of the “pending admit”
message.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1440

In case this Movement conflicts with the current situation of the patient (no pending admit
previously notified, or patient unknown) the message is discarded, and no error condition israised.
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).

Rev. 9.0 Final Text – 2012-08-31

66

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.15

Pending Transfer (ADT^A15^ADT_A15)

3.31.7.15.1 Trigger Event
1445

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that it is planned to transfer a patient.
MSH-9 is valued ADT^A15^ADT_A15.
3.31.7.15.2 Message Static Definition
Table 3.31-21: Static definition of message ADT^A15^ADT_A15
Segment

1450

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

O[0..*]

6

3.31.7.15.3 Comments on segment usage
Providers with an ongoing relationship may be communicated in ROL segments immediately
following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments.

1455

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
Segment DG1 should be used to communicate diagnosis information only if it is necessary tocommunicate with a receiver that is using a version of HL7 prior to V2.5.
The planned date for this pending transfer is given in field EVN-3 of segment EVN. See ITI TF2b: 3.30.5.2.

1460

3.31.7.15.4 Expected actions
The receiver shall record that a transfer is pending for this patient.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

Rev. 9.0 Final Text – 2012-08-31

67

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1465

In case this Movement conflicts with the current situation of the patient (no active inpatientencounter, or patient unknown) the message is discarded, and no error condition is raised.
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).
3.31.7.16

Cancel Pending Transfer – ADT^A26^ADT_A21

3.31.7.16.1 Trigger Event
1470

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A25) that it was planned to transfer a patient.
MSH-9 is valued ADT^A26^ADT_A21.
3.31.7.16.2 Message Static Definition
Table 3.31-22: Static definition of message ADT^A26^ADT_A21
Segment

1475

Usage

Card.

MSH

Message Header

MeaningR[1..1]

2

HL7 chapter

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.16.3 Comments on segment usage
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
The planned date for the pending transfer that is cancelled, is given in field EVN-3 of segment
EVN. See ITI TF-2b: 3.30.5.2.

1480

3.31.7.16.4 Expected actions
The receiver shall reset the patient’s status to the value immediately before the Pending Transfer
message was received.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1485

In case this Movement conflicts with the current situation of the patient (no pending transfer
known, or no active inpatient encounter, or patient unknown) the message is discarded, and noerror condition is raised.

Rev. 9.0 Final Text – 2012-08-31

68

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).
1490

3.31.7.17

Pending Discharge (ADT^A16^ADT_A16)

3.31.7.17.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that it is planned to discharge a patient.
MSH-9 is valued ADT^A16^ADT_A16.
1495

3.31.7.17.2 Message Static Definition
Table 3.31-23: Static definition of message ADT^A16^ADT_A16
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoRE

[0..1]

3

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

6

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

Rev. 9.0 Final Text – 2012-08-31

69

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.17.3 Comments on segment usage
Field PV2-9-expected discharge date/time is used to carry the expected date and time when thepatient is to be discharged.
1500

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.17.4 Expected actions
The receiver shall update the patient’s status to “pending discharge”.

1505

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no active inpatientencounter, or patient unknown) the message is discarded, and no error condition is raised.
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).

1510

3.31.7.18

Cancel Pending Discharge – ADT^A25^ADT_A21

3.31.7.18.1 Trigger Event
This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A16) that a patient was expected to be discharged.
MSH-9 is valued ADT^A25^ADT_A21.
1515

3.31.7.18.2 Message Static Definition
Table 3.31-24: Static definition of message ADT^A25^ADT_A21
Usage

Card.

MSH

Segment

Message Header

MeaningR[1..1]

2

HL7 chapter

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.18.3 Comments on segment usage
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.

Rev. 9.0 Final Text – 2012-08-31

70

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
1520

3.31.7.18.4 Expected actions
The receiver shall reset the patient’s status to its value prior to the receipt of the “pending
discharge” message.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1525

In case this Movement conflicts with the current situation of the patient (no pending discharge
known, or no active inpatient encounter, or patient unknown) the message is discarded, and noerror condition is raised.
If the receiver does not support the Pending Event Management option of this transaction, it shallapplication-reject the message (see ITI TF-2x: C.2.3).

1530

3.31.7.19

Change Attending Doctor – ADT^A54^ADT_A54

3.31.7.19.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that there has been a change in the doctor responsible for the patient’s treatment.
MSH-9 is valued ADT^A54^ADT_A54.
1535

3.31.7.19.2 Message Static Definition
Table 3.31-25: Static definition of message ADT^A54^ADT_A54
Usage

Card.

MSH

Segment

Message Header

MeaningR[1..1]

2

HL7 chapter

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ROL

Role

O

[0..*]

15

3.31.7.19.3 Comments on segment usage
Field PV1-7-attending doctor shall contain the new attending doctor.
1540

Providers with an ongoing relationship may be communicated in ROL segments immediately
following the PID/PD1 segments. Providers specific to an episode of care may be
communicated in ROL segments immediately following the PV1/PV2 segments.
Field ROL-4-role begin date/time and ROL-5-role end date/time are used to communicate thebegin and end date and time of the attending doctor (or of the admitting, consulting, and/or

Rev. 9.0 Final Text – 2012-08-31

71

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1545

referring doctor, as appropriate and as designated in ROL-7-role code). When segment ROL isused to communicate this information, field ROL-2-action code should be valued UP.
3.31.7.19.4 Expected actions
The receiver shall record the patient’s new attending doctor.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1550

In case this Movement conflicts with the current situation of the patient (no active inpatient or
outpatient encounter, or patient unknown) the message is discarded, but no error condition israised. If the receiver does not support the Advanced Encounter Management option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.20

1555

Cancel Change Attending Doctor – ADT^A55^ADT_A52

3.31.7.20.1 Trigger Event
This message is sent by a Patient Encounter Supplier to cancel a previous notification to a Patient
Encounter Consumer of a change to the patient’s attending doctor.
MSH-9 is valued ADT^A55^ADT_A52.
3.31.7.20.2 Message Static Definition

1560

Table 3.31-26: Static definition of message ADT^A55^ADT_A52
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

3.31.7.20.3 Comments on segment usage
Field PV1-7-attending doctor shall contain the patient’s attending doctor prior to the notificationof change.
3.31.7.20.4 Expected actions
1565

The receiver shall reset the patient’s attending doctor to the value in field PV1-7-attending
doctor.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

Rev. 9.0 Final Text – 2012-08-31

72

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1570

In case this Movement conflicts with the current situation of the patient (no active inpatient or
outpatient encounter, or patient unknown) the message is discarded, but no error condition israised.
If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.21

1575

Patient Goes on a Leave of Absence – ADT^A21^ADT_A21

3.31.7.21.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient has left the healthcare institution temporarily.
MSH-9 is valued ADT^A21^ADT_A21.
3.31.7.21.2 Message Static Definition

1580

Table 3.31-27: Static definition of message ADT^A21^ADT_A21
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.21.3 Comments on segment usage
Field EVN-6-event occurred shall contain the date and time that the patient actually left theinstitution. PV2-47-expected LOA return shall contain the date and time that the patient is
expected to return from the leave of absence.
1585

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.21.4 Expected actions
The receiver shall record that the patient has left the institution on a leave of absence.

1590

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no active encounter, or
patient unknown) the message is discarded, but no error condition is raised.

Rev. 9.0 Final Text – 2012-08-31

73

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
1595

3.31.7.22

Cancel Leave of Absence for a Patient – ADT^A52^ADT_A52

3.31.7.22.1 Trigger Event
This message is sent by a Patient Encounter Supplier to cancel a previous notification to a Patient
Encounter Consumer that a patient had left the healthcare institution temporarily.
MSH-9 is valued ADT^A52^ADT_A52.
1600

3.31.7.22.2 Message Static Definition
Table 3.31-28: Static definition of message ADT^A52^ADT_A52
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

3.31.7.22.3 Comments on segment usage
Field EVN-6-event occurred shall contain the date and time that the leave of absence wascancelled.
1605

3.31.7.22.4 Expected actions
The receiver shall cancel the patient’s leave of absence.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1610

In case this Movement conflicts with the current situation of the patient (no leave of absence
previously notified, or no active encounter, or patient unknown) the message is discarded, but noerror condition is raised.
If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.23

1615

Patient Returns from a Leave of Absence – ADT^A22^ADT_A21

3.31.7.23.1 Trigger Event
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient has returned from a leave of absence.

Rev. 9.0 Final Text – 2012-08-31

74

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
MSH-9 is valued ADT^A22^ADT_A21.
3.31.7.23.2 Message Static Definition
1620

Table 3.31-29: Static definition of message ADT^A22^ADT_A21
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.23.3 Comments on segment usage
Field EVN-6-event occurred shall contain the date and time that the patient actually returned
from the leave of absence. PV2-47-expected LOA return shall contain the date and time that thepatient was expected to return from the leave of absence.
1625

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
3.31.7.23.4 Expected actions
The receiver shall record that the patient has returned from the leave of absence.

1630

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this Movement conflicts with the current situation of the patient (no leave of absence
previously notified, or no active encounter, or patient unknown) the message is discarded, but noerror condition is raised.

1635

If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.24
Cancel Patient Return from a Leave of Absence –ADT^A53^ADT_A52
3.31.7.24.1 Trigger Event

1640

This message is sent by a Patient Encounter Supplier to cancel a previous notification to a Patient
Encounter Consumer that a patient had returned from a leave of absence.
MSH-9 is valued ADT^A53^ADT_A52.

Rev. 9.0 Final Text – 2012-08-31

75

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.31.7.24.2 Message Static Definition
Table 3.31-30: Static definition of message ADT^A53^ADT_A52
Segment

1645

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

3.31.7.24.3 Comments on segment usage
Field EVN-6-event occurred shall contain the date and time that the return from leave of absence
was cancelled. PV2-47-expected LOA return shall contain the date and time that the patient is
expected to return from the leave of absence.
3.31.7.24.4 Expected actions

1650

The receiver shall cancel the patient’s return from leave of absence.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1655

In case this Movement conflicts with the current situation of the patient (no return from leave ofabsence previously notified, or no active encounter, or patient unknown) the message isdiscarded, but no error condition is raised.
If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.25

Move account information – ADT^A44^ADT_A43

3.31.7.25.1 Trigger Event
1660

This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that an account previously associated with one patient is now associated with another patient.
MSH-9 is valued ADT^A44^ADT_A43.
3.31.7.25.2 Message Static Definition
Table 3.31-31: Static definition of message ADT^A44^ADT_A43
Usage

Card.

HL7 chapter

MSH

Segment

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

Rev. 9.0 Final Text – 2012-08-31

76

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Usage

Card.

HL7 chapter

EVN

Segment
Event TypeR

[1..1]

2------ PATIENT beginR[1..*]

Patient IdentificationR[1..1]

PID

1665

Meaning3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3------ PATIENT end

3.31.7.25.3 Comments on segment usageNone.
3.31.7.25.4 Expected actions

1670

The receiver shall associate the account in MRG-3-prior patient account number with the patient
in PID-3-patient identifier list, and shall remove associations of that account with the patient in
MRG-1-prior patient identifier list.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this message conflicts with the current situation (account unknown or supplier patient
unknown) the message is discarded, but no error condition is raised.

1675

If the receiver does not support the Advanced Encounter Management option of this transaction,
it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.26

Patient Departing – Tracking (ADT^A09^ADT_A09)

3.31.7.26.1 Trigger Event
1680

1685

This message is only used within the context of the “Temporary Patient Transfers Tracking”
option.
This message is sent by a Patient Encounter Supplier to notify a Patient Encounter Consumer
that a patient has departed a location without the patient’s official bed census location having
changed. The HL7 standard describes three situations that qualify as non-census location
changes: (a) patient tracking (i.e., pre-notification before an official transfer), (b) the patient is intransit between locations for some time, (c) a notification of temporary location change. This
IHE transaction only uses the latter: notification of temporary location change.
MSH-9 is valued ADT^A09^ADT_A09.
3.31.7.26.2 Message Static Definition
Table 3.31-32: Static definition of message ADT^A09^ADT_A09
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

Rev. 9.0 Final Text – 2012-08-31

77

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Segment

1690

Usage

Card.

HL7 chapter

EVN

Event Type

MeaningR[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

O[0..*]

6

3.31.7.26.3 Comments on segment usage
If the patient has left for a non-temporary location (tracking), then field PV1-3-patient location
shall contain the patient’s new location and field PV1-6-prior patient location shall contain thepatient’s old location.

1695

If the patient will be in transit for some time, then field PV1-42-pending location shall containthe new location and field PV1-6-prior patient location shall contain the patient’s old location.

1700

If the patient is moving to a temporary location, then field PV1-11-temporary location shallcontain the new temporary location. If the patient is moving from a temporary location, thenfield PV1-43-prior temporary location shall contain the old temporary location. If the patient ismoving from a permanent location, then field PV1-6-prior patient location shall contain the oldpermanent location.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
Segment DG1 should be used to communicate diagnosis information only if it is necessary tocommunicate with a receiver that is using a version of HL7 prior to V2.5.

1705

3.31.7.26.4 Expected actions
The receiver shall reset the patient’s location to the value in field PV1-11-temporary location,
field PV1-42-pending location, or field PV1-3-patient location, as appropriate.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1710

In case this message conflicts with the current situation the message is discarded, but no error
condition is raised.
If the receiver does not support the Temporary Patient Location Tracking option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).

Rev. 9.0 Final Text – 2012-08-31

78

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.27
1715

Cancel Patient Departing – Tracking – ADT^A33^ADT_A21

3.31.7.27.1 Trigger Event
This message is only used within the context of the “Temporary Patient Transfers Tracking”
option. This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer tocancel a previous notification (via trigger event A09) that a patient has departed a location
without the patient’s official bed census location having changed.

1720

MSH-9 is valued ADT^A33^ADT_A21.
3.31.7.27.2 Message Static Definition
Table 3.31-33: Static definition of message ADT^A33^ADT_A21
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

3.31.7.27.3 Comments on segment usage1725

If the patient was in a non-temporary location, then field PV1-3-patient location shall contain thepatient’s location prior to the erroneous A09 event. If the patient was in a temporary location,then field PV1-11-temporary location shall contain the patient’s location prior to the erroneous
A09 event.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.

1730

3.31.7.27.4 Expected actions
The receiver shall reset the patient’s location to the value in field PV1-11-temporary location or
to the value in field PV1-3-patient location, as appropriate.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1735

In case this message conflicts with the current situation the message is discarded, but no error
condition is raised.
If the receiver does not support the Temporary Patient Location Tracking option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).

Rev. 9.0 Final Text – 2012-08-31

79

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.28
1740

Patient Arriving – Tracking – ADT^A10^ADT_A09

3.31.7.28.1 Trigger Event
This message is only used within the context of the “Temporary Patient Transfers Tracking”
option.

1745

1750

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer as a
notification that a patient has arrived at a new location without the patient’s official bed census
location having changed. The HL7 standard describes three varieties of these non-census
location changes involving three different kinds of notification: (a) an unofficial notification oflocation change prior to the official notification of patient tracking, (b) the patient is in transit
between locations for some time, (c) a notification of a temporary location change. This IHE
transaction only uses the latter: notification of temporary location change.
MSH-9 is valued ADT^A10^ADT_A09.
3.31.7.28.2 Message Static Definition
Table 3.31-34: Static definition of message ADT^A10^ADT_A09
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

DG1

Diagnosis Information

X[0..0]

6

3.31.7.28.3 Comments on segment usage
1755

If the patient is arriving at a temporary location, field PV1-11-temporary location shall indicate
this temporary location. If the patient is moving from one temporary location to another, thenfield PV1-43-prior temporary location may also be used.
If the patient is arriving at a permanent location from a temporary location, field PV1-3-patient
location shall be used for the new location and field PV1-43-prior temporary location shall be
used for the old location.

1760

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.

Rev. 9.0 Final Text – 2012-08-31

80

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.28.4 Expected actions
The receiver shall update the patient’s location to the value in field PV1-11-temporary locationor to the value in field PV1-3-patient location, as appropriate.
1765

The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.
In case this message conflicts with the current situation the message is discarded, but no error
condition is raised.

1770

If the receiver does not support the Temporary Patient Location Tracking option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.29

Cancel Patient Arriving – Tracking – ADT^A32^ADT_A21

3.31.7.29.1 Trigger Event

1775

This message is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to cancel
a previous notification (via trigger event A10) that a patient arrived at a location without thepatient’s official bed census location having changed, as for example when the patient arrives at
a diagnostic or treatment service.
MSH-9 is valued ADT^A32^ADT_A21.
3.31.7.29.2 Message Static Definition
Table 3.31-35: Static definition of message ADT^A32^ADT_A21
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

1780

3.31.7.29.3 Comments on segment usage1785

If the patient was in a non-temporary location, then field PV1-3 - Assigned Patient Location may
contain (if known) the original patient location prior to the erroneous A10 (patient arrivingtracking) event. If the patient was in a temporary location, then field PV1-11 - Temporary
Location may contain (if known) the original patient location prior to the erroneous A10 (patient
arriving-tracking) event.
One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
Rev. 9.0 Final Text – 2012-08-31

81

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.29.4 Expected actions
1790

If field PV1-3 - Assigned Patient Location is populated, the receiver shall reset the patient’s
permanent location to the value contained in that field. If field PV1-11 - Temporary Location is
populated, the receiver shall reset the patient’s permanent location to the value contained in thatfield.
The receiver shall report the result of this operation (success / error) in an acknowledgment
message returned to the sender.

1795

In case this message conflicts with the current situation the message is discarded, but no error
condition is raised.
If the receiver does not support the Temporary Patient Location Tracking option of thistransaction, it shall application-reject the message (see ITI TF-2x: C.2.3).
3.31.7.30

1800

Update Patient Movement Information – ADT^Z99^ADT_A01

3.31.7.30.1 Trigger Event
This message is only used within the context of the “Historic Movement Management” option.
It is sent by a Patient Encounter Supplier to a Patient Encounter Consumer to communicate an
update of a Movement, which can be the current Movement or a historic one.
MSH-9 is valued ADT^Z99^ADT_A01.

1805

3.31.7.30.2 Message Static Definition
Table 3.31-36: Static definition of message ADT^Z99^ADT_A01
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

ROL

Role

O

[0..*]

15

NK1

Next of Kin / Associated Parties

O[0..*]

3

PV1

Patient VisitR[1..1]

3

PV2

Patient Visit – Additional InfoO

[0..1]

3

ZBE

Movement segment

R[1..1]

ROL

Role

O

[0..*]

15

DB1

Disability Information

O[0..*]

3

OBX

Observation/Result

O[0..*]

7

AL1

Allergy Information

O[0..*]

3

DG1

Diagnosis Information

O[0..*]

6

DRG

Diagnosis Related GroupO[0..1]

6------ PROCEDURE begin

O[0..*]

Rev. 9.0 Final Text – 2012-08-31

82

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Usage

Card.

HL7 chapter

PR1

Segment
Procedures

MeaningR[1..1]

6

ROL

Role

O

[0..*]

15------ PROCEDURE end

GT1

Guarantor

O[0..*]

6------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

IN2

Insurance Additional Info.

O[0..1]

6

IN3

Insurance Additional Info - Cert.

O[0..1]

6

ROL

Role

O

[0..*]

15------ INSURANCE end

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

PDA

Patient Death and AutopsyO[0..1]

3

6

3.31.7.30.3 Comments on segment usage
The ZBE segment is mandatory in this message. See the description of this segment in ITI TF2b: 3.31.6.1.
1810

3.31.7.30.4 Expected actions
Otherwise, the receiver shall update the Movement in its database, and shall report the result of
this operation (success / error) in an acknowledgment message returned to the sender.
If the receiver does not know the Movement to be updated (identified by ZBE-3 in the ZBE
segment), it discards the message and raises an error condition.

1815

A receiver not supporting the Historic Movement Management option shall application-reject themessage (see ITI TF-2x: C.2.3).
3.31.7.31

Merge two patients - ADT^A40^ADT_A39

3.31.7.31.1 Trigger Event
1820

The Patient Encounter Supplier notifies the merge of records for a patient that was incorrectly
filed under two different identifiers. This message is only used to merge two patient identifiers of
the same type, or two lists of patient identifiers, it is not supposed to update other patient
demographics information. The A08 trigger event should be used for this purpose.
MSH-9 is valued ADT^A40^ADT_A39.

Rev. 9.0 Final Text – 2012-08-31

83

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
1825

3.31.7.31.2 Message Static Definition
Table 3.31-37: Static definition of message ADT^Z40^ADT_A39
Usage

Card.

HL7 chapter

MSH

Segment

Message Header

MeaningR[1..1]

2

SFT

Software Segment

O[0..*]

2

EVN

Event TypeR

[1..1]

2------ PATIENT beginR[1..1]

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3

PV1

Patient Visit

X[0..0]

3---

3.31.7.31.3 Comments on segment usage
This transaction makes unrepeatable the PATIENT segment group: The message cancommunicate only one merge operation for one patient.
1830

The “incorrect supplier identifier” identified in the MRG segment (MRG-1-Prior Patient
Identifier List) is to be merged with the required “correct target identifier” of the same “identifier
type code” component identified in the PID segment (PID-3-Patient Identifier List). The“incorrect supplier identifier” would then logically never be referenced in future transactions.
The PV1 segment is not supported by IHE in this message.

1835

3.31.7.31.4 Expected actions
The receiver shall merge the two patients in its data base, and shall report the result of thisoperation (success / error) in an acknowledgment message returned to the sender.
If the receiver does not recognize the target patient identifiers, it shall perform a Change Patient
Identifier List instead of a Merge.

1840

If the receiver does not recognize the supplier patient identifiers to be merged, it shall take noaction. This situation is not an error.

3.32 Distribute Document Set on Media
1845

This section corresponds to Transaction ITI-32 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-32 is used by the Portable Media Creator to create the media
content and by Portable Media Importer to read the media content.
3.32.1 Scope
In the Distribute Document Set on Media transaction the Portable Media Creator sends
information to media reading actors by means of Interchange Media where it stores theinformation.

Rev. 9.0 Final Text – 2012-08-31

84

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
1850

3.32.2 Use Case Roles
Portable MediaCreatorPortable Media
Importer

DistributeDocument Set on
Media

Actor: Portable Media Creator
Role: Assemble the media content and store it on the media to be distributed.
Actor: Portable Media Importer
1855

Role: Read the Document Submission Set content of distributed media in order to access the
document(s) and the relevant metadata and perform import of the documents on the media.
3.32.3 Referenced Standard
DICOM PS 3.10 Media Storage and File Format for Data Interchange (DICOM file format).
http://dicom.nema.org/

1860

1865

DICOM PS 3.12 Media Formats and Physical Media for Data Interchange, Annex F - 120mm
CD-R media, Annex R - USB Connected Removable Devices, Annex V - ZIP File Over Media,
and Annex W - Email Media. http://dicom.nema.org/
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.
MDN: RFC 3798 Message Disposition Notification. http://www.rfc-editor.org/rfc/rfc3798.txt

3.32.4 Interaction Diagram
PortableMedia
CreatorPortable
Media
Importer
Distribute Document
Set on Media

1870

Rev. 9.0 Final Text – 2012-08-31

85

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.32.4.1 Distribute Document Set on MediaThis transaction defines the interchange of XDS document submission sets on media. It
specifies the requirements for a directory structure, and the physical media where stored.
1875

1880

1885

1890

1895

1900

The file directory structure restrictions and file organization are specified below. These are basedon industry standard file systems with restrictions chosen based on experience with demonstrated
interoperability in the field of reliable exchange. These are defined in Part 10 of the DICOM
standard and summarized below.
The media that are supported are:• CD-R media. The physical media specification used for the storage on CD-R is a restrictedsubset of the widely used CD-R media. The restrictions were chosen to ensureinteroperability and media reliability. The standard directory and file structure can berecorded to the CD-R media by widely available software, but this software must be set tocomply with the interoperability restrictions on recording format. This media specification
relies on the healthcare experience gained by CD-R media widely used in radiology andcardiology. It is defined by Annex F in Part 12 of the DICOM standard and is also used in
the IHE Radiology PDI profile for the interchange of images,• USB Removable Devices. This media specification encompasses a wide range of USB
connected flash media, removable storage devices, etc. The standard directory and filestructure can be recorded onto any of these media by any system that supports the USB
Removable Device type defined by the USB Implementers Forum. This specification isdefined in Annex R in Part 12 of the DICOM standard.
• Email transport of ZIP files. This media specification defines the encoding of the directoryand file structure as an ordinary ZIP file (maintaining the directory structure) and attaches
that ZIP file to an email message. Some additional constraints are added to the email
message header to facilitate recognizing the message. This specification is defined in theannexes to part 12 of the DICOM standard called: ZIP File Media and Email media. The ZIP
over Email Response option enables the Portable Media Importer to send an
acknowledgment message to the Portable Media Importer.
3.32.4.1.1 Trigger Events
The user at the Portable Media Creator wishes to transport information by the creation andtransport of interchange media. The Portable Media Creator assembles the Interchange Media
content and stores it on the media.

1905

If the ZIP over Email Response option is supported, the Portable Media Importer shall detect
whether the Import was successful or not.
3.32.4.1.2 Message Semantics
The message semantics of this transaction are described in terms of content specifications for the
media.

Rev. 9.0 Final Text – 2012-08-31

86

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

1910

The Portable Media Creator shall be able to include one or multiple Submission Set(s), including
document(s) and associated metadata. Additionally it shall include a README.TXT file and an
INDEX.HTM and associated files for use to display the media content using a simple browser. It
may include other files and directories that the Portable Media Importer will ignore.
3.32.4.1.2.1 Media File system and File Naming Restrictions

1915

1920

1925

The following restrictions are needed to ensure broad interoperability:• Strict ISO 9660 Level 1 compliance for filenames and directories, even on non-CDR media.
• Strict ISO 9660 Level 1 compliance for recording methods on CDR media. This means nopacket writing.
• Filenames should not be in lower case, nor have lower case equivalent file names encoded as
Joliet or Rock Ridge extensions to the ISO 9660 file system.
• Only file and folder names referenced by the DICOMDIR file are restricted to 8 characterswith no extension. Specifically, it is not permitted to name DICOM files based on their SOP
Instance UID, since that would exceed the 8 character limit and use the illegal periodcharacter, and it is not permitted to add a “.dcm” extension or similar.
Note:

Refer to RAD TF-3: Appendix E of the IHE Radiology Technical Framework for a reference to common
implementation misinterpretations and/or errors that are detrimental to interoperability.

3.32.4.1.2.2 Content Organization Overview

Entry for the web content
Entries for the content the submissions sets
Other content not covered by the profile
Figure 3.32.4.1-1: General structure of the media

1930

1935

The media shall contain at the “root” directory level, as shown in the figure above:• An IHE_XDM directory.
• Two files for helping to access the content of the media: README.TXT and INDEX.HTM• An Autorun file or equivalent shall not be present in the root directory. Executable files may
be present, but shall not be configured to start automatically.
As shown in the figure above, the IHE_XDM directory shall contain one sub-directory per
submission set included on the media.
There may be other files present on the media for other purposes, (e.g., use in compliance with
the IHE Radiology PDI profile). The presence or absence of these files shall not affectperformance of this transaction.
Rev. 9.0 Final Text – 2012-08-31

87

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________XDS Metadata
Other file ignored by the metadata
Simple part document
Multi part document
1940

1945

1950

1955

Figure 3.32.4.1-2: Structure of a submission set directory on the media

As shown on the figure above, each submission set directory shall contain:• A METADATA.XML file containing the XDS Registry metadata, as described in ITI TF-3:
4.1.7 Document Definition Metadata. This shall include all of the metadata that is specified
for a Register Document Set-b [ITI-42]. This may include XDSFolder objects, associations,and other metadata contents. There is no relationship between an XDSFolder and a media
directory, although some people do call media directories “folders”. The metadata for thesubmission set shall include unique and different submissionTime.
• One file for each “simple part” document referenced in the metadata as an
XDSDocumentEntry• One sub-directory for each “multipart” document referenced in the metadata as an
XDSDocumentEntry (see ITI TF-3: Table 4.1-5, attribute mimeType set to“multipart/related”)• Potentially other files and directories that are ignored by the Portable Media Importer
The “multipart” document shall be structured as one sub-directory containing all the parts as file,including the “start” part corresponding to the main file to be open by the “multipart” document
viewer. An example of “multipart” document is shown in Figure 3.32.4.1-3.

Start part (main file)
Other part (file)Figure 3.32.4.1-3: Structure on the media of a directory which is functionally equivalent toa “XDS multipart document”

1960

1965

1970

The URI element of the metadata describing a file that is present on this media shall point to thefile containing the document, through a relative URL which corresponds to the file name forsimple part document and to the concatenation of the sub-directory and the main file name for“multipart” document (e.g., DOC00002/DOC00002.XML). Note that in cases where the files are
not located within this media directory for the Submission Set, it is possible that the relative
URL may begin with “../” so that a single copy the document can be present for multiple
purposes.
In Figure 3.32.4.1-2, the METADATA.XML file of the Submission Set stored in the SUBSET01
directory will contain many XDSDocumentEntry objects having their elements set as follows(see Table 4.1-5, URI attribute for details):<ExtrinsicObject id="Document1" mimeType="text/xml"... (with URI set to“DOC00001.XML”)

Rev. 9.0 Final Text – 2012-08-31

88

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________<ExtrinsicObject id="Document2" mimeType="text/xml"... (with URI set to“DOC00002/DOC00002.XML”)

1975

The file named INDEX.HTM in the root directory shall be encoded in compliance with the
XHTML Basic recommendation from W3C. It may contain a description of the submission sets,
including especially:• Patient ID and demographics• Source Facility information
Note:

1980

XDM Distribute Document Set on Media Transaction does not require that all the submission sets included in the
media are relative to the same patient.

It may also describe other content which is on the media, including the means to launch any
executable that may be present on the media.

1985

1990

1995

2000

There shall also be a README.TXT file located in the root directory that shall contain:• Contact information regarding the Institution that created the media.
• Information regarding the Application that created the media.
• Name of the product application and software version• Contact information of the vendor of the application that created the media• General information about the overall organization of the interchange media. This is notintended to be specific to the content stored on this instance of interchange media, which if
necessary should be placed in the INDEX.HTM file.
• Information regarding the Media Viewer application (if a Media Viewer is contained)• Operating system(s) supported• Name of the product application and software version• Contact information of vendor that provided the Media Viewer application• Disclaimer statement about the intended usage of the application• List of minimum requirements• Additional information regarding the usage of the application
Note that generally the README.TXT file is independent of the clinical content of the media,
i.e., the same README.TXT may be included on all media created by that application at that
institution. Experience has shown that this kind of README.TXT file is very valuable forresolving problems.
In addition, if the Portable Media Creator implements support for the Web Content Option of the
PDI Profile then the INDEX.HTM file must meet the requirements of the PDI Profile Web
Content Option.

2005

The INDEX.HTM file located in the root directory shall contain:•••

An informative header containing:
Identification of the institution that created the interchange media
Optionally, a disclaimer statement about privacy/security from the institution that created theinterchange media

Rev. 9.0 Final Text – 2012-08-31

89

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2010

•
•
•
•

2015

•

•

a link to an entry point for accessing the web content of the IHE_PDI directorya link to the README.TXT filea link to additional non-constrained data (if it exists)a manifest which lists the data that can be imported by a Portable Media Importer Actor. (i.e.,
all DICOM content on the media)
a manifest which lists any patient-related data contained on the CD that cannot be imported(i.e., additional non-constrained content that doesn’t have an importable DICOM equivalenton the media).
a link to a launch point for a DICOM viewer, if present on the interchange media

3.32.4.1.2.3 Response message
2020

2025

2030

If the ZIP over Email Response option is supported and a response was requested, thePortable Media Importer shall send a response, based on the [MDN] mechanism, dependingof the success of the Import operation:••

Success: the MDN “disposition-type” field is set to “displayed”
Error: the MDN “disposition-type” field is set to “deleted” and the MDN “dispositionmodifier” is set to “Error: xxxx” where “xxxx” is the text detailing the error.
Note 1:

Older implementations of MDN might use “processed” instead of “display”. The current RFC has removed thisoption but Portable Media Creator should be prepared to receive it. If they receive it, they have to look in theerror field to see whether there is an error.

Note 2:

The general mechanism for use of eMail is described in ITI TF-2x: Appendix T (Informative)

3.32.4.1.3 Media Identification
The Portable Media Creator actor may add a human-readable identification on the outside of thephysical medium, reflecting the originating institution, the time of the creation and content of themedia. The method of media marking is outside the scope of this transaction.

2035

If the ZIP over Email Response option is supported, Portable Media Creator shall be
configurable to include in its message header the request for a response:• “Disposition-Notification-To:”, followed by the email address to which Portable Media
Importer shall send the response
Then, the Portable Media Importer shall acknowledge this operation by sending a MDN responseto the email address included in the message.

2040

And finally, the Portable Media Creator shall consider that the import is successful unless:• the disposition-modifier contains the word “error” or “failure”, case insensitive.
Note: This transaction does not specify how errors should be processed because the variety of
appropriate responses is too great.

2045

If the ZIP over Email option is supported, the subject line of the email shall contain the phrase:• XDM/1.0/DDM

Rev. 9.0 Final Text – 2012-08-31

90

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Note:

In case the same Email complies also with the DICOM Email, it is recommended that the subject contains thephrase: XDM/1.0/DDM+DICOM-ZIP

3.32.4.1.4 Expected Actions
2050

2055

The Portable Media Importer shall verify the integrity of the media by comparing their size andhash with the value of the corresponding entries in the METADATA.XML file of the relevant
submission set directory. Mismatching documents shall be indicated to the user. Media faults
shall be indicated to the user.
If the XDM Portable Media Importer is grouped with a Content Consumer of one or more IHE
Content Profiles, that actor is able to perform its processing on the documents it is designed tosupport.
Note:

This awkward phrasing means that ability to process data on portable media is described by saying that theprocessing actor is grouped with a Portable Media Importer actor.

3.32.4.1.4.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:
2060

2065

2070

2075

2080

1. The Portable Media Creator actor shall populate the confidentialityCode in the document
metadata with the list of values that identify the sensitivity classifications that apply tothe associated document. All documents submitted shall have confidentiality codes. The
confidentiality codes for different documents in the same submission may be different.
2. The Portable Media Creator actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the policies. The details of this are product specific and not
specified by IHE.
3. The Portable Media Creator actor may have user interface or business rule capabilities todetermine the appropriate confidentiality codes for each document. The details of this areproduct specific and not specified by IHE.
4. The Portable Media Importer actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the policies. The meanings of the codes on the media must be
provided out of band, e.g., by telephone, fax, or email. The detail of how this is done isproduct specific and not specified by IHE. If the documents are transferred internallywithin the organization or to other members of the recipient's affinity domain, appropriate
internal confidentiality codes shall be applied.
5. The Portable Media Creator actor shall be able to publish the consent documents and any
applicable digital signatures that apply to the collection of content that it has created on
portable media.
6. The Portable Media Importer actor shall have the ability to coerce the confidentiality
code in the metadata associated with the document from the codes used by the Exporterto the codes used by the Importer.

Rev. 9.0 Final Text – 2012-08-31

91

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2085

2090

2095

2100

The Portable Media Importer actor shall abide by the XDS Affinity Domain Policies represented
by the confidentialityCode in the metadata associated with the document. The Portable MediaCreator actor likely will have user access controls or business rule capabilities to determine thedetails of how confidentiality codes apply to query results. The details of this are product specificand not specified by IHE. These rules shall reduce the query results to only those that areappropriate to the current situation for that actor and user.
3.32.4.1.5 Security considerations
In the case of physical media, encryption of the CD-R or USB shall not be used.
If the ZIP over Email option is supported, the transaction shall be secured by S/MIME (seeIHE ATNA) and comply with the security process as defined in the DICOM Part 15 Appendix(Secure Use of ZIP File Media over Email). The security process requires the use of S/MIME
to both encrypt and sign the message. The encryption is used to maintain confidentiality during
the transport. The signature is used to maintain integrity during transport and indicates that thesender is authorized to send the message.
Portable Media Creators that create media shall generate one or more ATNA “Export” events
into the audit trail to describe the media creation event. These events shall describe eachsubmission set and/or study that is exported.
Portable Media Importers that import media shall generate one or more ATNA “Import” events
into the audit trail to describe the media import event. These events shall describe eachsubmission set and/or study that is imported.

2105

2110

Note:

It is easy to build a partial implementation of actors in the XDM profile that lack the auditing capability. For
example, a person can manually create media that comply with the requirements of the XDM media. It is
possible that the manual process omits the generation of audit records for their activity. This would not be acompliant or complete implementation of the actors, but it is easy to make this kind of mistake.

The Portable Media Importer shall check the hash value and size as found in the XDS metadata
to detect corruption within the metadata or media. The Portable Media Importer shall notify theuser if any errors are detected.

3.33 Intentionally Left Blank
3.34 Retrieve Form
This section corresponds to Transaction ITI-34 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-34 is used by the Form Filler and Form Manager actors.
2115

2120

3.34.1 Scope
This transaction involves a Form Filler requesting a form from a Form Manager. The Form Filler
has a formID, and possibly additional workflow information, obtained by a means that is outside
the scope of this transaction. The Form Filler may also provide a form instance id to reference a
previously submitted form. The Form Manager will return a form or URL corresponding to thegiven formID, and optionally a form instance id, or else it returns an error response. Forms aredefined and constrained below by the format options.

Rev. 9.0 Final Text – 2012-08-31

92

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.34.2 Use Case Roles
Form Manager

Form Filler

Retrieve Form

2125

Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form Manager
Role: A system that provides forms based upon requests that provide specific formIDs, andoptionally additional work flow data.

2130

3.34.3 Referenced Standards
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html

2135

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.
ITI TF-2x: Appendix V Web Services for IHE Transactions
XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xforms11-20041115/

2140

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.

2145

http://www.w3.org/TR/xhtml-basic

Rev. 9.0 Final Text – 2012-08-31

93

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.34.4 Interaction Diagram
Form
ManagerForm Filler

Retrieve Form
RequestRetrieve Form
Response

3.34.4.1 Retrieve Form Request
2150

Retrieve Form involves a Form Filler requesting a form from a Form Manager. The Form Filler
shall supply workflow data and prepopulation data. The Form Filler may also supply a form
instance id.
The Retrieve Form Request shall provide an archiveURL value, as a nil value or as a URL
pointing to a Form Archiver actor. See ITI TF-2b: 3.34.4.1.2 for details.

2155

2160

The Form Filler requests that Form Filler use context information in the selection and/or creationof the returned form by supplying the prepopData argument with well-formed xml representing
the Form Filler context. Specification of the prepopData schema is left to content profiles. Thisvalue may be nil.
The Form Filler supplies any additional workflow information to be used in the selection and/or
creation of the form using the context element of the workflowData parameter. Specification ofthis context element is left to content profiles.
The response to a Retrieve Form Request returns the form, or reference to a form, and may
return a form instance id.
3.34.4.1.1 Trigger Events

2165

The Form Filler, based upon human decision or application of a rule for automatic operation,
requests a form hosted by a Form Manager.
3.34.4.1.2 Message Semantics

2170

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions. The following parameters are specified for thistransaction.

Rev. 9.0 Final Text – 2012-08-31

94

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Description

Value

prepopData

Parameter NameR

REQ

The xml context information supplied
by a Form Filler for use in prepopulating form fields

This value shall be nil or a wellformed xml document.

workflowDataR

The xml representation of workflow
specific values.

This value is a well-formed xml
document.as defined below.

formIDR

The identifier of a form.

A string identifying the form

encodedResponseR

Tells the Form Manager whether or
not to return an encoded response{true,false}archiveURL

R

Tells the Form Manager whether or
not the Form Filler is exercising theArchive Option

the URL of any Form Filler
identified Form Archiver or thenull string

context

R

The xml specifics of workflow
context

Defined by content profiles; maybe nilinstanceIDR

An id value of a previously submitted
instance of data.

A string identifying an instanceof previously submitted data;
may be nil.

The contents of the prepopData parameter is defined in a prepopData schema specified by IHE
content profiles. When there is no prepopData the attribute xsi:nil shall be set to “true” (see thesupport materials).
2175

The content of workflowData parameter shall minimally be:

2180<workflowData><formID>a String identifying the form</formID><encodedResponse>false</encodedResponse><archiveURL /><context/><instanceID/></workflowData>

2185

See the schema provided with the support materials(ftp://ftp.ihe.net/TF_Implementation_Material/ITI/). The workflowData may be extended by IHE
content profiles with further definition of the <context> element.
3.34.4.1.3 Expected Actions

2190

2195

Upon receipt of the Retrieve Form request, the Form Manager shall parse the request and shallreturn the requested response in the RetrieveFormResponse element, or errors with SOAP Faults.
The Form Manager shall return the form or URL based on the values of: a) the
encodedResponse; b) the formID; c) any additional workflowData; d) the optionally supplied
instanceID.
If encodedResponse is ‘true’, then the response from the Form Manager shall be either a
Structured (XML) or Unstructured (non-XML) element. When the encodedResponse parameteris 'true', all anchor addresses that are not fragment identifiers shall be composed of absolute
URIs.

Rev. 9.0 Final Text – 2012-08-31

95

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
If encodedResponse is ‘false’, then the response from the Form Manager shall be a URL elementthat can be used directly by a web browser for retrieval and operation of the form.
The Form Manager may assign and return a value for a form instanceID.
2200

When the Form Filler provides a valid URL in the archiveURL parameter of the request, theForm Manager shall return a form that shall perform an Archive Form transaction upon form
submission, in addition to any predefined actions associated with the form submission. As shownin ITI TF-2b: 3.36 Archive Form, this additional archival transaction is between Form Filler andForm Archiver actors.

2205

When the Form Filler supplies data in the prepopData parameter, the Form Manager may use thisinformation to determine the form to be returned and to pre-populate the fields of the form. The
exact use of the prepopData, and the structure, is deferred to the publication of an IHE content
profile.

2210

2215

The Form Manager shall use the values within the workflowData parameter, as well as theoptionally supplied instanceID, to determine the form to be returned and to pre-populate thefields of the form.
The value of the formID has been previously assigned by the Form Manager to identify a form to
be returned to the Form Filler using one of the named format options. A Form Manager may
support multiple named options, but for each formID there is only one named option that is
supported.
The Form Manager shall use the SOAP Faults defined in Table 3.34.4.1.3-1 when appropriate.
Form Fillers shall be capable of accepting other values beyond the ones specified here.
Table 3.34.4.1.3-1:
Description of error

2220

2225

2230

Code

Reason Text

There is missing information, such as no formID

SenderRequired Information Missing

No form is available

SenderUnknown formID

An example of a SOAP Fault is:<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Required Information Missing</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>Rev. 9.0 Final Text – 2012-08-31

96

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.34.4.1.4 Security Considerations
2235

As noted in the mitigations section of ITI TF-1: 17.5 Security Considerations, endpoints are free
to implement TLS as needed for additional privacy and protection. Content Profiles, based upon
the nature of the data, may need to require use of ATNA.
3.34.4.2 Retrieve Form Response
3.34.4.2.1 Trigger Events

2240

This message is triggered by a Form Manager actor responding to a Retrieve Form request.
3.34.4.2.2 Message Semantics
The form or URL is returned.
3.34.4.2.3 Expected Actions

2245

The Form Filler shall retrieve from the URLvalue returned if the Retrieve Form
encodedResponse value was false.
Regardless of the Retrieve Form encodedResponse value, the Form Filler may fill any form
fields needed for form submission, and may display the form for user interaction.
3.34.4.2.3.1 XHTML Handling

2250

A Form Manager shall return a form, whether returned as the response or referenced by areturned URL, formatted as XHTML using XHTML Basic and W3C HTML Compatibility
Guidelines provided in the Appendix C of the W3C XHTML 1.0 Recommendation. The returned
form shall support the Submit and all required Archive transactions.
3.34.4.2.3.2 XForm Option

2255

2260

A Form Manager that supports the XForms option shall additionally be capable of returning aform, whether returned as the response or referenced by a returned URL, that conforms to
XForms 1.1. The host language for the XForm shall be XHTML Basic according to the W3C
HTML Compatibility Guidelines provided in the Appendix C of the W3C XHTML 1.0
Recommendation. The returned form shall support the Submit and all required Archive
transactions.
3.34.5 Protocol Requirements
The Retrieve Form request and response shall be transmitted using Synchronous Web Services
Exchange, according to the requirements specified in ITI TF-2x: Appendix V.
The Retrieve Form transaction shall use SOAP 12.

Rev. 9.0 Final Text – 2012-08-31

97

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2265

2270

2275

2280

2285

WSDL Namespace Definitions
ihe

urn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

These are the requirements for the Retrieve Form transaction presented in the order in which
they would appear in the WSDL definition:• The following types shall be imported (xds:import) in the /definitions/types section:• Namespace=”urn:ihe:iti:rfd:2007”, schema=”RFD.xsd”• The /definitions/message/part/@element attribute of the Retrieve Form Request message
shall be defined as: “ihe:RetrieveFormRequest”• The /definitions/message/part/@element attribute of the Retrieve Form Response message
shall be defined as: “ihe:RetrieveFormResponse”• The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Form
Request message shall be defined as “urn:ihe:iti:2007:RetrieveForm”• The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Form
Response message shall be defined as: “urn:ihe:iti:2007:RetrieveFormResponse”• The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be definedas “urn:ihe:iti:2007:RetrieveForm”
These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.34.5.1 Sample SOAP Messages.
For informative WSDL for the Form Manager see ITI TF-2x: Appendix W. A full XML Schema
Document for the RFD types is available online on the IHE FTP site
(ftp://ftp.ihe.net/TF_Implementation_Material/ITI/).
3.34.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,2290<MessageID/>, .; these WS-Addressing headers are populated according to ITI TF-2x: Appendix
V: Web Services for IHE Transactions. Some of the body of the SOAP message is omitted forbrevity.
3.34.5.1.1 Sample Retrieve Form SOAP Request

2295<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>

Rev. 9.0 Final Text – 2012-08-31

98

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2300

2305

2310

2315

<wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveForm</wsa:Action></soap:Header><soap:Body><RetrieveFormRequest xmlns="urn:ihe:iti:rfd:2007"><prepopData>...some xml content...</prepopdata><workflowData><formID>1</formID><encodedResponse>false</encodedResponse><archiveURL /><context /><instanceID /></workflowData></RetrieveFormRequest></soap:Body></soap:Envelope>3.34.5.1.2 Sample Retrieve Form SOAP Response<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"

2320

2325

2330

2335

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveFormResponse</wsa:Action></soap:Header><soap:Body><RetrieveFormResponse xmlns="urn:ihe:iti:rfd:2007"><form><URL>http://somehost/xxx/services/someForm</URL><instanceID>1.2.3.4.5</instanceID></form><contentType /><responseCode /></RetrieveFormResponse></soap:Body></soap:Envelope>3.35 Submit Form
2340

This section corresponds to Transaction ITI-35 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-35 is used by the Form Filler and Form Receiver actors.
3.35.1 Scope
This transaction involves a Form Filler submitting a form to a Form Receiver.

Rev. 9.0 Final Text – 2012-08-31

99

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2345

3.35.2 Use Case Roles
Form ReceiverForm Filler

Submit Form

Actor: Form Filler
2350

Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form Receiver
Role: A system that receives submitted forms.
3.35.3 Referenced Standards

2355

IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
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.
ITI TF-2x: Appendix V Web Services for IHE Transactions

2360

Rev. 9.0 Final Text – 2012-08-31

100

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.35.4 Interaction Diagram
Form
ReceiverForm Filler

Submit Form [ITI-35]

Ack/Nak response

3.35.4.1 Submit Form
2365

This transaction is initiated by a Form Filler submitting form instance data, using XML as aformat, to a Form Receiver.
3.35.4.1.1 Trigger Events
The Submit Form transaction is triggered by the submission action from within the form.
3.35.4.1.2 Message Semantics

2370

The Submit Form transaction is performed by invocation of a Web Service call using SOAP, by
the Form Filler, submitting the form instance data (XML) to a Form Receiver. See section 11.19
Integration with SOAP (http://www.w3.org/TR/2006/WD-xforms11-20061212/#submit) for
submitting from within XForms.
3.35.4.1.3 Expected Actions

2375

The Form Receiver shall return the HTTP response code 200 – OK to indicate success. If theForm Receiver cannot recognize the posted data, then the Form Receiver shall return the HTTP
response code 400 – Bad Request.
The Form Filler may display the results of the response from the Form Receiver.

2380

3.36 Archive Form
This section corresponds to Transaction ITI-36 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-36 is used by the Form Filler and Form Archiver actors.

Rev. 9.0 Final Text – 2012-08-31

101

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.36.1 Scope
This transaction involves a Form Filler submitting form instance data to a Form Archiver.
2385
3.36.2 Use Case Roles
Form Archiver

Form Filler

Archive Form

2390

Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form ArchiverRole: A system that receives submitted forms for archival purposes.
3.36.3 Referenced Standards

2395

IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
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.

2400

ITI TF-2x: Appendix V Web Services for IHE Transactions

Rev. 9.0 Final Text – 2012-08-31

102

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.36.4 Interaction Diagram
Form
ArchiverForm Filler

Archive Form [ITI-36]

Ack/Nak response

3.36.4.1 Archive Form
2405

This transaction is initiated by a Form Filler submitting a data to a Form Archiver for archival
purposes.
3.36.4.1.1 Trigger Events

2410

The Form Filler shall use this transaction to submit data to a Form Archiver for archival
purposes. The Archive Form transaction may be initiated by a Form Filler, or it may be triggered
as a secondary submission action from within a form.
3.36.4.1.2 Message Semantics

2415

The Archive Form transaction is performed by invocation of a Web Service call using SOAP, by
the Form Filler, submitting the form instance data (XML) to a Form Archiver. See section 11.19
Integration with SOAP (http://www.w3.org/TR/2006/WD-xforms11-20061212/#submit) for
submitting from within XForms.
3.36.4.1.3 Expected Actions
The Form Archiver shall return the HTTP response code 200 – OK to indicate success.
The transaction data shall be saved by the Form Archiver.

2420

If the Form Archiver fails to save the data then the Form Archiver shall return the HTTP
response code 500 – Internal Server Error.
If the Form Archiver cannot recognize the request, then the Form Archiver shall return the HTTP
response code 400 – Bad Request.
The Form Filler may display the response from the Form Archiver.

Rev. 9.0 Final Text – 2012-08-31

103

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.37 Retrieve Clarifications
2425

This section corresponds to Transaction ITI-37 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-37 is used by the Form Filler and Form Manager actors.
3.37.1 Scope

2430

2435

This transaction involves a Form Filler requesting a set of clarifications from a Form Manager. A
Form Filler supporting the Retrieve Clarifications option shall perform this request periodically,
based upon a duration defined by or agreed upon with the Form Manager / Form Receiver. Notethat not all use cases will need to support this option.
The Form Filler has an orgID, obtained by a means that is outside the scope of this transaction,and the Form Manager will either return a form that contains either the data to be clarified or aset of links to other forms that can be retrieved using the Retrieve Form transaction. All updates/ clarifications / new data are submitted to the Form Receiver using the Submit Form transaction.
3.37.2 Use Case Roles
Form Filler

Form Manager

Retrieve
Clarifications

2440

Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form Manager
Role: A system that provides clarification information based upon requests that provide specificorgIDs.

2445

3.37.3 Referenced Standards
IETF RFC1738, Uniform Resource Locators (URL), December 1994,
http://www.faqs.org/rfcs/rfc1738.html
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1

2450

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.
ITI TF-2x: Appendix V Web Services for IHE Transactions
XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xforms11-20041115/
Rev. 9.0 Final Text – 2012-08-31

104

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.37.4 Interaction Diagram
Form
ManagerForm Filler

Retrieve Clarifications Request

Retrieve Clarifications
Response

2455
3.37.4.1 Retrieve Clarifications Request
This transaction is initiated whenever a Form Filler which supports the Retrieve Clarifications
option needs to obtain clarification information relevant to the organization or site.
2460

3.37.4.1.1 Trigger Events

2465

The Retrieve Clarification event is triggered by the need for information on current clarifications
to be made available within an EHR system. The transaction does not specify when the Retrieve
Clarification happens, only that this transaction is available when information regarding
clarifications is needed from a Form Manager. It is the responsibility of the Form Filler that
supports this option to periodically execute this transaction.
3.37.4.1.2 Message Semantics
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
The following parameters are specified for this transaction.

2470
Parameter Name

REQ

clarificationData

R

orgID

R

Rev. 9.0 Final Text – 2012-08-31

Description

Value

The xml representation ofclarification specific values.

This value is a well-formed
xml document.as defined
below.
A string identifying theorganization

105

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Parameter Name

REQ

Description

Value

encodedResponseR

Tells the Form Manager whether
or not to return an encoded
response{true,false}archiveURL

R

Tells the Form Manager whether
or not the Form Filler is
exercising the Archive Option

the URL of any Form Filler
identified Form Archiver; maybe nilcontext

R

The xml specifics of workflow
context

Defined by content profiles;
may be nil

The clarificationData may be extended by IHE content profiles with further definition of the<context> element. The content of clarificationData shall minimally be:
2475

2480

<clarificationData><orgID>a String identifying the form</orgID><encodedResponse>false</encodedResponse><archiveURL /><context/></clarificationData>

3.37.4.1.3 Expected Actions
Upon receipt of the Retrieve Clarifications request, the Form Manager shall parse the request andshall return the requested response in the RetrieveClarificationsResponse element, or errors with
SOAP Faults.

2485

The Form Manager shall return the form or URL based on the values of: a) the
encodedResponse; b) the orgID; c) any additional clarificationData.
If no clarification information is available, this is shall be indicated by a form indicating that noclarification information is available.

2490

If encodedResponse is ‘true’, then the response from the Form Manager shall be either a
Structured (XML) or Unstructured (non-XML) element, based upon the formatOption. When theencodedResponse parameter is 'true' all anchor addresses that are not fragment identifiers shallbe composed of absolute URIs.
If encodedResponse is ‘false’, then the response from the Form Manager shall be a URL elementthat can be used directly by a web browser for retrieval and operation of the form.

2495

The value of the orgID has been previously assigned by the Form Manager and identifies use oneof the named format options. A Form Manager may support multiple named options, but foreach orgID there is only one named option that is supported.
The Form Manager shall use the SOAP Faults defined in Table 3.37.4.1.3-1 when appropriate.
Form Fillers shall be capable of accepting other values beyond the ones specified here.

2500

Rev. 9.0 Final Text – 2012-08-31

106

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.37.4.1.3-1: SOAP Faults
Description of error

Code

There is missing information, such as no orgID
No form is available

SenderSenderReason Text
Required Information Missing
Unknown orgID

An example of a SOAP Fault is:
2505

2510

2515

2520

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace"><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Unknown orgID</env:Text></env:Reason></env:Fault></env:Body></env:Envelope>

The orgID has been assigned by the Form Manager use one of the named format options. A
Form Manager may support multiple named options, but for each orgID there is only one named
option that is supported.
3.37.4.1.4 Security Considerations
The security considerations for the Retrieve Clarifications request message are no different thanthose of the Retrieve Form request message. See ITI TF-2b: 3.34.4.1.4.
3.37.4.2 Retrieve Clarifications Response

2525

3.37.4.2.1 Trigger Events
The Delivery of a Form is triggered by a Form Manager actor providing a form based upon theorgID supplied with the Retrieve Clarifications transaction.
3.37.4.2.2 Message Semantics
The form or URL is returned in response to the Retrieve Clarifications.

2530

3.37.4.2.3 Expected Actions
The Form Filler may display the form or navigate to the returned URL to retrieve the form.

Rev. 9.0 Final Text – 2012-08-31

107

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.37.4.2.3.1 XHTML Handling

2535

A Form Manager shall return a form, whether returned as the response or referenced by areturned URL, formatted as XHTML using XHTML Basic and W3C HTML Compatibility
Guidelines provided in the Appendix C of the W3C XHTML 1.0 Recommendation. The returned
form shall support the Submit and all required Archive transactions.
3.37.4.2.3.2 XForm Option

2540

A Form Manager that supports the XForms option shall additionally be capable of returning aform, whether returned as the response or referenced by a returned URL, that conforms to
XForms 1.1. The host language for the XForm shall be XHTML Basic according to the W3C
HTML Compatibility Guidelines provided in the Appendix C of the W3C XHTML 1.0
Recommendation. The returned form shall support the Submit and all required Archive
transactions.
3.37.5 Protocol Requirements

2545

The Retrieve Clarifications request and response shall be transmitted using Synchronous Web
Services Exchange, according to the requirements specified in ITI TF-2x: Appendix V.
The Retrieve Clarifications transaction shall use SOAP 12.
WSDL Namespace Definitions

2550

2555

2560

ihe

urn:ihe:iti:rfd:2007

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2005/08/addressing

xsd

http://www.w3.org/2001/XMLSchema

These are the requirements for the Retrieve Clarifications transaction presented in the order inwhich they would appear in the WSDL definition:• The following types shall be imported (xds:import) in the /definitions/types section:• Namespace=” urn:ihe:iti:rfd:2007”, schema=”RFD.xsd”• The /definitions/message/part/@element attribute of the Retrieve Clarifications Request
message shall be defined as: “ihe:RetrieveClarificationsRequest”• The /definitions/message/part/@element attribute of the Retrieve Clarifications Response
message shall be defined as: “ihe:RetrieveClarificationsResponse”• The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve
Clarifications Request message shall be defined as “urn:ihe:iti:2007:RetrieveClarifications”• The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve
Clarifications Response message shall be defined as:“urn:ihe:iti:2007:RetrieveClarificationsResponse”• The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be definedas “urn:ihe:iti:2007:RetrieveClarifications”

Rev. 9.0 Final Text – 2012-08-31

108

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2565

2570

These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.34.5.1 Sample SOAP Messages.
For informative WSDL for the Form Manager see ITI TF-2x: Appendix W. A full XML Schema
Document for the RFD types is available online on the IHE FTP site
(ftp://ftp.ihe.net/TF_Implementation_Material/ITI/).
3.37.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, …; these WS-Addressing headers are populated according to2575

ITI TF-2x: Appendix V: Web Services for IHE Transactions.
3.37.5.1.1 Sample Retrieve Clarifications SOAP Request

2580

2585

2590

2595

2600

2605

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveClarifications</wsa:Action></soap:Header><soap:Body><RetrieveClarificationsRequest xmlns="urn:ihe:iti:rfd:2007"><clarificationData><orgID>123</formID><encodedResponse>false</encodedResponse><archiveURL /><context /></clarificationData></RetrieveClarificationsRequest></soap:Body></soap:Envelope>

3.37.5.1.2 Sample Retrieve Clarifications SOAP Response<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>

Rev. 9.0 Final Text – 2012-08-31

109

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2610

2615

2620

<wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveClarificationsResponse</wsa:Action></soap:Header><soap:Body><RetrieveClarificationsResponse xmlns="urn:ihe:iti:rfd:2007"><form><URL>http://somehost/xxx/services/someForm</URL></form><contentType /><responseCode /></RetrieveClarificationsResponse></soap:Body></soap:Envelope>3.38 Cross Gateway Query
This section corresponds to Transaction 38 of the IHE Technical Framework. Transaction 38 isused by cooperating Initiating Gateway and Responding Gateway actors.
2625

2630

2635

2640

2645

3.38.1 Scope
The scope of the Cross Gateway Query transaction is based on the Registry Stored Query
transaction [ITI-18]. The same set of stored queries is required to be supported and the options
controlling what kind of data is returned are the same. Differences from the Registry Stored
Query transactions are:
• The Cross Gateway Query is between an Initiating Gateway and Responding Gateway.
• Initiating Gateway shall specify the homeCommunityId attribute in all Cross-Community
Queries which do not contain a patient identifier.
• The homeCommunityID attribute shall be returned within all appropriate elements.
• Responding Gateways shall support the Asynchronous Web Services Exchange Option on
the Cross Gateway Query. Support for this function is required in order to enable use of
Asynchronous Web Services Exchange in any cross-community interaction. Without this
support an Initiating Gateway would require unique configuration, per Responding Gateway,
to know if Asynchronous Web Services Exchange was supported. It is expected that
Asynchronous Web Services Exchange will be desired by the majority of communities.
• Asynchronous Web Services Exchange is an option on the Initiating Gateway, see ITI TF-1:
18.2.2.
• For stored queries that rely on concepts that a community may not support, namely
associations, folders and submission sets, a Responding Gateway is allowed to respond withzero entries.
There shall be an agreed upon common coding/vocabulary scheme used for the Cross Gateway
Query. For example, a common set of privacy consent vocabularies shall be used.
3.38.2 Use Case Roles

Rev. 9.0 Final Text – 2012-08-31

110

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Initiating
Gateway

Responding
Gateway

Cross Gateway
Query

2650

Figure 3.38.2-1: Use Case Roles

Actor: Initiating Gateway
Role: To formulate a Cross Gateway Query on behalf of a user.
Actor: Responding Gateway
2655

Role: To respond to a Cross Gateway Query based on the internal configuration of thecommunity.
3.38.3 Referenced Standard
Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.

2660

ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

Appendix V

ITI TF-2x: Appendix V: Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

3.38.4 Interaction Diagram
Initiating
Gateway

Responding
Gateway

Cross Gateway Query
Request
Cross Gateway Query
Response

2665

Rev. 9.0 Final Text – 2012-08-31

111

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.38.4.1 Cross Gateway Query

2670

This is a query request between an Initiating Gateway and a Responding Gateway. The query
request contains:• A reference to a pre-defined query defined by the Registry Stored Query transaction [ITI-18].
• Parameters to the query. The query parameters are defined by the Registry Stored Query
transaction. The homeCommunityId attribute is required for every Registry Stored Query
which does not specify a patient identity.
3.38.4.1.1 Trigger Events

2675

This message is initiated when the Initiating Gateway has determined that it must interact with
the Responding Gateway to satisfy a Registry Stored Query [ITI-18] request received from an
XDS.b Document Consumer or a query request from other internal non-IHE actor. Wheninitiating this message to satisfy a Registry Stored Query [ITI-18] request the Initiating Gateway
shall pass all parameters, either known or unknown, into the Cross Gateway Query.
3.38.4.1.2 Message Semantics

2680

The message semantics are based on the Registry Stored Query. See ITI TF-2a: 3.18.4.1.2. Of
special note are the use of homeCommunityId, specifying the patient identifier and special
handling of some stored queries. These are explained below.
3.38.4.1.2.1 homeCommunityId

2685

2690

2695

2700

The homeCommunityId attribute is required on the Cross Gateway Query. The
homeCommunityId is a globally unique identifier for a community and is used to obtain the Web
Services endpoint of services that provide access to data in that community. homeCommunityId
is structured as an OID limited to 64 characters and specified in URI syntax, for example thehomeCommunityId of 1.2.3 would be formatted as urn:oid:1.2.3.
Its use is as follows:• It is returned within the response to Cross Gateway Query and Registry Stored Query
transactions to indicate the association of a response element with a community. It is
specified as the ebRIM 'home' attribute within the relevant response elements. Document
Consumers process the value as an opaque unique identifier.
• It is an optional parameter to Registry Stored Query requests, not requiring a patient id
parameter, and Retrieve Document Set requests to indicate which community to direct therequest.

The Initiating Gateway shall specify the homeCommunityId parameter within all queries which
do not include a patient identifier parameter. These would be queries which specify anentryUUID or uniqueID. The homeCommunityId shall contain the value that identifies thecommunity associated with the Responding Gateway. The homeCommunityId value is specified
as the home attribute on the AdhocQuery element of the query request, as in:<AdhocQuery id=”…” home=”urn:oid:1.2.3” … >Rev. 9.0 Final Text – 2012-08-31

112

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2705

Each Cross Gateway Query request can have at most one homeCommunityId value. If multiple
entryUUID or uniqueID values are specified they must all be associated with the same
homeCommunityId value. Multiple individual query requests can be used to retrieve dataassociated with different homeCommunityIds. This restriction is expected to be temporary as
query syntax is extended to handle multiple homeCommunityIds in a single query request.
3.38.4.1.2.2 Specifying patient identifier

2710

2715

The Initiating Gateway shall specify in relevant queries a patient identifier known to the
Responding Gateway. The mechanism used by the Initiating Gateway to determine the correct
patient identifier to use is outside the intended scope of this transaction. The Responding
Gateway can expect to be able to resolve the patient identifier. If the patient identifier is
unknown by the Responding Gateway’s community, the Responding Gateway shall return either
a successful response with no elements or an error with errorCode XDSUnknownPatientId,
depending on local policy.
3.38.4.1.2.3 Special handling of some stored queries

2720

Some stored queries rely on the support of concepts which may not be used within a community.
It is also possible that a Responding Gateway community may have policies which restrict thesharing of information related to those concepts. The concepts of concern are submission sets,folders and associations. In either case a Responding Gateway shall respond to the appropriate
stored queries by returning zero results. Table 3.38.4.1.2.3-1 lists all the stored queries which
rely on specialized concepts.
Table 3.38.4.1.2.3-1: Stored Queries
Query Name

Concepts

Requirement

FindDocuments

None

Required by all

FindSubmissionSets

Submission Set

Zero elements when no submission set concept in community

FindFolders

FolderZero elements when no folder concept in community

GetAllSubmission Set,
Folder,
Association

Return all appropriate document entries and other entries dependingon which of the other concepts the community supports

GetDocuments

None

Required by all

GetFolders

FolderZero elements when no folder concept in community

GetAssociations

Association

Zero elements when no association concept in community

GetDocumentsAndAssociations

Association

Return only document entries if no association concept

GetSubmissionSets

Submission Set

Zero elements when no submission set concept in community

GetSubmissionSetAndContents

Submission Set

Zero elements when no submission set concept in community

GetFolderAndContents

FolderZero elements when no folder concept in community

GetFoldersForDocument

FolderZero elements when no folder concept in community

GetRelatedDocuments

Association

Zero elements when no association concept in community

2725

Rev. 9.0 Final Text – 2012-08-31

113

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.38.4.1.3 Expected Actions
Actors supporting this transaction shall support the Expected Actions described in ITI TF-2a:3.18.4.1.3. In addition:
2730

2735

2740

2745

2750

2755

2760

2765

The Responding Gateway actor shall:• Return an XDSUnknownCommunity error code if the value of homeCommunityId isspecified and is not known by the Responding Gateway.
• Verify the homeCommunityId is specified on relevant queries and return an
XDSMissingHomeCommunityId error code if missing.
• Route the query to the local XDS Document Registry or perform equivalent action to form aquery response. When routing to a local XDS Document Registry, the Responding Gateway
shall pass all parameters into the Registry Stored Query [ITI-18] transaction.
• When routing a response from a local XDS Document Registry, the Responding Gateway
shall pass all entities received in the Registry Stored Query response into the response to the
Cross Gateway Query.
• Ensure that the response contains the value identifying the Responding Gateway’s
community for the homeCommunityId attribute in every appropriate element. The elementsthat shall include the ebRIM home attribute are:• If returntype=”LeafClass” the ExtrinsicObject and RegistryPackage elements shallcontain the home attribute.
• If returnType=”ObjectRef” the ObjectRef element shall contain the home attribute.
• Ensure that every RegistryError element returned in the response shall have the location
attribute set to the homeCommunityId of the Responding Gateway.
The Initiating Gateway actor shall:• On receiving the response from the Responding Gateway, verify the homeCommunityId ispresent where appropriate. If homeCommunityId is not present in any of theExtrinsicObject, RegistryPackage or ObjectRef elements the Initiating Gateway shall reflect
an XDSMissingHomeCommunityId to the initiator of the transaction – either the Document
Consumer or the internal actor. All XDSMissingHomeCommunityId errors generated by theInitiating Gateway shall include, in the context of the message, identification of the
RespondingGateway that returned the invalid response and the element or elements that werein error.
• If the XDS Affinity Domain Option is supported and if needed, consolidate results frommultiple Responding Gateways. This includes reflecting in the consolidated results returnedin response to the originating Registry Stored Query [ITI-18] all successes and failures
received from Responding Gateways. If both successes and failures are received from
Responding Gateways, the Initiating Gateway shall return both RegistryObjectList andRegistryErrorList in one response and specify PartialSuccess status. If an
XDSUnknownPatientId error is returned from a Responding Gateway then the Initiating
Gateway shall not include this error in the consolidated results sent to the Document
Consumer. The removal of the XDSUnknownPatientId is done to maintain compatibility
with the XDS profile’s use of Registry Stored Query since Document Consumers are not
Rev. 9.0 Final Text – 2012-08-31

114

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
expecting to receive this error. Other than removal of the XDSUnknownPatientId, theInitiating Gateway shall pass all entities received in the Cross Gateway Query response into
the response to the Registry Stored Query [ITI-18].
2770

3.38.4.1.4 Security Considerations
Both the Initiating Gateway and Responding Gateway shall audit the Cross Gateway Query. The
audit entries shall be equivalent to the entries required for the Registry Stored Query.

2775

2780

2785

The Initiating Gateway:• If receiving a Registry Stored Query transaction from a Document Consumer, shall audit as if
it were a Document Registry. See ITI TF-2a: 3.18.5.1.2.
• In addition, shall audit the Cross Gateway Query as if it were a Document Consumer exceptthat for EventTypeCode the Initiating Gateway shall specify EV(“ITI-38”, “IHE
Transactions”, and “Cross Gateway Query”). See ITI TF-2a: 3.18.5.1.1.
• In addition, if interacting with a local Document Registry, shall audit as if it were a
Document Consumer. See ITI TF-2a: 3.18.5.1.1.
The Responding Gateway:• Shall audit the Cross Gateway Query as if it were a Document Registry except that for
EventTypeCode the Responding Gateway shall specify EV(“ITI-38”, “IHE Transactions”,“Cross Gateway Query”). See ITI TF-2a: 3.18.5.1.2.
• In addition, if interacting with a local Document Registry, shall audit as if it were a
Document Consumer. See ITI TF-2a: 3.18.5.1.1.
3.38.5 Protocol Requirements

2790

The Cross Gateway Query request and response will be transmitted using Synchronous or
Asynchronous Web Services Exchange, according to the requirements specified in ITI TF-2x:
Appendix V. The protocol requirements are identical to the Registry Stored Query except as
noted below.
Table 3.38.5-1: WSDL Namespace Definitions
soap

http://schemas.xmlsoap.org/wsdl/soap/

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2006/05/addressing/wsdl/

xsd

http://www.w3.org/2001/XMLSchema

ihe

urn:ihe:iti:xds-b:2007rs

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

lcm

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

query

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

Rev. 9.0 Final Text – 2012-08-31

115

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2795

2800

Responding Gateway: These are the requirements for the Cross Gateway Query transaction
presented in the order in which they would appear in the Responding Gateway WSDL definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0",
schemaLocation="query.xsd"• The /definitions/message/part/@element attribute of the Cross Gateway Query Request
message shall be defined as “query:AdhocQueryRequest”• The /definitions/message/part/@element attribute of the Cross Gateway Query Response
message shall be defined as “query:AdhocQueryResponse”• Refer to Table 3.38.5-2 below for additional attribute requirements

2805
Table 3.38.5-2: Additional Attribute Requirements
Attribute

2810

Value

/definitions/portType/operation@nameRespondingGateway_CrossGateway
Query/definitions/portType/operation/input/@wsaw:Ac
tion

urn:ihe:iti:2007:CrossGatewayQuery/definitions/portType/operation/output/@wsaw:A
ction

urn:ihe:iti:2007:CrossGatewayQuery
Response/definitions/binding/operation/soap12:operation/@soapAction

urn:ihe:iti:2007:CrossGatewayQuery

These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.38.5.1 Sample SOAP Messages.
For informative WSDL for the Responding Gateway actor see ITI TF-2x: Appendix W.
3.38.5.1 Sample SOAP Messages

2815

The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
W3C WS-Addressing standard. The body of the SOAP message is omitted for brevity; in a real
scenario the empty element will be populated with the appropriate metadata.
Samples presented in this section are also available online on the IHE FTP site, see ITI TF-2x:
Appendix W.

2820

3.38.5.1.1 Sample Cross Gateway Query SOAP Request
3.38.5.1.1.1 Synchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header>Rev. 9.0 Final Text – 2012-08-31

116

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2825
2830
2835

<a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayQuery</a:Action><a:MessageID>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To s:mustUnderstand="1">http://localhost/service/IHEXCARespondingGateway.svc</a:To></s:Header><s:Body><query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"/></s:Body></s:Envelope>3.38.5.1.1.2 Asynchronous Web Services Exchange

2840
2845
2850

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayQuery</a:Action><a:MessageID>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:MessageID><a:ReplyTo><a:Address>http://192.168.2.4:9080/XcaService/InitiatingGatewayReceiver.svc</a:Address></a:ReplyTo><a:To s:mustUnderstand="1">http://localhost/XcaService/RespondingGatewayReceiver.svc</a:To></s:Header><s:Body><query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"/></s:Body></s:Envelope>3.38.5.1.2 Sample Cross Gateway Query SOAP Response
3.38.5.1.2.1 Synchronous Web Services Exchange
2855
2860

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayQueryResponse</a:Action><a:RelatesTo>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:RelatesTo></s:Header><s:Body><query:AdhocQueryResponse xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"/></s:Body></s:Envelope>3.38.5.1.2.2 Asynchronous Web Services Exchange
2865
2870
2875

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayQueryResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:RelatesTo><a:To s:mustUnderstand="1">http://localhost:2647/XcaService/InitiatingGatewayReceiver.svc</a:To></s:Header><s:Body><query:AdhocQueryResponse xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"/></s:Body></s:Envelope>

3.39 Cross Gateway Retrieve
This section corresponds to Transaction 39 of the IHE Technical Framework. Transaction 39 isused by the Initiating Gateway and Responding Gateway actors.

Rev. 9.0 Final Text – 2012-08-31

117

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2880

2885

2890

2895

3.39.1 Scope
The scope of the Cross Gateway Retrieve transaction is semantically the same as the Retrieve
Document Set transaction [ITI-43]. Differences from the Retrieve Document Set transactionsare:• The Cross Gateway Retrieve is between an Initiating Gateway and a Responding Gateway.
• The ‘homeCommunityId’ parameter is required. This means that the homeCommunityId
parameter which is optional on the Retrieve Document Set transaction is required by thistransaction.
• Responding Gateways shall support the Asynchronous Web Services Exchange Option on
the Cross Gateway Retrieve. Support for this function is required in order to enable use of
Asynchronous Web Services Exchange in any cross-community interaction. Without this
support an Initiating Gateway would require unique configuration, per Responding Gateway,
to know if Asynchronous Web Services Exchange was supported. It is expected that
Asynchronous Web Services Exchange will be desired by the majority of communities.
• Asynchronous Web Services Exchange is an option on the Initiating Gateway, see ITI TF-1:
18.2.2.
3.39.2 Use Case Roles
Initiating
Gateway

Responding
Gateway

Cross Gateway
Retrieve

Figure 3.39.2-1: Use Case Roles

2900

Actor: Initiating Gateway
Role: To formulate a Cross Gateway Retrieve in response to Retrieve Document Set
transactions or other internal interaction.
Actor: Responding Gateway
Role: To return the documents requested.

2905

3.39.3 Referenced Standard
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.
ebRIM OASIS/ebXML Registry Information Model v3.0
ebRS OASIS/ebXML Registry Services Specifications v3.0

Rev. 9.0 Final Text – 2012-08-31

118

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2910

Appendix V

ITI TF-2x: Appendix V: Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

MTOM
SOAP Message Transmission Optimization Mechanism
http://www.w3.org/TR/soap12-mtom/
3.39.4 Interaction Diagram
Initiating
Gateway

Responding
Gateway

Cross Gateway
Retrieve Request
Cross Gateway
Retrieve Response

2915
3.39.4.1 Cross Gateway Retrieve
The Cross Gateway Retrieve uses the same syntax and standards as the Retrieve Document Set
transaction specified in XDS. See ITI TF-2b: 3.43.
3.39.4.1.1 Trigger Events
2920

This message is initiated by the Initiating Gateway to retrieve a set of documents from anothercommunity represented by a Responding Gateway. The Initiating Gateway may be responding
to a Retrieve Document Set transaction or may use a proprietary mechanism for triggering the
Cross Gateway Retrieve.
3.39.4.1.2 Message Semantics

2925

The message semantics for Cross Gateway Retrieve are the same as Retrieve Document Set. See
ITI TF-2b: 3.43.4.1.2. The Initiating Gateway shall specify the homeCommunityId parameterwithin the Retrieve Document Set. The homeCommunityId shall contain the value that identifies
the community associated with the Responding Gateway.
3.39.4.1.3 Expected Actions

2930

Actors supporting this transaction shall support the Expected Actions described in the ITI TF2b: 3.43.4.1.3.
The Responding Gateway shall determine the local system or systems which hold the documents
requested and interact with those systems. The Responding Gateway may use a Retrieve

Rev. 9.0 Final Text – 2012-08-31

119

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2935

2940

2945

Document Set transaction or other internally defined interaction, to retrieve the document or
documents. If more than one system is contacted the Responding Gateway shall consolidate theresults from the multiple systems into one response to the Initiating Gateway. If both successes
and failures are received the Responding Gateway may choose to use PartialSuccess status toreflect both failure and success. The Responding Gateway may alternatively choose to suppress
the failures and report only successes.
Every RegistryError element returned in the response shall have the location attribute set to thehomeCommunityId of the Responding Gateway.
If the XDS Affinity Domain Option is supported, the Initiating Gateway actor shall, if needed,
consolidate results from multiple Responding Gateways. This includes reflecting in the
consolidated results returned to the originating Retrieve Document Set [ITI-43] all successes andfailures received from Responding Gateways. If both successes and failures are received from
Responding Gateways, the Initiating Gateway shall return both DocumentResponse andRegistryErrorList elements in one response and specify PartialSuccess status.
3.39.4.1.4 Security Considerations

2950

2955

2960

2965

Both the Initiating Gateway and Responding Gateway shall audit the Cross Gateway Retrieve.
The audit entries shall be equivalent to the entries required for the Retrieve Document Set.
The Initiating Gateway:• If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit as
if it were a Document Repository. See ITI TF-2b: 3.43.6.
• In addition, shall audit the Cross Gateway Retrieve as if it were a Document Consumer
except that for EventTypeCode the Initiating Gateway shall specify EV(“ITI-39”, “IHE
Transactions”, and “Cross Gateway Retrieve”). See ITI TF-2b: 3.43.6.
• In addition, if interacting with a local Document Repository, shall audit as if it were a
Document Consumer. See ITI TF-2b: 3.43.6. One audit record shall be created for each
Document Repository contacted.
The Responding Gateway:• Shall audit the Cross Gateway Retrieve as if it were a Document Repository except that for
EventTypeCode the Responding Gateway shall specify EV(“ITI-39”, “IHE Transactions”,“Cross Gateway Retrieve”). See ITI TF-2b: 3.43.6.
• In addition, if interacting with a local Document Repository, shall audit as if it were a
Document Consumer. See ITI TF-2b: 3.43.6. One audit record shall be created for each
Document Repository contacted.
3.39.5 Protocol Requirements

2970

The Cross Gateway Retrieve request and response will be transmitted using Synchronous or
Asynchronous Web Services Exchange, according to the requirements specified in ITI TF-2x:
Appendix V. The protocol requirements are identical to the Retrieve Document Set except as
noted below.

Rev. 9.0 Final Text – 2012-08-31

120

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.39.5-1: WSDL Namespace Definitions

2975

2980

soap

http://schemas.xmlsoap.org/wsdl/soap/

soap12

http://schemas.xmlsoap.org/wsdl/soap12/

wsaw

http://www.w3.org/2006/05/addressing/wsdl/

xsd

http://www.w3.org/2001/XMLSchema

ihe

urn:ihe:iti:xds-b:2007rs

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

lcm

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

query

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

Responding Gateway: These are the requirements for the Cross Gateway Retrieve transaction
presented in the order in which they would appear in the Responding Gateway WSDL definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace="urn:ihe:iti:xds-b:2007", schema="IHEXDS.xsd"• The /definitions/message/part/@element attribute of the Cross Gateway Retrieve Request
message shall be defined as “ihe:RetrieveDocumentSetRequest”• The /definitions/message/part/@element attribute of the Cross Gateway Retrieve Response
message shall be defined as “ihe:RetrieveDocumentSetResponse”• Refer to Table 3.39.5-2 below for additional attribute requirements
3.39.5-2: Requirements for portType and Binding attributes
Attribute

2985

Value

/definitions/portType/operation@nameRespondingGateway_CrossGa
tewayRetrieve/definitions/portType/operation/input/@wsaw:Ac
tion

urn:ihe:iti:2007:CrossGateway
Retrieve/definitions/portType/operation/output/@wsaw:A
ction

urn:ihe:iti:2007:CrossGateway
RetrieveResponse/definitions/binding/operation/soap12:operation/@soapAction

urn:ihe:iti:2007:CrossGateway
Retrieve

These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.43.5.1 Sample SOAP Messages.
For informative WSDL for the Responding Gateway actor see ITI TF-2x: Appendix W.
The <ihe:RetrieveDocumentSetRequest/> element is defined in ITI TF-2b: 3.43.5. When usedwithin the Cross Gateway Retrieve the <ihe:HomeCommunityId/> element is required.

2990

The <ihe:RetrieveDocumentSetResponse/> element is defined in ITI TF-2b: 3.43.5.
3.39.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,Rev. 9.0 Final Text – 2012-08-31

121

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

2995<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
W3C WS-Addressing standard. The body of the SOAP message is omitted for brevity; in a real
scenario the empty element will be populated with the appropriate metadata.
Samples presented in this section are also available online on the IHE FTP site, see ITI TF-2x:
Appendix W.
3.39.5.1.1 Sample Cross Gateway Retrieve SOAP Request

3000

3.39.5.1.1.1 Synchronous Web Services Exchange<s:Envelope

3005
3010
3015
3020
3025

3030
3035
3040
3045
3050

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayRetrieve</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XcaService/IHEXCAGateway.svc</a:To></s:Header><s:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><HomeCommunityId>urn:oid:1.2.3.4</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId></DocumentRequest><DocumentRequest><HomeCommunityId>urn:oid:1.2.3.5</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...2000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></s:Body></s:Envelope>

3.39.5.1.1.2 Asynchronous Web Services Exchange<s:Envelope

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayRetrieve</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo><a:Address>http://192.168.2.4:9080/XcaService/InitiatingGatewayReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XcaService/RespondingGatewayReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><HomeCommunityId>urn:oid:1.2.3.4</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId></DocumentRequest><DocumentRequest><HomeCommunityId>urn:oid:1.2.3.5</HomeCommunityId>

Rev. 9.0 Final Text – 2012-08-31

122

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3055<RepositoryUniqueId>1.3.6.1.4...2000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></s:Body></s:Envelope>

3.39.5.1.2 Sample Cross Gateway Retrieve SOAP Response
3060

3065
3070
3075
3080
3085
3090
3095

3.39.5.1.2.1 Synchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayRetrieveResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Success"/><DocumentResponse><HomeCommunityId>urn:oid:1.2.3.4</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse><DocumentResponse><HomeCommunityId>urn:oid:1.2.3.5</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...2000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>

3.39.5.1.2.2 Asynchronous Web Services Exchange
3100
3105
3110

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:CrossGatewayRetrieveResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XcaService/InitiatingGatewayReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">

Rev. 9.0 Final Text – 2012-08-31

123

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3115
3120
3125
3130
3135

<rs:RegistryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Success"/><DocumentResponse><HomeCommunityId>urn:oid:1.2.3.4</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse><DocumentResponse><HomeCommunityId>urn:oid:1.2.3.5</HomeCommunityId><RepositoryUniqueId>1.3.6.1.4...2000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>3.40 Provide X-User Assertion
3140

This section corresponds to Transaction ITI-40 of the IHE IT Infrastructure Technical
Framework.
3.40.1 Scope
Transaction ITI-40 is used by the X-Service User to pass a claimed identity assertion to the XService Provider. The X-Service User and X-Service Provider use the 'X-Assertion Provider'as the third party issuer of the claimed identity assertion.

Rev. 9.0 Final Text – 2012-08-31

124

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3145

3.40.2 Use Case Roles

Actor: X-Service User
Role: User of a transaction that requires a Cross-Enterprise User Assertion
3150

Actor: X-Service Provider
Role: Service provider on a transaction that requires a Cross-Enterprise User Assertion
3.40.3 Referenced Standards
3.40.3.1 Normative -- required to use this transaction
•

3155
•
•
3160

•
•

OASIS http://www.oasis-open.org/committees/security/.
• SAMLCore SAML V2.0 Core standard
WSS10 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WSSecurity 2004)", March 2004.
WSS11 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WSSecurity 2004)", February 2006.
WSS:SAMLTokenProfile1.0 OASIS Standard, “Web Services Security: SAML Token
Profile”, December 2004
WSS:SAMLTokenProfile1.1 OASIS Standard, “Web Services Security: SAML Token
Profile 1.1”, February 2006

Rev. 9.0 Final Text – 2012-08-31

125

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3165

•

•

XSPA-SAMLv1.0 OASIS Standard, “Cross-Enterprise Security and Privacy Authorization(XSPA) Profile of the Security Assertion Markup Language (SAML) for Healthcare v1.0” ,November 2009
SAML 2.0 Profile For XACML 2.0 OASIS Standard, February 2005

3.40.3.2 Informative -- assist with understanding or implementing this transaction
3170

•

•
3175

3180

IHE Profiles• Personnel White Pages Profile• Enterprise User Authentication Profile• Basic Patient Privacy Consents Profile
OASIS-OPEN• SAML V2.0 Standards http://www.oasis-open.org/committees/security/.
• SAML V2.0 Technical Overview• SAML Executive Overview• SAML Tutorial presentation by Eve Maler of Sun Microsystems• SAML Specifications• WS-Trust - OASIS Web Services Secure Exchange (WS-SX) TC

Rev. 9.0 Final Text – 2012-08-31

126

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.40.4 Interaction Diagram

Figure 3.40.1-1: X-User Assertion Messages

3185

3.40.4.1 Provide X-User Assertion
The Provide X-User Assertion is profiled to assure interoperability between an X-Service Userand an X-Service Provider that need an Assertion about the entity requesting the service. There
are many ways to provide an Assertion that are all acceptable and may be used by parties thathave agreed to their use.

3190

The Provide X-User Assertion transaction sets some minimal interoperability profiling for thisuse-case. The Provide X-User Assertion transaction shall be used when there is no other agreed
upon policy that would assure User Assertion interoperability (e.g., WS-SecurityPolicy).
3.40.4.1.1 Trigger

3195

Configuration of the X-Service Provider and X-Service User indicates when the X-User
Assertion transaction is necessary.

Rev. 9.0 Final Text – 2012-08-31

127

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.40.4.1.2 Message Semantics

3200

The X-User Assertion must be protected at all times against confidentiality exposure, malicious
modification, and trust relationship between those communicating it. The IHE Actors that aregrouped with XUA may already require IHE-ATNA and thus TLS Mutual-Authentication,
Integrity, and Confidentiality.
The X-Service User shall include the OASIS Web Services Security (WSS) Header, and shall
include a SAML 2.0 Assertion as the security token.

3205

3210

3215

3220

3225

3230

3235

Any ATNA Audit Messages that the X-Service User records in relationship to a transaction
protected by the XUA (e.g., XDS.b Registry Stored Query, and XDS.b Retrieve Document Set),
shall have the user identity recorded according to the XUA specific ATNA encoding rules (See3.40.4.2 ATNA Audit encoding). This assures that the X-Service User and X-Service Provider
ATNA Audit messages can be correlated at the ATNA Audit Repository.
Any ATNA Audit Messages recorded by Actor grouped with the X-Service User Actor, shallhave the user identity recorded according to the XUA specific ATNA encoding rules (See3.40.4.2 ATNA Audit encoding). For example: The XDS.b Document Consumer Actor records
the Query event, this event record will include the identity provided in the XUA Identity
Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages
can be correlated at the ATNA Audit Repository.
The SAML 2.0 Assertion is profiled as follows (bold is used when SAML 2.0 terms are used):• The Assertion shall contain a Subject. The Subject contains the logical identifier of theprincipal performing the original service request (person, application, etc.) and remains
unchanged through operations acting on the assertion (e.g., proxying the Assertion).
• The Subject shall contain a SubjectConfirmation element. The bearer confirmation
method shall be supported; the holder-of-key method may be supported. Thesemethods are defined in the SAML 2.0 Profile specification, section 3.
• The SAML Assertion Conditions are profiled as:• NotBefore shall be populated with the issue instant of the Assertion• NotOnOrAfter is not specified by XUA because reasonable time limits are not clear
at the IHE Profile level. The Expiration is provided by the X-Assertion Provider andwould be variable on an Affinity Domain and/or System level.
• The assertion shall contain an AudienceRestriction containing an Audience whose
value is a URI identifying the X-Service Provider (e.g., XDS Registry, XDS
Repository). It may contain an Audience whose value is a URI identifying theAffinity Domain.
• The Assertion may contain ProxyRestriction and OneTimeUser conditions but
XUA actors may ignore these conditions.
• The Assertion shall contain an AuthnStatement specify the AuthnContextClassRef orAuthnContextDeclRef• The Assertion may contain other statements (e.g., Attributes)• The Assertion shall be signed by the X-Assertion Provider as defined in SAML Core.
Rev. 9.0 Final Text – 2012-08-31

128

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The interface between the X-Service User and the X-Assertion Provider is not specified by
XUA. This interface needs to be protected against risks (e.g., exposure of the SAML Token tointerception for malicious use). Assertions need to be carefully managed in the X-Service User toensure they are not exposed in the application code or any subsequent use of the Assertion.
3240

3245

3250

3255

3.40.4.1.3 Expected Actions
The X-Service Provider shall validate the Identity Assertion by processing the Web-Services
Security header in accordance with the Web-Services Security Standard, and SAML 2.0
Standard processing rules (e.g., check the digital signature is valid and chains to an X-Identity
Provider that is configured as trusted). If this validation fails, then the grouped Actor’s associatedtransaction shall return with an error code as described in WS-Security core specification section
12 (Error Handling, using the SOAP Fault mechanism), and the ATNA Audit event for
Authentication Failure shall be recorded according to ATNA rules.
Any ATNA Audit Messages recorded by Actor grouped with the X-Service Provider Actor, shallhave the user identity recorded according to the XUA specific ATNA encoding rules (See ITI
TF-2b: 3.40.4.2 ATNA Audit encoding). For example: The XDS.b Registry Stored Query Actor
records the Query event, this event record will include the identity provided in the XUA Identity
Assertion. This assures that the X-Service User and X-Service Provider ATNA Audit messages
can be correlated at the ATNA Audit Repository.
The X-Service Provider may use standards transactions to communicate with the X-Assertion
Provider (e.g., WS-Trust, SAML 2.0 Protocol) to obtain information not included in the assertion
provided (e.g., Attributes that might be related to structural roles).
The X-Service Provider may utilize the identity in access control decisions. Appropriate error
messages, not defined here, shall be returned. The X-Service Provider may ignore any otherstatements (e.g., Attributes).

3260

3265

The X-Service Provider may use the authentication class references to determine the method thatwas used to authenticate the user. For example the X-Service Provider may have a configurable
list of authentication class references that it is willing to recognize as authentication methods thatare acceptable, thus treating other authentication class references as not authorized.
Assertions need to be carefully managed inside the X-Service Provider to ensure they are notexposed in the application code or any subsequent use of the Assertion.
3.40.4.2 ATNA Audit encoding
When an ATNA Audit message needs to be generated and the user is authenticated by way of an
X-User Assertion, the ATNA Audit message UserName element shall record the X-User
Assertion using the following encoding:3270

alias"<"user"@"issuer">"
where:• alias is the optional string within the SAML Assertion's Subject element SPProvidedID
attribute

Rev. 9.0 Final Text – 2012-08-31

129

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3275

•
•

user is the required content of the SAML Assertion's Subject element
issuer is the X-Assertion Provider entity ID contained with the content of SAML Assertion'sIssuer element

3.40.4.3 Informative Material on WS-Trust

3280

If the X-Service Provider uses WS-Trust in order to obtain a SAML assertion from an X-Identity
Provider, it is suggested to use the version 1.3 of the WS-Trust specification, as described in[WS-Trust].

3.41 Provide and Register Document Set-b

3285

This section corresponds to Transaction [ITI-41] of the IHE Technical Framework. Provide andRegister Document Set-b is used by the Document Source to provide a set of documents to theDocument Repository, and to request that the Document Repository store these documents andthen register them with the Document Registry. The Document Source may also provide a set of
documents to a Document Recipient.
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)
Cross-Enterprise Document Reliable Interchange (XDR)

3290

3295

3300

3305

The Provide and Register Document Set-b transaction describes the interaction between theDocument Source and the Document Recipient actors, and the Document Source and Document
Repository actors. The interaction between the Document Repository and the XDS Document
Registry is described separately in the Register Document Set-b Transaction [ITI-42].
This transaction aligns with the Registry Services standard (ebRS) for the format of the
document metadata as defined in ITI TF-3: 4.1. The ebRS standard covers the interaction with aservice that includes a registry with integrated repository. From the point of view of theDocument Source, the separate nature of the XDS Document Registry and Document Repository
actors is not relevant.
By specifying separate Document Registry and Document Repository actors, XDS offers
additional flexibility of having a single Document Registry index content for multiple Document
Repositories. The ebRIM portion of the registry standard supports this possibility though theExternalLink object type.
In XDS, the documents and metadata go to the Document Repository actor and then the metadata
is forwarded on to the Document Registry actor. They move in this direction for several reasons:• Allows best reuse of ebXML Registry specified metadata and web services protocols• Document Source only needs to know the identity of the Document Repository. Document
Repository knows the identity of the Document Registry. If Provide and Register Document
Set-b transaction were sent to the Document Registry then routing decisions for documents
would be more complex.
• Resulting protocols are simpler

Rev. 9.0 Final Text – 2012-08-31

130

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3310

3315

•

Simplifies the common case where the Document Source and the Document Repository aregrouped.

Actors that support the Asynchronous Web Services Exchange option and implement the Provide
and Register Document Set-b [ITI-41] transaction shall support Asynchronous Web Services
Exchange on all XDS.b or XDR transactions they implement. Refer to section ITI TF-2x: V.5
Synchronous and Asynchronous Web Services Exchange for an explanation of Asynchronous
Web Services Exchange.
3.41.1 Scope
The Provide and Register Document Set-b transaction passes a Repository Submission Request(see ITI TF-3: 4.1.3.1) from a Document Source to a Document Repository or Document
Recipient.

3320

3325

A Provide and Register Document Set-b transaction shall carry:• Metadata describing zero or more documents• Within metadata, one XDSDocumentEntry object per document• XDS Submission Set definition along with the linkage to new documents and references toexisting documents• Zero or more XDS Folder definitions along with linkage to new or existing documents• Zero or more documents
3.41.2 Use Case Roles
Document Source

Document Recipient

Document Repository

Provide and Register
Document Set – b

Actor: Document Source
3330

Role: A system that submits documents and associated metadata to a Document Repository.
Detailed requirements for this actor are discussed in ITI TF-2b: 3.41.6.1.
Actor: Document Recipient

3335

Role: A system that receives a set of documents. Typically this document set will be madeavailable to the intended recipient who will chose to either view it or integrate it into theElectronic Healthcare Record (EHR).
Detailed requirements for this actor are discussed in ITI TF-2b: 3.41.6.2.

Rev. 9.0 Final Text – 2012-08-31

131

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor: Document Repository

3340

Role: A document storage system that receives documents and associated metadata and:• Stores the documents• Enhances submitted metadata with repository information to enable later retrieval of
documents• Forwards the enhanced metadata to the Document Registry.
Detailed requirements for this actor are discussed in ITI TF-2b: 3.41.6.2.
3.41.3 Referenced Standards

3345

Implementors of this transaction shall comply with all requirements described in: ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

Appendix V

ITI TF-2x:Appendix V Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

MTOM

SOAP Message Transmission Optimization Mechanism http://www.w3.org/TR/soap12-mtom/

XOP

XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/

3.41.4 Interaction Diagrams
Document
SourceDocument
Repository
Provide and Register Document Set – b
RequestProvide and Register Document Set – b
Response

3350

Rev. 9.0 Final Text – 2012-08-31

132

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Document
SourceDocument
Recipient
Provide and Register Document Set – b
RequestProvide and Register Document Set – b
Response

3.41.4.1 Provide and Register Document Set-b Request
3355

3360

3365

A Document Source sends documents and associated metadata to a Document Recipient, or aDocument Repository that has an associated Document Registry.
The Document Repository shall, upon receipt of a Provide and Register Document Set-b [ITI-41]
transaction send a corresponding Register Document Set-b [ITI-42] transaction to the Document
Registry actor.
• The Document Repository actor shall create and insert the
XDSDocumentEntry.repositoryUniqueId, XDSDocumentEntry.size, andXDSDocumentEntry.hash attributes for each document received from the Provide andRegister Document Set-b [ITI-41] transaction into the resulting Register Document Set-b[ITI-42] transaction metadata. The combination of XDSDocumentEntry.uniqueId and
XDSDocumentEntry.repositoryUniqueId attributes value shall later be accepted in a Retrieve
Document Set transaction [ITI-43] for that document and the document shall be returned.
3.41.4.1.1 Trigger Events

3370

The Document Source, based on a human decision or the application of a certain rule ofautomatic operation, wants to submit• A set of zero or more documents to the Document Repository and the associated metadata to
the Document Registry.
or• A set of one or more documents to a Document Recipient.
3.41.4.1.2 Message Semantics

3375

The sections in ITI TF-3: 4.1 specify the mapping of XDS concepts to ebRS and ebRIM
semantics and document metadata. A full example of document metadata submission can befound in ITI TF-2x: Appendix W.

Rev. 9.0 Final Text – 2012-08-31

133

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.4.1.3 Expected Actions
The Provide and Register Document Set-b message shall include the metadata attributes (asdefined in ITI TF-3: 4.1.7 Document Definition Metadata).
3380

3385

3390

A Document Recipient receives the metadata and the associated document(s). It shall be able tointerpret the submission without any context (e.g., a prior submission).
The Document Source may include Folders in metadata. If the Document Recipient is not able toprocess the Folder specific content it shall return a PartialFolderContentNotProcessed warningwhich includes a textual description identifying that Folder Content was not processed. In thiscase the Document Recipient is expected to have processed the rest of the submission
successfully.
In the case where the Document Source submits a replacement of documents, if the Document
Recipient is not able to process the replacement semantics in the submission it shall return aPartialReplaceContentNotProcessed warning which includes a textual description identifyingthat the replacement semantics were not processed. In this case the Document Recipient is
expected to have processed the rest of the submission successfully.
A Document Repository shall forward the metadata to the Document Registry using the Register
Document Set-b transaction [ITI-42].

3395

3400

3405

3410

The Document Repository receives this message. Each document within the message shall be
stored into the Document Repository as an octet stream with an associated MIME type.
The Document Source shall supply all necessary document metadata attributes with the
exception of the ones below. The Document Repository shall modify the received document
metadata before initiating the Register Document Set-b transaction to the Document Registry byadding/replacing:• The repositoryUniqueId for this Document Repository to allow for the Document Consumer
to correctly identify the proper Document Repository for each document(XDSDocumentEntry.repositoryUniqueId).
• A hash value (XDSDocumentEntry.hash)• A size (XDSDocumentEntry.size).
A Register Document Set-b transaction with this modified metadata shall be issued to theDocument Registry.
The Document Repository shall ensure that when any Retrieve Document Set transaction isreceived requesting a specific document(s), it shall be provided to the Document Consumer
unchanged from the octet stream that was submitted (full fidelity repository) and shall match thesize and hash attributes of the XDSDocumentEntry object.
If the Document Repository or Document Recipient detects a failure it shall return an error
message to the Document Source thus terminating this transaction. The conditions of failure andpossible error messages are given in the ebRS standard and detailed in ITI TF-3: 4.1.13 Error
Reporting.

Rev. 9.0 Final Text – 2012-08-31

134

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3415

3.41.4.1.3.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:

3420

1. The Document Source actor shall populate the confidentialityCode in the document
metadata with the list of values that identify the sensitivity classifications that apply tothe associated document. The confidentiality codes for different documents in the same
submission may be different.
2. The Document Source actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the XDS Affinity Domain Policy. The details of this areproduct specific and not specified by IHE.

3425

3430

3. The Document Source actor may have user interface or business rule capabilities todetermine the appropriate confidentiality codes for each document. The details of this areproduct specific and not specified by IHE. However, the information about how
confidentiality codes are assigned must be part of the published policy for the XDS
Affinity Domain. Note: For example, when publishing a document, the Document
Source, might show a list of checkboxes where a user can select which of the available
consents a document is to be published.

3435

4. The Document Recipient actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the policies. The meanings of the codes on the media must be
provided out of band, e.g., by telephone, fax, or email. The detail of how this is done isproduct specific and not specified by IHE. If the documents are transferred internallywithin the organization or to other members of the recipient's affinity domain, appropriate
internal confidentiality codes shall be applied.

3440

5. The Document Recipient actor shall have the ability to coerce the confidentiality code in
the metadata associated with the document from the codes used by the Document Source
to the codes used by the Document Recipient.

3445

6. The Document Recipient actor shall abide by the XDS Affinity Domain Policies
represented by the confidentialityCode in the metadata associated with the document. The
Document Recipient actor likely will have user access controls or business rulecapabilities to determine the details of how confidentiality codes apply to query results.
The details of this are product specific and not specified by IHE. These rules shall reduce
the query results to only those that are appropriate to the current situation for that actor
and user.
3.41.4.2 Provide and Register Document Set-b Response

3450

The Document Repository or Document Recipient shall send a Provide and Register Document
Set-b Response when the processing of a Provide and Register Document Set-b Request iscomplete.
The Provide and Register Document Set-b Response message shall carry the status of therequested operation and an error message if the requested operation failed. The conditions ofRev. 9.0 Final Text – 2012-08-31

135

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3455

failure and possible error messages are given in the ebRS standard and detailed in ITI TF-3:
4.1.13 Error Reporting.
3.41.4.2.1 Trigger Events

3460

3465

The following events can trigger this message:• Documents successfully received and processed by the Document Recipient• Documents were not successfully received by the Document Recipients• Documents stored to the Document Repository successfully and metadata stored to theDocument Registry successfully (The registry part is carried out as part of a Register
Document Set-b transaction)• Documents stored to the Document Repository successfully but an error occurred in storing
the metadata to the Document Registry• Documents were not successfully stored to the Document Repository
3.41.4.2.2 Message Semantics

3470

The Provide and Register Document Set-b Response message shall carry the status of therequested operation and an error message if the requested operation failed. The conditions offailure and possible error messages are given in the ebRS standard and detailed in ITI TF-3:
4.1.13 Error Reporting.
3.41.4.2.3 Expected Actions
The Document Source now knows that the transaction succeeded/failed and can continue.

3475

The document(s) received by the Document Recipient shall be available for further processing
according to the capabilities of the system. These capabilities are not specified by IHE, but may
include viewing the document or storing them to an Electronic Healthcare Record (EHR).
The document(s) added to the Document Repository are now available for retrieval. The
metadata added to the registry shall be available for discovery via Registry Stored Query
transactions.

3480

3.41.5 Protocol Requirements
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:Appendix V: Web Services for IHE Transactions.
The Provide and Register Document Set-b transaction shall use SOAP12 and MTOM with XOP
encoding (labeled MTOM/XOP in this specification). See ITI TF-2x: Appendix V for details.

3485

WSDL Namespace Definitions
ihe

urn:ihe:iti:xds-b:2007rs

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

lcm

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

query

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

Rev. 9.0 Final Text – 2012-08-31

136

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3490

3495

3500

Document Repository: These are the requirements for the Provide and Register Document Set-b
transaction presented in the order in which they would appear in the Document Repository
WSDL definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", schema="rs.xsd"• namespace="urn:ihe:iti:xds-b:2007", schemaLocation="IHEXDS.xsd"• The /definitions/message/part/@element attribute of the Provide and Register Document Setb Request message shall be defined as “ihe:ProvideAndRegisterDocumentSetRequest”• The /definitions/message/part/@element attribute of the Provide and Register Document Setb Response message shall be defined as “rs:RegistryResponse”• Refer to Table 3.41.5.b below for additional attribute requirements• To support the Asynchronous Web Services Exchange option on the Document Source, theDocument Repository and Document Recipient shall support the use of a non-anonymous
response EPR in the WS-Addressing replyTo header.
These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.41.5.1 Sample SOAP Messages.
For informative WSDL for the Document Repository actor see ITI TF-2x: Appendix W.

3505

3510

3515

The <ihe:ProvideAndRegisterDocumentSetRequest/> element is defined as:• One <lcm:SubmitObjectsRequest/> element that contains the submission set metadata• Zero or more <ihe:Document/> elements that contain the base64encoded data for the
documents being submitted to the Document Repository or Document Recipient. The<ihe:Document/> element also includes the document id attribute (ihe:Document/@id) oftype xsd:anyURI to match the document ExtrinsicObject id in the metadata and providing thenecessary linkage
The use of MTOM/XOP is governed by the following rules:• The Document Repository or Document Recipient shall accept documents in a Provide andRegister Document Set-b transaction in MTOM/XOP format. The response message shall use
MTOM/XOP format.
• The Document Source shall generate Provide and Registry Document Set-b transactions in
MTOM/XOP format. It shall accept the response message in MTOM/XOP format.
Table 3.41.5.b: Additional Attribute Requirements
Attribute

Value/definitions/portType/operation@nameDocumentRepository_
ProvideAndRegisterDocumentSet-b/definitions/portType/operation/i
nput/@wsaw:Action

urn:ihe:iti:2007:
ProvideAndRegisterDocumentSet-b/definitions/portType/operation/o
utput/@wsaw:Action

urn:ihe:iti:2007:
ProvideAndRegisterDocumentSetbResponse

Rev. 9.0 Final Text – 2012-08-31

137

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Attribute

Value/definitions/binding/operation/so
ap12:operation/@soapAction

urn:ihe:iti:2007:CrossGatewayQuery

A full XML Schema Document for the XDS.b types is available online on the IHE FTP site, see
ITI TF-2x: Appendix W.
3520

3525

3.41.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
ITI TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP message isomitted for brevity; in a real scenario the empty element will be populated with the appropriate
metadata.
Samples presented in this section are also available online on the IHE FTP site, see ITI TF-2x:
Appendix W.
3.41.5.1.1 Sample Provide and Register Document Set-b SOAP Request

3530

3.41.5.1.1.1 Synchronous Web Services Exchange

3535

POST /axis2/services/repository HTTP/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180;
type="application/xop+xml"; start="<0.urn:uuid76A2C3D9BCD3AECFF31217932910181@apache.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"
User-Agent: Axis2
Host: localhost:4040
Content-Length: 4567

3540--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:76A2C3D9BCD3AECFF31217932910181@apache.org>

3545<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://localhost:4040/axis2/services/test11966a</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetb</wsa:Action></soapenv:Header><soapenv:Body><xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007"><lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

3550
3555
3560
3565

<!-- Registry Metadata goes here --></rim:RegistryObjectList></lcm:SubmitObjectsRequest><xdsb:Document id="Document01"><xop:Include href="cid:1.urn:uuid:76A2C3D9BCD3AECFF3121793290229@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include"/></xdsb:Document></xdsb:ProvideAndRegisterDocumentSetRequest>

Rev. 9.0 Final Text – 2012-08-31

138

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3570
3575

</soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:76A2C3D9BCD3AECFF31217932910229@apache.org>
This is my document.
It is great!

3580--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180--

Rev. 9.0 Final Text – 2012-08-31

139

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.5.1.1.2 Asynchronous Web Services Exchange
3585
3590
3595
3600

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetb</a:Action><a:MessageID>urn:uuid:6d296e90-e5dc-43d0-b455-7c1f3eb35d83</a:MessageID><a:ReplyTo><a:Address> http://192.168.2.4:9080/XdsService/DocumentSourceReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRepositoryReceiver.svc</a:To></s:Header><s:Body><ProvideAndRegisterDocumentSetRequest
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">

3605
3610

<lcm:SubmitObjectsRequest><!—Rest of SubmitObjectsRequest message goes here --></lcm:SubmitObjectsRequest><Document
id="Document01">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></ProvideAndRegisterDocumentSetRequest></s:Body></s:Envelope>3615
3.41.5.1.2 Sample Provide and Register Document Set-b SOAP Response
3.41.5.1.2.1 Synchronous Web Services Exchange
3620
3625
3630

3635
3640

<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</a:Action><a:RelatesTo>urn:uuid:6d296e90-e5dc-43d0-b455-7c1f3eb35d83</a:RelatesTo></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" /></s:Body></s:Envelope>

3.41.5.1.2.2 Asynchronous Web Services Exchange<s:Envelope

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID>

Rev. 9.0 Final Text – 2012-08-31

140

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3645
3650

<a:RelatesTo>urn:uuid:6d296e90-e5dc-43d0-b455-7c1f3eb35d83</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentSourceReceiver.svc</a:To></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" /></s:Body></s:Envelope>

3.41.6 Actor Requirements
3655This section summarizes the responsibilities of the actors relevant to this transaction.
3.41.6.1 Document Source

3660

3665

An implementation of the Document Source actor shall be capable of the following operations:• Submit one or more documents. Whether a submission contains a single or multiple
documents depends on workflows, policies, and other external factors which are outside of
the scope of this transaction.
An implementation of the XDS Document Source actor may support one or more of thefollowing XDS.b options:• Document Replace Option: In this option the Document Source offers the ability to submit
a document as a replacement for another document already in the registry/repository.
• Document Addendum Option In this option the Document Source shall offer the ability tosubmit a document as an addendum to another document already in the registry/repository.
• Document Transformation Option In this option the Document Source shall offer theability to submit a document as a transformation of another document already in theregistry/repository.

3670
Note: In order to support document replacement/addendum/transformation grouping with the Document Consumer may benecessary in order to Query the registry (e.g., for UUIDs of existing document entries)•
3675

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 benecessary in order to Query the registry (e.g., for UUIDs of existing folder).

These operations are discussed in ITI TF-3: 4.1.3.4 Other Properties of Submission Requests.
3680

3.41.6.2 Document Repository or Document Recipient
A Document Repository or Document Recipient shall be capable of accepting submissions
containing multiple documents.
Note: The Document Source may submit single documents or multiple documents depending on its needs.

Rev. 9.0 Final Text – 2012-08-31

141

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3685

3690

3695

3700

A Document Repository shall validate the following metadata element received as part of aProvide and Register transaction:• XDSDocumentEntry.uniqueId – a submission shall be rejected if not unique within therepository and the hashes of the two documents do not match. If the hashes of the documents
match, the Document Repository shall accept the duplicate document.
A Document Repository or Document Recipient shall validate the following metadata element
received as part of a Provide and Register transaction:• XDSSubmissionSet.sourceId – a Document Repository or Document Recipient may choose
to accept submissions only from certain sources and use this field to perform the filtering.
• XDSDocumentEntry.hash – a submission shall be rejected if the hash is included in thesubmission and its value does not match the hash for the received document (ignoring case),
as calculated by the Document Repository or Document Recipient; an
XDSRepositoryMetadataError shall be returned on mismatch.
• XDSDocumentEntry.size – a submission shall be rejected if the size is included in thesubmission and its value does not match the size of the received document, as computed by
the Document Repository or Document Recipient; an XDSRepositoryMetadataError shall be
returned on mismatch.
3.41.7 Security Considerations
Relevant XDS Affinity Domain security considerations are discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3.41.7.1 Audit Record Considerations

3705

The Provide and Register Document Set-b Transaction is PHI-Export event, as defined in ITI
TF-2a: Table 3.20.6-1. The Actors involved in the transaction shall create audit data inconformance with DICOM (Supp 95) “Data Export”/”Data Import”, with the following
exceptions.

Rev. 9.0 Final Text – 2012-08-31

142

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3710

3.41.7.1.1 Document Source audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-41”, “IHE Transactions”, “Provide and Register Document
Set-b”)

UserIDM

The content of the <wsa:ReplyTo/> element.

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

Source (Document Source) (1)
Human Requestor (0..n)
Destination (Document Repository) (1)Audit Source (Document Source) (1)Patient (1)SubmissionSet (1)Where:

SourceAuditMessage/
ActiveParticipant

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Rev. 9.0 Final Text – 2012-08-31

143

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AuditMessage/
ParticipantObjectIdenti
fication)

3715

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

The patient ID in HL7 CX format.

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS
Metadata”, “submission set classificationNode”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDM

The submissionSet unique ID

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

3.41.7.1.2 Document Repository or Document Recipient audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-41”, “IHE Transactions”, “Provide and Register Document
Set-b”)

Source (Document Source) (1)Destination (Document Repository or Document Recipient) (1)Audit Source (Document Repository or Document Recipient) (1)Patient (1)SubmissionSet (1)Where:

SourceAuditMessage/
ActiveParticipant

UserIDM

The content of the <wsa:ReplyTo/> element.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

Rev. 9.0 Final Text – 2012-08-31

144

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AuditMessage/
ParticipantObjectIdenti
fication)

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS
Metadata”, “submission set classificationNode”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDM

The submissionSet unique ID

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

3720

3.42 Register Document Set-b
This section corresponds to transaction [ITI-42] of the IHE IT Infrastructure Technical
Framework. Transaction [ITI-42] is used by the Document Repository Actor to register a set of
documents with the Document Registry in XDS.b.
3725

Rev. 9.0 Final Text – 2012-08-31

145

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)

3730

Actors that support the Asynchronous Web Services Exchange option and implement theRegister Document Set-b transaction shall support the following:• Document Repository Actor shall support Asynchronous Web Services Exchange for theProvide & Register Document Set – b [ITI-41] and Register Document Set – b [ITI-42], andRetrieve Document Set [ITI-43] transactions• Document Registry Actor shall support Asynchronous Web Services Exchange for theRegistry Stored Query [ITI-18] and Register Document Set – b [ITI-42] transactions
Refer to section ITI TF-2x: V.5 Synchronous and Asynchronous Web Services Exchange for an
explanation of Asynchronous Web Services Exchange.

3735

3.42.1 Scope
The Register Document Set-b transaction passes a Submission Request from a Document
Repository actor to a Document Registry actor.

3740

A Register Document Set-b transaction shall carry:• Metadata describing zero or more documents• XDS Submission Set definition along with the linkage to new documents and references toexisting documents• An optional XDS Folder definitions along with linkage to new or existing documents
3.42.2 Use Case Roles
Document Repository
Or
Integrated Document
Source/Repository

Document
Registry

RegisterDocument Set – b

3745

Actor: Document Repository or Integrated Document Source/Repository
Role: A document storage system that submits document metadata to a Document Registry.
3750

Actor: Document Registry
Role: A document indexing system that receives and stores document metadata.

Rev. 9.0 Final Text – 2012-08-31

146

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Note: Within this transaction, the Document Repository and Integrated Document Source/Repository actors can be usedinterchangeably

3.42.3 Referenced Standards
3755

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

HL7V2

HL7 Version 2.5

Appendix V

ITI TF-2x:Appendix V Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

3.42.4 Interaction Diagram

Document
Repository

Document
Registry
Register Document Set – b Request

Register Document Set – b Response

3760
3.42.4.1 Register Document Set-b Request
The Document Repository sends metadata for a set of documents to the Document Registry.
3.42.4.1.1 Trigger Events
3765

The Register Document Set-b Request message is triggered when:• A Document Repository wants to register metadata for a set of documents it holds. These
documents may have been stored in the Document Repository by a Document Consumer(using the Provide and Register Document Set-b transaction [ITI-41]) or generated internallyby an Integrated Document Source/Repository.

Rev. 9.0 Final Text – 2012-08-31

147

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3770

3.42.4.1.2 Message Semantics
The sections in ITI TF-3: 4.1 specify the mapping of XDS concepts to ebRS and ebRIM
semantics and document metadata. A full example of document metadata submission can befound in ITI TF-2x: Appendix W.

3775

The Registry actor shall store and later include in metadata returned in a query response the
XDSDocumentEntry.repositoryUniqueId attribute along with other metadata attributes received
in the Register Document Set-b [ITI-42] transaction as determined by profile and transaction
requirements.
3.42.4.1.4 Expected Actions

3780

3785

Upon receipt of a Register Document Set-b Request message, the Document Registry with theaid of the Registry Adaptor shall do the following:• Accept all valid SubmitObjectsRequests.
• Perform metadata 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 shall occur:• An error is returned• The error status includes an error message• The request is rolled back3.42.4.1.4.1 Basic Patient Privacy Enforcement Option

3790

If the Basic Patient Privacy Enforcement Option is implemented:
1. The Integrated Document Source / Repository actor shall populate theconfidentialityCode in the document metadata with the list of values that identify thesensitivity classifications that apply to the associated document. The confidentiality codesfor different documents in the same submission may be different.

3795

3800

3805

2. The Integrated Document Source / Repository actor shall be able to be configured with
the Patient Privacy Policies, Patient Privacy Policy Identifiers (OIDs) and associatedinformation necessary to understand and enforce the XDS Affinity Domain Policy. The
details of this are product specific and not specified by IHE.
3. The Integrated Document Source / Repository actor may have a user interface or businessrule capabilities to determine the appropriate confidentiality codes for each document.
The details of this are product specific and not specified by IHE. However, theinformation about how confidentiality codes are assigned must be part of the publishedpolicy for the XDS Affinity Domain. For example, when publishing a document, theIntegrated Document Source / Repository might show a list of checkboxes where a user
can select which of the available consents a document is to be published.

Rev. 9.0 Final Text – 2012-08-31

148

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.42.4.1.5 Protocol Requirements

3810

The Register Document Set-b transaction shall use SOAP12. Furthermore:• The Document Registry actor shall accept the Register Document Set-b Request formatted asa SIMPLE SOAP message and respond with the Register Document Set-b Response
formatted as a SIMPLE SOAP message.
• The Document Repository actor shall generate the Register Document Set-b Request
formatted as a SIMPLE SOAP message and accept the Register Document Set-b Response
formatted as a SIMPLE SOAP message.
See ITI TF-2x: Appendix V for details.

3815

3.42.4.2 Register Document Set-b Response
3.42.4.2.1 Trigger Events
The Document Registry finishes processing a Register Document Set-b Request Message andshall respond with:• Register Document Set-b Response

3820

3.42.4.2.2 Message Semantics
The Register Document Set-b Response message shall carry 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 and detailed in ITI TF-3: 4.1.13 Error Reporting.
3.42.4.2.3 Expected Actions

3825

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.
3.42.5 Protocol Requirements

3830

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.

Rev. 9.0 Final Text – 2012-08-31

149

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________WSDL Namespace Definitions

3835

3840

3845

ihe

urn:ihe:iti:xds-b:2007rs

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

lcm

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

query

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

Document Registry: These are the requirements for the Register Document Set-b transaction
presented in the order in which they would appear in the Document Registry WSDL definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", schema=" rs.xsd"• namespace="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0", schema=" lcm.xsd"• The /definitions/message/part/@element attribute of the Register Document Set-b Request
message shall be defined as “lcm:SubmitObjectsRequest”• The /definitions/message/part/@element attribute of the Register Document Set-b Response
message shall be defined as “rs:RegistryResponse”• Refer to Table 3.42.5.b below for additional attribute requirements• To support the Asynchronous Web Services Exchange option on the Document Repository,
the Document Registry shall support the use of a non-anonymous response EPR in the WSAddressing replyTo header.
These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.42.5.1 Sample SOAP Messages.
For informative WSDL for the Document Registry actor see ITI TF-2x: Appendix W.

3850

Table 3.42.5.b: Additional Attribute Requirements
Attribute

Value/definitions/portType/operation@name

DocumentRepository_RegisterDocumentSet-b/definitions/portType/operation/input/@wsaw:Action

urn:ihe:iti:2007:RegisterDocumentSet-b/definitions/portType/operation/output/@wsaw:Action

urn:ihe:iti:2007:
ProvideAndRegisterDocumentSetbResponse/definitions/binding/operation/soap12:operation/@soap
Actionurn:ihe:iti:2007: RegisterDocumentSet-b

3.42.5.1 Sample SOAP Messages

3855

The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to ITI
TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP message isRev. 9.0 Final Text – 2012-08-31

150

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
omitted for brevity; in a real scenario the empty element will be populated with the appropriate
metadata.
Samples presented in this section are also available online on the IHE FTP site, see ITI TF-2x:
Appendix W.
3860

3.42.5.1.1 Sample Register Document Set-b SOAP Request
3.42.5.1.1.1 Synchronous Web Services Exchange

3865
3870
3875
3880

3885

3890
3895
3900
3905

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-b</a:Action><a:MessageID>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo s:mustUnderstand="1"><a:To >http://localhost:2647/XdsService/IHEXDSRegistry.svc</a:To></s:Header><s:Body><lcm:SubmitObjectsRequest
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><!—Rest of SubmitObjectsRequest message goes here --></lcm:SubmitObjectsRequest></s:Body></s:Envelope>

3.42.5.1.1.2 Asynchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-b</a:Action><a:MessageID>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:MessageID><a:ReplyTo><a:Address>
http://192.168.2.4:9080/XdsService/DocumentRepositoryReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRegistryReceiver.svc</a:To></s:Header><s:Body><lcm:SubmitObjectsRequest
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><!—Rest of SubmitObjectsRequest message goes here --></lcm:SubmitObjectsRequest></s:Body></s:Envelope>Rev. 9.0 Final Text – 2012-08-31

151

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3910

3.42.5.1.2 Sample Register Document Set-b SOAP Response
3.42.5.1.2.1 Synchronous Web Services Exchange

3915
3920
3925

<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-bResponse</a:Action><a:RelatesTo>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:RelatesTo></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></s:Body></s:Envelope>

3.42.5.1.2.2 Asynchronous Web Services Exchange<s:Envelope

3930
3935
3940
3945

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSetbResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRepositoryReceiver.svc</a:To></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></s:Body></s:Envelope>

3.42.6 Actor Requirements

3950

The Document Repository actor shall:• Make (all) the new document(s) included in the XDS Submission Set available for retrieval
via the Retrieve Document Set transaction before it initiates the Register Document Set-b
Request message with the Registry actor.

3955This is necessary because:• The Document Registry actor may choose to validate the successful storage of the
document(s) before acknowledging the Register Document Set-b Request transaction.
• The Document Consumer actor may retrieve the document(s) before the Register Document
Set-b Response is received by the Document Repository actor.
3.42.7 Security Considerations
Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).

Rev. 9.0 Final Text – 2012-08-31

152

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.42.7.1 Audit Record Considerations
3960

The Register Document Set-b Transaction is PHI-Export event, as defined in ITI TF-2a: Table
3.20.6-1. The Actors involved in the transaction shall create audit data in conformance with
DICOM (Supp 95) “Data Export”, with the following exceptions.
3.42.7.1.1 Document Repository or Integrated Document Source/Repository audit
message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-42”, “IHE Transactions”, “Register Document Set-b”)

Source (Document Repository or Integrated Document Source/Repository) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)Audit Source (Document Repository or Integrated Document Source/Repository) (1)Patient (1)SubmissionSet (1)3965

Where:

SourceAuditMessage/
ActiveParticipant

UserIDU

When WS-Addressing is used: <ReplyTo/>

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

DestinationRev. 9.0 Final Text – 2012-08-31

153

SOAP endpoint URI.

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
AlternativeUserID

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AuditMessage/
ParticipantObjectIdenti
fication)U

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS
Metadata”, “submission set classificationNode”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

The submissionSet unique ID

3.42.7.1.2 Document Registry audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-42”, “IHE Transactions”, “Register Document Set-b”)

Source (Document Repository or Integrated Document Source/Repository) (1)Destination (Document Registry ) (1)Audit Source (Document Registry) (1)Patient (1)SubmissionSet (1)Rev. 9.0 Final Text – 2012-08-31

154

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3970

Where:

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AuditMessage/
ParticipantObjectIdenti
fication)

UserIDU

When WS-Addressing is used this should be the value of the<ReplyTo/> element.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS
Metadata”, “submission set classificationNode”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDM

The submissionSet unique ID

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

Rev. 9.0 Final Text – 2012-08-31

155

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ParticipantObjectDetailUnot specialized

3.43 Retrieve Document Set
3975

This section corresponds to Transaction ITI-43 of the IHE Technical Framework. The Document
Consumer, Document Repository and Initiating Gateway actors use transaction ITI-43.
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)
Cross-Community Access (XCA)

3980

Actors that support the Asynchronous Web Services Exchange option shall support
Asynchronous Web Services Exchange on all XDS.b transactions they implement. Refer tosection ITI TF-2x: V.5 Synchronous and Asynchronous Web Services Exchange for an
explanation of Asynchronous Web Services Exchange.
3.43.1 Scope

3985

This transaction is used by the Document Consumer to retrieve a set of documents from theDocument Repository or Initiating Gateway. The Document Consumer has already obtained the
XDSDocumentEntry uniqueId and the Document Repository repositoryUniqueId from theDocument Registry/Initiating Gateway by means of the Registry Stored Query transaction.
3.43.2 Use Case Roles

Document Repository
Or
Integrated Document
Source/Repository

Document
Consumer

Initiating Gateway

Retrieve
Document Set

3990
XDS Actors:

Actor: Document Consumer
Role: Obtains document.
3995

Actor: Document Repository or Integrated Document Source/Repository
Role: Provides documents.
XCA Actors:

Rev. 9.0 Final Text – 2012-08-31

156

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor: Initiating Gateway
Role: An Initiating Gateway which implements the XDS Affinity Domain option
retrieves a set of documents by using the Cross Gateway Retrieve transaction and/or a
Retrieve Document Set transaction.

4000

Note: Within this transaction, the Document Repository and Integrated Document Source/Repository actors can be usedinterchangeably.

3.43.3 Referenced Standard
4005

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

Appendix V

ITI TF-2x:Appendix V Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

MTOM

SOAP Message Transmission Optimization Mechanism http://www.w3.org/TR/soap12-mtom/

XOP

XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/

3.43.4 Interaction Diagram
Document
Repository/
Initiating
Gateway

Document
Consumer
Retrieve Document Set Request

Retrieve Document Set Response

4010

3.43.4.1 Retrieve Document Set Request
3.43.4.1.1Trigger Events
4015

The Document Consumer obtains document(s) uniqueId via the Registry Stored Query
transaction. If the Registry Stored Query was sent to the Initiating Gateway the Document
Consumer shall address the Retrieve Document Set to the Initiating Gateway. In this case noRev. 9.0 Final Text – 2012-08-31

157

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4020

resolution of repositoryUniqueId is needed by the Document Consumer. The Document
Consumer shall specify the homeCommunityId element in the Retrieve Document Set
transaction if it was found in the entry containing the uniqueId of the document being retrieved.
For more information regarding the homeCommunityId see section 3.38.4.1.2.
Once the document(s) uniqueId have been obtained, the Document Consumer will start the
Retrieve Document Set Request with the Document Repository.
3.43.4.1.2 Message Semantics

4025

4030

4035

The Retrieve Document Set Request shall carry the following information:• A required repositoryUniqueId that identifies the repository from which the document is tobe retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId.
• A required documentUniqueId that identifies the document within the repository. This value
corresponds to the XDSDocumentEntry.uniqueId.
• If available, the homeCommunityId element that identifies the community holding the
document. The homeCommunityId element shall be specified if the XDSDocumentEntry
containing the uniqueId of the document contains the homeCommunityId attribute. See ITI
TF-2a: 3.18.4.1.2 for details.
The repositoryUniqueId associated to each document requested can be different therefore
allowing a single request to identify multiple repositories.
3.43.4.1.3 Expected Actions
When receiving a Retrieve Document Set Request, a Document Repository or an Initiating
Gateway shall generate a Retrieve Document Set Response containing the requested documents
or error codes if the documents could not be retrieved.

4040

4045

An XCA Initiating Gateway receiving the Retrieve Document Set Request shall use thehomeCommunityId to obtain the Web Services endpoint of the Responding Gateways or, in thecase where homeCommunityId identifies the local community, use the repositoryUniqueId toobtain the Web Services endpoint of the Document Repositories. The process of obtaining the
Web Services endpoint is not further specified in this transaction. The Initiating Gateway shallsend Cross Gateway Retrieves/Retrieve Document Set transactions to each appropriate
Responding Gateway/Document Repository, consolidate the results, and return them to theDocument Consumer.
3.43.4.1.3.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:

4050

1. The Document Consumer actor shall abide by the XDS Affinity Domain Policies
represented by the confidentialityCode in the metadata associated with the document. The
Document Consumer actor likely will have user access controls or business rulecapabilities to determine the details of how confidentiality codes apply to query results.
The details of this are product specific and not specified by IHE. These rules shall reduce

Rev. 9.0 Final Text – 2012-08-31

158

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4055

4060

the query results to only those that are appropriate to the current situation for that actor
and user.
2. The Document Consumer actor shall be able to be configured with Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the XDS Affinity Domain Policy. The details of this areproduct specific and not specified by IHE.
3.43.4.2 Retrieve Document Set Response
3.43.4.2.1 Trigger Events
This message will be triggered by a Retrieve Document Set Request Message
3.43.4.2.2 Message Semantics

4065

4070

4075

4080

The Retrieve Document Set Response Message shall carry the following information, for each of
the returned documents:• A homeCommunityId. This value shall be the same as the homeCommunityId value in the
Retrieve Document Set Request Message. If the homeCommunityId value is not present in
the Retrieve Document Set Request Message, this shall not be present.
• A required repositoryUniqueId that identifies the repository from which the document is tobe retrieved. This value shall be the same as the value of the repositoryUniqueId in theoriginal Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required documentUniqueId that identifies the document within the repository. This value
shall be the same as the documentUniqueId in the original Retrieve Document Set Request
Message. This value corresponds to the XDSDocumentEntry.uniqueId.
• The retrieved document as a XOP Infoset• The MIME type of the retrieved document• Errors or warnings in case the document(s) could not be retrieved successfully
3.43.4.2.3 Expected Actions
A Document Repository shall retrieve the document(s) indicated in the request.
The Document Repository shall return the document or an error code in case the document could
not be retrieved. The conditions of failure and possible error messages are given in the ebRS
standard and detailed in ITI TF-3: 4.1.13 Error Reporting.

4085

3.43.5 Protocol Requirements
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.

Rev. 9.0 Final Text – 2012-08-31

159

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4090

4095

The Retrieve Document Set transaction shall use SOAP12 and MTOM with XOP encoding(labeled MTOM/XOP in this specification). See ITI TF-2x: Appendix V for details. The
Document Repository shall:• Accept the Retrieve Document Set Request message in MTOM/XOP format.
• Generate the Retrieve Document Set Response message in MTOM/XOP format
The Document Consumer shall:• Generate the Retrieve Document Set Request message in MTOM/XOP format.
• Accept the Retrieve Document Set Response message in MTOM/XOP format.
WSDL Namespace Definitions

4100

4105

4110

ihe

urn:ihe:iti:xds-b:2007rs

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

lcm

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

query

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

Document Repository: These are the requirements for the Retrieve Document Set transaction
presented in the order in which they would appear in the Document Repository WSDL
definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace="urn:ihe:iti:xds-b:2007", schema="IHEXDS.xsd"• The /definitions/message/part/@element attribute of the Retrieve Document Set Request
message shall be defined as “ihe:RetrieveDocumentSetRequest”• The /definitions/message/part/@element attribute of the Retrieve Document Set Response
message shall be defined as “ihe:RetrieveDocumentSetResponse”• Refer to Table 3.43.5.b below for additional attribute requirements
To support the Asynchronous Web Services Exchange option on the Document Consumer, theDocument Repository shall support the use of a non-anonymous response EPR in the WSAddressing replyTo header.
Table 3.43.5.b: Additional Attribute Requirements
Attribute

Value/definitions/portType/operation@name

DocumentConsumer_
RetrieveDocumentSet/definitions/portType/operation/input/@wsaw:Actionurn:ihe:iti:2007:
RetrieveDocumentSet/definitions/portType/operation/output/@wsa
w:Action

urn:ihe:iti:2007:
RetrieveDocumentSetResp
onse/definitions/binding/operation/soap12:operati
on/@soapAction

urn:ihe:iti:2007:
RetrieveDocumentSet

Rev. 9.0 Final Text – 2012-08-31

160

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4115

These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in ITI TF-2b: 3.43.5.1 Sample SOAP Messages.
For informative WSDL for the Document Repository actor see in Appendix W.

4120

4125

4130

4135

4140

4145

4150

The <ihe:RetrieveDocumentSetRequest/> element is defined as:• One or more <ihe:DocumentRequest/> elements, each one representing an individual
document that the Document Consumer wants to retrieve from the Document Repository.
Each <ihe:DocumentRequest/> element contains:• A required <ihe:RepositoryUniqueId/> element that identifies the repository fromwhich the document is to be retrieved. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required <ihe:DocumentUniqueId/> that identifies the document within therepository. This value corresponds to the XDSDocumentEntry.uniqueId.
• An optional <ihe:HomeCommunityId/> element that corresponds to the homeattribute of the Identifiable class in ebRIM.
This allows the Document Consumer to specify one or more documents to retrieve from theDocument Repository.
The <ihe:RetrieveDocumentResponse/> element is defined as:• A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element• An optional sequence of <ihe:DocumentResponse/> elements containing• A <ihe:HomeCommunityId/> element. The value of this element shall be the same as
the value of the/RetrieveDocumentSetRequest/DocumentRequest/HomeCommunityId element in the
Retrieve Document Set Request Message. If the <ihe:HomeCommunityId/> element
is not present in the Retrieve Document Set Request Message, this value shall not bepresent.
• A required <ihe:RepositoryUniqueId/> that identifies the repository from which the
document is to be retrieved. The value of this element shall be the same as the valueof the /RetrieveDocumentSetRequest/DocumentRequest/RepositoryUniqueId elementin the original Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required <ihe:DocumentUniqueId/> that identifies the document within therepository. The value of this element shall be the same as the value of the/RetrieveDocumentSetRequest/DocumentRequest/DocumentUniqueId element in theoriginal Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.uniqueId.
• A required <ihe:Document/> element that contains the retrieved document inbase64binary encoded format• A required <ihe:mimeType/> element that indicates the MIME type of the retrieved
documentRev. 9.0 Final Text – 2012-08-31

161

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4155

The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall
status of the request: It shall contain one of the following values:
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

See ITI TF-3: 4.1.13 Error Reporting for the interpretation of these values.
4160

4165

4170

4175

4180

4185

For each document requested in a /RetrieveDocumentSetRequest/DocumentRequest element:• If a warning is reported when retrieving the document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be returned with:• @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning• @errorCode is specified• @codeContext contains the warning message• @location contains the DocumentUniqueId of the document requested• The document shall be returned in an instance of/RetrieveDocumentSetResponse/DocumentResponse/Document as a XOP Infoset. The
returned document and warning are correlated via the DocumentUniqueId.
• If an error is reported when retrieving a document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be returned with:• @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error• @errorCode is specified• @codeContext contains the error message• @location contains the DocumentUniqueId of the document requested• No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned• If the document is successfully retrieved (without warning) then no/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be present and a/RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned
containing the document as a XOP Infoset.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not
used in this transaction.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in thistransaction.

4190

A full XML Schema Document for the XDS.b types is available online on the IHE FTP site, see
ITI TF-2x: Appendix W.
Rev. 9.0 Final Text – 2012-08-31

162

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.43.5.1 Sample SOAP Messages

4195

The samples in the following two sections show a typical request and its relative response. The
sample messages also show the WS-Addressing headers <Action/>, <MessageID/>,<ReplyTo/>…; these WS-Addressing headers are populated according to ITI TF-2x: Appendix
V: Web Services for IHE Transactions.
3.43.5.1.1 Sample Retrieve Document Set SOAP Request
3.43.5.1.1.1 Synchronous Web Services Exchange

4200
4205
4210
4215
4220
4225
4230

4235

POST /tf6/services/xdsrepositoryb HTTP/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517;
type="application/xop+xml";
start="<0.urn:uuid:3448B7F8EA6E8B9DFC1289514997518@apache.org>";
start-info="application/soap+xml"
User-Agent: Axis2
Host: ihexds.nist.gov:5000--MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:3448B7F8EA6E8B9DFC1289514997518@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:To soapenv:mustUnderstand="1">http://localhost:5000/tf6/services/xdsrepositoryb</wsa:To><wsa:MessageID soapenv:mustUnderstand="1">urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:MessageID><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSet</wsa:Action></soapenv:Header><soapenv:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId><DocumentUniqueId>1.42.20101110141555.15</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517--

This request message is in MTOM/XOP format because request/response message pairs must
always be in the same format (MTOM/XOP vs. SIMPLE SOAP) and the response requires
MTOM/XOP: one part for descriptive metadata and a second part for document contents.
3.43.5.1.1.2 Asynchronous Web Services Exchange

4240
4245

<s:Envelope

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSet</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo>Rev. 9.0 Final Text – 2012-08-31

163

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4250
4255
4260
4265

<a:Address>
http://192.168.2.4:9080/XdsService/DocumentConsumerReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRepositoryReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId></DocumentRequest><DocumentRequest><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></s:Body></s:Envelope>3.43.5.1.2 Sample Retrieve Document Set SOAP Response
3.43.5.1.2.1 Synchronous Web Services Exchange
4270

4275
4280
4285
4290
4295
4300
4305

In the following example, the HTTP header Transfer-Encoding: chunked and thecorresponding chunk annotations were removed for readability.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310;
type="application/xop+xml";
start="0.urn:uuid:E910375860336E2B8F1289514978311@apache.org";
start-info="application/soap+xml";
Date: Thu, 11 Nov 2010 22:36:15 GMT--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:E910375860336E2B8F1289514978311@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action><wsa:RelatesTo>urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:RelatesTo></soapenv:Header><soapenv:Body><xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007"><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><xdsb:DocumentResponse><xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId><xdsb:DocumentUniqueId>1.42.20101110141555.15</xdsb:DocumentUniqueId><xdsb:mimeType>text/plain</xdsb:mimeType><xdsb:Document><xop:Include

Rev. 9.0 Final Text – 2012-08-31

164

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4310
4315
4320

4325

href="cid:1.urn:uuid:E910375860336E2B8F1289514978312@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include"/></xdsb:Document></xdsb:DocumentResponse></xdsb:RetrieveDocumentSetResponse></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:E910375860336E2B8F1289514978312@apache.org>
Four score and seven years ago our fathers brought forth on this continent a new nation,
conceived in Liberty, and dedicated to the proposition that all men are created equal.
--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310--

This example shows the ‘wire format’ for MTOM/XOP. The Document element contains a<xop:Include> element that points to the document contents as a separate attachment.
Note:

4330

4335
4340
4345
4350
4355
4360
4365

In some systems, the ‘in memory’ format replaces the <xop:Include> with the Base64 encoded contents of the
document. This is done so the entire message contents fits into an XML parse tree.

A second form of the response is possible, an un-optimized MTOM/XOP message. In this form
the message is still formatted as a multipart but the document contents is not split out into aseparate part of the multipart. Some popular Web Service toolkits generate this form for verysmall documents. The same response in this form looks like:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310;
type="application/xop+xml";
start="0.urn:uuid:E910375860336E2B8F1289514978311@apache.org";
start-info="application/soap+xml";
Date: Thu, 11 Nov 2010 22:36:15 GMT--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:E910375860336E2B8F1289514978311@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action><wsa:RelatesTo>urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:RelatesTo></soapenv:Header><soapenv:Body><xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007"><rs:RegistryResponse
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><xdsb:DocumentResponse><xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId><xdsb:DocumentUniqueId>1.42.20101110141555.15</xdsb:DocumentUniqueId><xdsb:mimeType>text/plain</xdsb:mimeType><xdsb:Document>

Rev. 9.0 Final Text – 2012-08-31

165

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4370
4375

Base64 encoded contents of document go here</xdsb:Document></xdsb:DocumentResponse></xdsb:RetrieveDocumentSetResponse></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310--

3.43.5.1.2.2 Asynchronous Web Services Exchange
4380
4385
4390
4395
4400
4405
4410

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentConsumerReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Success"/><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>3.43.6 Security Considerations
4415

Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3.43.6.1 Audit Record Considerations
The Retrieve Document Set Transaction is PHI-Export event, as defined in ITI TF-2a: Table
3.20.6-1. The Actors involved in the transaction shall create audit data in conformance with
DICOM (Supp 95) “Data Export”/”Data Import”, with the following exceptions.

4420

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 be heuristicallycombined. The heuristics for this combination are not specified by IHE. It is intended to reduce

Rev. 9.0 Final Text – 2012-08-31

166

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
the volume of audit records. Combination is permitted when the active participants and patient
are the same, and the time difference is considered insignificant.
4425

The Document Consumer Actor shall generate an “Import” event. This may be one event pertransaction, or multiple transactions may be reported as a single event using a heuristic for
combining transactions. Combination is permitted when the active participants and patient are
the same, and the time difference is considered insignificant.
3.43.6.1.1 Document Consumer audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-43”, “IHE Transactions”, “Retrieve Document Set”)

Source (Document Repository) (1)Destination (Document Consumer) (1)
Human Requestor (0..n)
Audit Source (Document Consumer) (1)Patient (0..1)
Document (1..n) (see combining rules above)

4430

Where:

SourceAuditMessage/
ActiveParticipant

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

Rev. 9.0 Final Text – 2012-08-31

167

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Destination

UserIDM

The content of the <wsa:ReplyTo/> element.

AuditMessage/
ActiveParticipant

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(9, RFC-3881, “Report Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(if-known)(AuditMessage/
ParticipantObjectIdenti
fication)

Document(AuditMessage/
ParticipantObjectIdenti
fication)

Rev. 9.0 Final Text – 2012-08-31

168

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The ParticipantObjectDetail element may occur more than once.
ParticipantObjectDetail

4435

M

In one element, the value of <ihe:RepositoryUniqueId/> in value
attribute, “Repository Unique Id” in type attribute
In another element, the value of “ihe:homeCommunityID” as the valueof the attribute type and the value of the homeCommunityID as thevalue of the attribute value

3.43.6.1.2 Document Repository audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-43”, “IHE Transactions”, “Retrieve Document Set”)

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

UserIDM

The content of the <wsa:ReplyTo/> element.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

Source (Document Repository) (1)Destination (Document Consumer) (1)Audit Source (Document Repository) (1)Document (1..n) (see combining rules above)
Where:

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Document

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (System)

Rev. 9.0 Final Text – 2012-08-31

169

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(9, RFC-3881, “Report Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

PARTICIPANTOBJECTQUERYU

not specialized
The ParticipantObjectDetail element may occur more than once.

ParticipantObjectDetail

In one element, the value of <ihe:RepositoryUniqueId/> in value
attribute, “Repository Unique Id” in type attribute

M

In another element, the value of “ihe:homeCommunityID” as the valueof the attribute type and the value of the homeCommunityID as thevalue of the attribute value

4440

3.44 Patient Identity Feed HL7 V3This section corresponds to Transaction ITI-44 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-44 is used by the Patient Identity Source, Patient Identifier Crossreference Manager and Document Registry Actors.
4445

3.44.1 Scope
The scope is identical to ITI TF-2a: 3.8.1.
3.44.2 Use Case Roles
Patient Identifier
Cross-referenceManager

Patient Identity
SourceDocument
Registry

Patient Identity
Feed HL7 V3

Actor: Patient Identity Source
4450

Role: Provides notification to the Patient Identifier Cross-reference Manager and Document
Registry for any patient identification related events including: creation, updates, merges, etc.
Corresponding HL7 v3 Application Roles:
Patient Registry Informer (PRPA_AR201301UV02)
Actor: Patient Identifier Cross-reference Manager

Rev. 9.0 Final Text – 2012-08-31

170

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4455

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.
Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)

4460

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).
Corresponding HL7 v3 Application Roles:

4465

Patient Registry Tracker (PRPA_AR201302UV02)
3.44.3 Referenced Standards
HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008).
3.44.4 Interaction Diagrams

Document RegistryorPatient Identifier
Cross-referenceManager

Patient Identity
SourcePatient Registry Record Added
PRPA_IN201301UV02

Patient Registry Record Revised
PRPA_IN201302UV02
Patient Registry Duplicates Resolved
PRPA_IN201304UV02
4470

Figure 3.44-1: Patient Identity Sequence

Rev. 9.0 Final Text – 2012-08-31

171

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.1 Patient Identity Management – Add or Revise Patient Record
3.44.4.1.1 Trigger Events
4475

The following events from a Patient Identity Source will trigger one of the Add or Revise Patient
Record messages:
Patient Registry Record Added (PRPA_TE201301UV02)
This trigger event signals that a new patient was added to a Patient Identity Source.
Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger
the following Patient Registry Record Revised message:

4480

Patient Registry Record Revised (PRPA_TE201302UV02)
This trigger event signals that patient information was revised in a Patient Identity Source.

4485

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.
3.44.4.1.2 Message Semantics

4490

The Patient Identity Feed transaction is carried out by the HL7 v3 Patient Activate(PRPA_MT201301UV02) and Patient Revise (PRPA_MT201302UV02) messages, as defined in
the subsequent sections. The Patient Identity Source shall generate the message whenever apatient is registered or when some piece of patient demographic data changes. The componentsof the message listed below are required, and their detailed descriptions are provided in thefollowing subsections.
Each message shall be acknowledged by the HL7 v3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.

4495

The message information model in ITI TF-2b: 3.44.4.1.2.2.describes the relevant data elements
for this transaction. Specific requirements for the particular actors are found in ITI TF-2b:
3.44.4.1.3 Expected Actions.
3.44.4.1.2.1 Major Components of the Patient Registry Record Added/Revised
Messages

4500

Patient

4505

The Patient class is the entry point to the R-MIMs for the Patient Activate(PRPA_RM201301UV02) and Patient Revise (PRPA_RM201302UV02) models. The patient
identifiers are captured using an Instance Identifier (II) data type. Please see ITI TF-2x:
Appendix E for a detailed description about the use of the HL7 V3 II data type for patient
identifiers.

Rev. 9.0 Final Text – 2012-08-31

172

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Provider Organization

4510

The Patient class is scoped by the provider organization where this person is a patient. The HL7
definition of the CMET requires that the provider organization needs to be identified by an id
attribute, and at least one of address, telecommunications address, or contact person to bepresent. The id attribute SHALL have only a root, expressed as an ISO OID.
Person4515

The Person class contains identifying and demographic data elements for the focal person
similar to those in the HL7 v2.x PID segment such as name, gender, date of birth, marital status
and deceased indicator and time.
Language Communication
Information about what language(s) should be used to communicate with the focal person can besent in the LanguageCommunication class.
PersonalRelationship

4520

This is used for sending information pertaining to the mother’s maiden name.
CitizenCitizenship information for a person, including citizen identifier and effective time can be sent in
the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code, ismandatory.

4525

4530

Other Identifiers
The OtherIDs class is used to capture other identifiers associated with the person such as adriver’s license number or social security number. In this transaction the IDs assigned by thescoping provider organization are represented in the id attribute of the Patient class. All other IDs
are represented in the OtherIDs class. For the purposes of interoperability where both HL7 V3and HL7 v2.x based transactions are used, the following requirement is imposed on the
OtherIDs.id attribute and on the scopingOrganization.id attribute:
OtherIDs.id.root SHALL be identical to scopingOrganization.id.root
scopingOrganization.id.extension SHALL NOT have any value
Please see ITI TF-2x: E.2 for details on the use of the II data type for patient identifiers.

4535

4540

3.44.4.1.2.2 Message Information Model of the Patient Registry Record
Added/Revised Messages
Below is the Message Information Model for both the Patient Activate and Patient Revise
messages, as restricted for this transaction. The purpose of the model is to describe the data
elements relevant for this transaction. It is a strict common subset of the Patient Activate(PRPA_RM201301UV02) and Patient Revise (PRPA_RM201302UV02) RMIMs. While HL7
defines two models for the two messages, a single common subset is sufficient for the purposesof this IHE transaction.

Rev. 9.0 Final Text – 2012-08-31

173

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4545

The base RMIMs can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201301UV.htm andEdition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions are
made on the original RMIMs to arrive at the restricted model:
The focal entity choice is restricted to be only a person
The relationship holder of the personal relationship is restricted to be a person (using CMET
COCT_MT030207UV)

4550

The provider organization which is scoping the patient role is required in both the Add andRevise messages (it is optional in the original Revise message definition).
The following roles are omitted:
asPatientOfOtherProvider
guarantor

4555

guardiancontactParty
asMembercareGiver
asStudent

4560

The following participations are omitted:
subjectOf (administrativeObservation)
coveredPartyOf (coverage)

Rev. 9.0 Final Text – 2012-08-31

174

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4565

Figure 3.44.4.1.2-1: RMIM Diagram

The attributes of this model are described in the following table. Note that CMETs are notdiscussed, as the HL7 definitions for them are being used.
Table 3.44.4.1.2-1:
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Patient

The primary record for the focal person in a Patient Identity SourceclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Identifiers designated by this patient identity source for the focal
personPatient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

confidentialityCode [0..*]

Value(s) that control the disclosure of information about this living

Rev. 9.0 Final Text – 2012-08-31

175

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Patient (SET<CE>) {CWE:Confidentiality}

subject as a patient

veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status granted by the scoperorganization, often resulting in preferred treatment and special
considerations. Examples include board member, diplomat.

PersonA subtype of LivingSubject representing a human being
Either Person.name or Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
telecom [0..*]

Telecommunication address(es) for communicating with this person

Person (BAG<TEL>)
administrativeGenderCode [0..1]

A value representing the gender (sex) of this person. Note: this
attribute does not include terms related to clinical gender which is acomplex physiological, genetic and sociological concept that
requires multiple observations in order to be comprehensively
described.

Person (CE) {CWE:AdministrativeGender}

birthTime [0..1]

The date and time this person was born

Person (TS)deceasedInd [0..1]

An indication that this person is dead

Person (BL)deceasedTime [0..1]

The date and time this person died

Person (TS)multipleBirthInd [0..1]

An indication that this person was part of a multiple birth

Person (BL)multipleBirthOrderNumber [0..1]

The order in which this person was born if part of a multiple birth

Person (INT)
addr [0..*]Address(es) for corresponding with this person

Person (BAG<AD>)maritalStatusCode [0..1]

A value representing the domestic partnership status of this person

Person (CE) {CWE:MaritalStatus}
religiousAffiliationCode [0..1]

A value representing the primary religious preference of this person

Person (CE) {CWE:ReligiousAffiliation}
raceCode [0..*]A set of values representing the races of this person

Person (SET<CE>) {CWE:Race}ethnicGroupCode [0..*]A set of values representing the ethnic groups of this person

Person (SET<CE>) {CWE:Ethnicity}

Rev. 9.0 Final Text – 2012-08-31

176

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number. Please see notes abovein the Major Components section on the use of OtherIDs.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role" except
for Citizen, or Employee.

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)
PersonalRelationship

A personal relationship between the focal living subject and anotherliving subject

classCode [1..1] (M)Structural attribute; this is a "personal relationship" role

Role (CS) {CNE:PRS, fixed value= "PRS"}
id [0..*]

Identifier(s) for this personal relationshipRole (SET<II>)code [1..1] (M)A required value specifying the type of personal relationshipbetween the relationshipHolder and the scoping living subject
drawn from the PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

Role (CE) {CWE:PersonalRelationshipRoleType}A value specifying the state of this personal relationship (based on
the RIM Role class state-machine), for example, following divorce
a spouse relationship would be "terminated".

statusCode [0..1]
Role (CE){CWE:RoleStatus}
effectiveTime [0..1]
Role (IVL<TS>)

An interval of time specifying the period during which this personal
relationship is in effect, if such time is applicable and known.

CitizenUsed to capture person information relating to citizenship.

classCode [1..1] (M)Structural attribute; this is a "citizen" role

Role (CS) {CNE:CIT, fixed value= "CIT"}
id [0..*]

Identifier(s) for the focal person as a citizen of a nationRole (SET<II>)
effectiveTime [0..1]

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

Employee (IVL<TS>)
NationA politically organized body of people bonded by territory andknown as a nation.

classCode [1..1] (M)Structural attribute; this is a 'nation' type of entity

Organization (CS) {CNE:NAT, fixed value= "NAT"}
determinerCode [1..1] (M)Structural attribute; this is a specific entity

Organization (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
code [1..1] (M)A value that identifies a nation state

Organization (CD) {CWE:NationEntityType}name [0..1]

Rev. 9.0 Final Text – 2012-08-31

A non-unique textual identifier or moniker for this nation

177

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Organization (ON)
Employee

A relationship of the focal person with an organization to receive
wages or salary. The purpose of this class is to identify the type of
relationship the employee has to the employer rather than the natureof the work actually performed. For example, it can be used tocapture whether the person is a Military Veteran or not..

classCode [1..1] (M)Structural attribute; this is an "employee" role

Employee (CS) {CNE:EMP}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
effectiveTime [0..1]

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

Employee (IVL<TS>)
occupationCode [0..1]

A code qualifying the classification of kind-of-work based upon arecognized industry or jurisdictional standard. OccupationCode isused to convey the person's occupation as opposed to jobClassCode(not used in this transaction) which characterizes this particular job.
For example, it can be used to capture whether the person is a
Military Veteran or not.

Employee (CE) {CWE:EmployeeOccupationCode}BirthPlace

The birthplace of the focal living subject.

classCode [1..1] (M)Structural attribute; this is a "birthplace" role.

Birthplace (CS) {CNE:BIRTHPL}
id [0..*]

A living subject's birth place represented by a unique identifier.

Birthplace (SET<II>)addr [0..*]Patient (BAG<AD>)

A living subject's birth place represented as an address. Note:
Either BirthPlace.addr or an associated Place.name must be valued.

classCode [1..1] (M)Structural attribute; this is a "birthplace" role.

Birthplace (CS) {CNE:BIRTHPL}
LanguageCommunication

A language communication capability of the focal person

languageCode [1..1] (M)A value representing a language for which the focal person has
some level of proficiency for written or spoken communication.
Examples: Spanish, Italian, German, English, American Sign

LanguageCommunication (CE){CWE:HumanLanguage}
preferenceInd [0..1]

An indicator specifying whether or not this language is preferred by
the focal person for the associated mode

LanguageCommunication (BL)Rev. 9.0 Final Text – 2012-08-31

178

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.1.2.3 Control Act and Transmission Wrappers
4570

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thetwo interactions, and the associated constraints.
Table 3.44.4.1.2-2: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201301UV02 or PRPA_IN201302UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201301UV02 or
PRPA_TE201302UV02 respectively

The value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

4575

RegistrationEvent.statusCode SHALL be set to“active”
There SHALL be no InReplacementOf act
relationship for these interactions.

The composite message schemas which describe the full payload of these interactions, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the HL7 V3
2008 Normative Edition schemas are at
Edition2008/processable/multicacheschemas/PRPA_IN201301UV02.xsd andEdition2008/processable/multicacheschemas/PRPA_IN201302UV02.xsd).
3.44.4.1.2.4 Web Services Types and Messages

4580

The Patient Registry Record Added/Revised messages will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.
The following WSDL naming conventions SHALL apply:

4585“add” message-> "PRPA_IN201301UV02_Message"“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:

4590

4595

4600

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201301UV02.xsd"/><xsd:element name="PRPA_IN201301UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201302UV02.xs
d"/>Rev. 9.0 Final Text – 2012-08-31

179

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4605

4610

4615

<xsd:element name="PRPA_IN201302UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…

The messages are described by the following snippet:

4620

4625

4630

…
<message name="PRPA_IN201301UV02_Message"><part element="hl7:PRPA_IN201301UV02" name="Body"/></message><message name="PRPA_IN201302UV02_Message"><part element="hl7:PRPA_IN201302UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Identity Feed Service are described together
with the expected actions of the actors which receive these messages in sections ITI TF-2b:
3.44.4.1.3 and TF-2b: 3.44.4.1.4.
3.44.4.1.3 Expected Actions – PIX Manager

4635

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes specified
in Table 3.44.4.1.2-1 above. This is to ensure that the Patient Identifier Cross-reference Manager
can handle a sufficient set of corroborating information in order to perform its cross-referencing
function.
The Patient Identifier Cross-reference Manager shall only recognize a single Patient Identity
Source per domain.
The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient
Identifier Cross-reference Manager, but its specification is beyond the scope of IHE.

4640

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 sendout notification to any Patient Identifier Cross-reference Consumers that have been configured as
being interested in receiving such notifications using the PIX Update Notification HL7 V3transaction (see ITI TF-2b: 3.46 for the details of that transaction).

4645

3.44.4.1.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.

Rev. 9.0 Final Text – 2012-08-31

180

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXManager":“add” message-> "PRPA_IN201301UV02_Message"“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType-> "PIXManager_PortType"add operation-> "PIXManager_PRPA_IN201301UV02"
revise operation -> "PIXManager_PRPA_IN201302UV02"
SOAP 1.2 binding -> "PIXManager_Binding_Soap12"
SOAP 1.2 port-> "PIXManager_Port_Soap12"

4650

4655

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
4660

4665

4670

4675

3.44.4.1.3.1.1 Port Type<portType name="PIXManager_PortType"><operation name="PIXManager_PRPA_IN201301UV02"><input message="tns:PRPA_IN201301UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201301UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation><operation name="PIXManager_PRPA_IN201302UV02"><input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201302UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.44.4.1.3.1.2 Bindings
SOAP 1.2 binding:
…

4680

4685

4690

4695

<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXManager_PRPA_IN201301UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201301UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PIXManager_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/><input><wsoap12:body use="literal"/></input><output>

Rev. 9.0 Final Text – 2012-08-31

181

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4700

…

<wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Manager implementing the PIXV3 profile is available online
on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.1.3.2 Message Examples
4705

Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.1.4 Expected Actions – Document Registry4710

The Document Registry shall be capable of accepting attributes in the Patient Registry Record
Added or Patient Registry Record Revised messages as specified in Table 3.44.4.1.2-1. The
Patient Identity Feed transaction contains more than what the XDS Document Registry needs for
its operation.
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, if present in a received message, shall beignored.

4715

3.44.4.1.4.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “DocumentRegistry”.
The following WSDL naming conventions SHALL apply:

4720

4725

wsdl:definitions/@name="DocumentRegistry":"add" message-> "PRPA_IN201301UV02_Message""revise" message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType-> "DocumentRegistry_PortType"add operation-> "DocumentRegistry_PRPA_IN201301UV02"
revise operation -> "DocumentRegistry_PRPA_IN201302UV02"
SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port-> "DocumentRegistry_Port_Soap12"

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
4730

3.44.4.1.3.1.1 Port Type

4735

<portType name="DocumentRegistry_PortType"><operation name="DocumentRegistry_PRPA_IN201301UV02"><input message="tns:PRPA_IN201301UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201301UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation>Rev. 9.0 Final Text – 2012-08-31

182

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4740

4745

<operation name="DocumentRegistry_PRPA_IN201302UV02"><input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201302UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.44.4.1.3.1.2 Bindings
SOAP 1.2 binding:
…

4750

4755

4760

4765

4770

<binding name="DocumentRegistry_Binding_Soap12"
type="DocumentRegistry_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="DocumentRegistry_PRPA_IN201301UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201301UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="DocumentRegistry_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

An informative WSDL for the Document Registry implementing the XDS.b profile is available
online on the IHE FTP site, see ITI TF-2x: Appendix W.
4775

3.44.4.1.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.2 Patient Identity Management – Patient Identity Merge
3.44.4.2.1 Trigger Events

4780

When two patients’ records are found to identify the same patient by a Patient Identity Source ina Patient Identifier Domain, the Patient Identity Source shall indicate this information using thefollowing trigger:
Patient Registry Duplicates Resolved (PRPA_TE201304UV02)

Rev. 9.0 Final Text – 2012-08-31

183

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This trigger event signals that duplicate records were resolved in a patient registry.
4785

A Patient Registry Duplicates Resolved message indicates that the Patient Identity Source hasdone a merge within a specific Patient Identification Domain. That is, the surviving identifier(patient ID) has subsumed a duplicate patient identifier.
3.44.4.2.2 Message Semantics

4790

The Patient Registry Duplicates Resolved interaction is carried out by the HL7 v3 Patient
Demographics message (PRPA_MT201303UV02). The message shall be generated by thesystem (Patient Identity Source) that performs the update whenever two patient records are found
to reference the same person.
The components of the HL7 Merge Patient message listed below are required, and the detailed
description of the message is provided in Sections ITI TF-2b: 3.44.4.2.2.1 to 3.44.4.2.2.4.

4795

4800

4805

Each message shall be acknowledged by the HL7 v3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.
When two Patient identifiers are to be merged, the subsumed identifier is referenced in theRegistry Trigger Event Control Act Wrapper and the payload is sent for the surviving identifier.
For example, if Patients A, B, and C are all to be merged into Patient B, then two messages aresent. In the first message Patient A’s identifier is referenced in the Registry Trigger EventControl Act Wrapper via the replacementOf act relationship and Patients B’s identifier isreferenced in the Patient class of the payload. In the second message Patient C’s identifier isreferenced in the wrapper, and Patient B’s identifier is, again, in the payload.
The message information model in ITI TF-2b: 3.44.4.2.2.2 describes the relevant data elements
for this transaction. Specific requirements for the particular actors are found in ITI TF-2b:
3.44.4.2.3 Expected Actions.
3.44.4.2.2.1 Major Components of the Patient Registry Duplicates Resolved
Patient

4810

The Patient class is the entry point to the R-MIM for the Patient Demographics(PRPA_RM201303UV02) in the Patient Identity Source. The patient identifier is represented
using an Instance Identifier (II) data type. Please see ITI TF-2x: Appendix E for a detailed
description about the use of the HL7 V3 II data type for patient identifiers.
Provider Organization

4815

The Patient class is scoped by the provider organization which is the assigning authority for thepatient’s identifier. For this message the provider organization class is optional. The HL7
definition of the CMET requires that the provider organization needs to be identified by an id
attribute, and at least one of address, telecommunications address, or contact person to bepresent. The id attribute SHALL have only a root expressed as an ISO OID, and it shall matchthe root of the Patient.id attribute
PersonRev. 9.0 Final Text – 2012-08-31

184

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4820

The Person class contains the name for the focal person (similarly to the requirement for the
HL7 v2.x PID segment).
3.44.4.2.2.2 Message Information Model of the Patient Registry Duplicates
Resolved Message

4825

Below is the Message Information Model for the Duplicates Resolved message, as restricted forthis transaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Demographics (PRPA_RM201303UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201303UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:

4830

The focal entity choice is restricted to be only a person
All optional classes are removed
All optional attributes in the Patient and Person class are removed

4835

This restricted model makes clear the purpose of this message – it is to inform about the mergeof identities in the Patient Identity Source. If there are any updates to the demographics of thepatient in question, this information shall be relayed via a Patient Registry Record Revised
message. This follows the semantics of the Patient Identity Feed transaction as defined in ITI TF2a: 3.8, and is a restriction on the semantics of this message as defined by HL7 (where any
demographics information can be updated with the Duplicates Resolved message).
The provider organization is also optionally available.

4840

Figure 3.44.4.2.2-1: Message Information Model for Duplicates Resolved Message

Rev. 9.0 Final Text – 2012-08-31

185

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
The attributes of this model are described in the following table.
Table 3.44.4.2.2-1: Model Attributes
PRPA_HD201303IHE
Duplicates Resolved

This HMD extract defines the message used toreport that two patient identifiers were merged (i.e.,a duplicate was resolved).
Derived from Figure 3.44.4.2.2-1(PRPA_RM201303IHE)

Patient

The primary record for the focal person in a Patient Identity SourceclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Identifiers designated by various patient identity sources for the
focal person

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human being
Both Person.name and Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)

3.44.4.2.2.3 Control Act and Transmission Wrappers
4845

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.44.4.2.2-3: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201304UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201304UV02

The value of processingModeCode SHALL be set to T

RegistrationEvent.statusCode SHALL be set to“active”

The acceptAckCode SHALL be set to AL

There SHALL be an InReplacementOf act
relationship

There SHALL be only one receiver Device

The value of PriorRegistration.statusCode SHALL be“obsolete”
There SHALL be a PriorRegisteredRole role
There SHALL be a single PriorRegisteredRole.id
attribute, representing the subsumed patient
identifier.

Rev. 9.0 Final Text – 2012-08-31

186

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4850

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201304UV02.xsd).
3.44.4.2.2.4 Web Services Types and Messages

4855

The Patient Registry Resolve Duplicates message will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.
The following WSDL naming conventions SHALL apply:"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
Acknowledgement

4860

4865

4870

4875

4880

-> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201304UV02.xsd"/><xsd:element name="PRPA_IN201304UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…

The messages are described by the following snippet:

4885

4890

…
<message name="PRPA_IN201304UV02_Message"><part element="hl7:PRPA_IN201304UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Resolved Duplicates Service are described together
with the expected actions of the actors which receive these messages in ITI TF-2b: 3.44.4.2.3
and 3.44.4.2.4.

Rev. 9.0 Final Text – 2012-08-31

187

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.2.3 Expected Actions – PIX Manager
4895

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
Resolve Duplicates message as specified in Table 3.44.4.2.2-1.
The Patient Identifier Cross-reference Manager shall perform the Expected Actions similar to theones specified in ITI TF-2a: 3.8.4.2.3. The particular behavior is described below.

4900

4905

When the Patient Identifier Cross-reference Manager receives the Resolve Duplicates message
type of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers
provided in the wrapper and the payload of the message by replacing any references it ismaintaining internally to the patient ID provided in the wrapper by the patient ID included in the
payload. After the identifier references are replaced, the Patient Identifier Cross-referenceManager shall reapply its internal cross-referencing logic/ policies before providing the updated
information via either the PIX Query or PIX Notification Transactions.
3.44.4.2.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXManager":“merge” message -> "PRPA_IN201304UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType-> "PIXManager_PortType"merge operation -> "PIXManager_PRPA_IN201304UV02"
SOAP 1.2 binding -> "PIXManager_Binding_Soap12"
SOAP 1.2 port-> "PIXManager_Port_Soap12"

4910

4915

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
3.44.4.2.3.1.1 Port Type
4920

4925

<portType name="PIXManager_PortType"><operation name="PIXManager_PRPA_IN201304UV02"><input message="tns:PRPA_IN201304UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201304UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.44.4.2.3.1.2 Bindings
4930

4935

SOAP 1.2 binding:…

<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXManager_PRPA_IN201304UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201304UV02"/>
Rev. 9.0 Final Text – 2012-08-31

188

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4940

4945

…

<input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Manager implementing the PIXV3 profile is available online
on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.2.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
4950

3.44.4.2.4 Expected Actions – Document Registry
The Document Registry shall be capable of accepting attributes in the Resolve Duplicatesmessage as specified in Table 3.44.4.2.2.2-1. Other attributes may exist, but the Document
Registry shall ignore them.

4955

4960

4965

The Document Registry shall perform the Expected Actions similar to the ones specified in ITI
TF-2a: 3.8.4.2.4. The particular behavior is described below.
When the Document Registry receives the Resolve Duplicates message of the Patient Identity
Feed transaction, it shall merge the patient identity specified in the PriorRegistrationRole.id
attribute of the Control-Act wrapper (subsumed patient identifier) into the patient identity
specified in Patient.id attribute of the message payload (surviving patient identifier) in its
registry. After the merge, all Document Submission Sets (including all Documents and Folders
beneath them) under the secondary patient identity before the merge shall point to the primarypatient identity. The secondary patient identity shall no longer be referenced in the futureservices provided by the Document Registry.
Changes resulting from a Resolve Duplicates message are not reversible. No un-resolve message
is supported by this transaction.
See ITI TF-2a: 3.18.4.1.2.3.8.1 of the Technical Framework for details of how this message typeaffects results of a Stored Query transaction and the end of ITI TF-2a: 3.14.4.1.2.12 to see how it
affects the Register transaction.

4970

4975

A Resolve Duplicates message contains two attributes of interest:• PriorRegistrationRole.id – subsumed patient identifier: the patient identifier which is tobecome obsolete• Patient.id – surviving patient identifier: the patient identifier which is to remain active.
After a duplicate resolution, the Patient.id attribute represents all records formerly represented byeither the Patient.id attribute or the PriorRegistrationRole.id attribute. All other attributes may beignored.

Rev. 9.0 Final Text – 2012-08-31

189

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

4980

4985

The following conditions shall be detected by the Document Registry. Messages containing these
conditions shall not update the state of the Document Registry.
• The subsumed patient identifier is not issued by the correct Assigning Authority according to
the Affinity Domain configuration.
• The surviving patient identifier is not issued by the correct Assigning Authority according to
the Affinity Domain configuration.
• The subsumed and surviving patient identifiers are the same.
• The subsumed patient identifier has already been subsumed by an earlier message.
• The surviving patient identifier has already been subsumed by and earlier message.
• The subsumed patient identifier does not convey a currently active patient identifier known
to the Document Registry.
If none of the above conditions occur then the Document Registry shall perform the following
duties:

4990

4995

5000

1.

Records the merge. Only the subsumed and surviving patient identifiers need beremembered. A patient identifier merge affects the processing of future Register
Document Set [ITI-14] transactions. See ITI TF-2a: 3.14.4.1.2.12 XDS Registry
Adaptor for details.

2.

Multiple merge transactions can form a recorded merge chain, where the Subsumed
identifier of the current merge is the Surviving identifier of a previous merge.

3.

Register Document Set transactions referencing a subsumed identifier are rejected with
an XDSUnknownPatientId error.

4.

Stored Query transactions referencing a subsumed identifier return no content.

5.

Stored Query transactions referencing a surviving identifier successfully match theentire recorded merge chain and return appropriate metadata.

6.

No change in the Registry Query transaction.

Note: This transaction does not specify how the merge is to be implemented. It may or may not change the stored form of
the metadata. It only specifies the observable results from the perspective of the Registry Stored Query
transaction [ITI-18] and the Register Document Set-b transaction [ITI-42].

3.44.4.2.4.1 Web Services Port Type and Binding Definitions
5005

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “DocumentRegistry”.
The following WSDL naming conventions SHALL apply:5010

wsdl:definitions/@name="DocumentRegistry":"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "DocumentRegistry_PortType"
resolve duplicates operation -> "DocumentRegistry_PRPA_IN201304UV02"
SOAP 1.2 binding-> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port-> "DocumentRegistry_Port_Soap12"

Rev. 9.0 Final Text – 2012-08-31

190

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
5015

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
3.44.4.2.4.1.1 Port Type

5020

5025

<portType name="DocumentRegistry_PortType"><operation name="DocumentRegistry_PRPA_IN201304UV02"><input message="tns:PRPA_IN201304UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201304UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.44.4.2.4.1.2 Bindings
SOAP 1.2 binding:
5030

5035

5040

…

<binding name="DocumentRegistry_Binding_Soap12"
type="DocumentRegistry_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="DocumentRegistry_PRPA_IN201304UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201304UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

5045
An informative WSDL for the Document Registry implementing the XDS.b profile is available
online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.2.4.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
5050

3.44.5 Security Requirements
This transaction is generally used in profiles that require actors to be grouped with a Secure
Node 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 XDS Affinity
Domain Audit Record Repository.

5055

The use of ATNA along with XDS does require that each member of the XDS Affinity Domain
have audit and security mechanisms in place. See ITI TF-1: Appendix G and ITI-TF-2x:
Appendix K.
Rev. 9.0 Final Text – 2012-08-31

191

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5060

The individual actors involved are often members of different secure domains. The data transfers
between different secure domains need different protection than transfers within a secure domain
and shall be encrypted with TLS authentication of both hosts.
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 XDS Affinity Domain business relationships
and no IHE Integration Profile is specified at this time, see ITI TF-1: Appendix L.

5065

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 XDS Affinity Domain is managed and controlled by
the business relationship terms of the XDS Affinity Domain. There is no automatic IHE
transaction for such access.

5070

3.44.5.1 Security Audit Record
When grouped with ATNA Secure Node or Secure Application actors, this transaction is to beaudited as “Patient Record” event, as defined in ITI TF-2a: Table 3.20.6-1. The following tables
show items that are required to be part of the audit record for this transaction.

5075

Logically, a merge operation consists of a delete on one patient record, and an update of another
patient record. Separate audit records shall be written for the delete operation and the update
operation.
3.44.5.1.1 Patient Identity Source audit message
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCodeM“C” (create) , “U” (update), or “D” (delete) as appropriate

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)

Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identity Source Actor) (1)Patient (1)Where:

Rev. 9.0 Final Text – 2012-08-31

192

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

5080
Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format (see ITI TF-2x: appendix E)

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

Patient(AuditMessage/
ParticipantObjectIdentifi
cation)3.44.5.1.2 Patient Identifier Cross-reference Manager audit message
Field Name
Event

EventID

Rev. 9.0 Final Text – 2012-08-31

Opt
M

193

Value Constraints
EV(110110, DCM, “Patient Record”)

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
EventActionCodeM“C” (create) , “U” (update), or “D” (delete) as appropriate

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)

Source (Patient Identity Source Actor) (1)Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)Patient(1)Where:
UserIDM
the content of the <wsa:ReplyTo/> element
SourceAuditMessage/
ActiveParticipant

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

5085
Destination
AuditMessage/
ActiveParticipant

Patient(AuditMessage/
ParticipantObjectIdentifi
cation)Rev. 9.0 Final Text – 2012-08-31

194

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.5.1.3 Document Registry audit message
5090

Document Registry audit message are the same as Patient Identifier Cross-reference Manager
audit message as presented in section ITI TF-2b: 3.44.5.1.2

3.45 PIXV3 Query
5095

This section corresponds to Transaction ITI-45 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-45 is used by the Patient Identifier Cross-reference Consumer andPatient Identifier Cross-reference Manager actors.
3.45.1 Scope
The scope is identical to ITI TF-2a: 3.9.1, PIX Query Scope.
3.45.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIXV3 Query

5100

Actor: Patient Identifier Cross-reference Consumer
Role: Queries the Patient Identifier Cross-reference Manager for a list of corresponding patient
identifiers, if any
Corresponding HL7 v3 Application Roles:
Patient Registry Query Placer (PRPA_AR201303UV02)

5105

Actor: Patient Identifier Cross-reference Manager
Role: Manages the cross-referencing of patient identifiers across Patient Identification Domains.
Upon request it returns a list of corresponding patient identifiers, if any.
Corresponding HL7 v3 Application Roles:
Patient Registry Query Fulfiller (PRPA_AR201304UV02)

5110

3.45.3 Referenced Standards
HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008)
Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.

Rev. 9.0 Final Text – 2012-08-31

195

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
5115

3.45.4 Interaction Diagrams
Patient Identity
Cross-Reference
Consumer

Patient Identifier
Cross-ReferenceManager

Patient Registry Get Identifiers Query
PRPA_IN201309UV02
Patient Registry Get Identifiers Query Response
PRPA_IN201310UV02

3.9B-1: Get Corresponding Identifiers Sequence

3.45.4.1 Get Corresponding Identifiers
3.45.4.1.1 Trigger Events
5120

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:
Patient Registry Get Identifiers Query (PRPA_TE201309UV02)
This query requests all other identifiers associated with a particular person identifier.

5125

3.45.4.1.2 Message Semantics

5130

The Get Corresponding Identifiers transaction is initiated by the HL7 Patient Registry Query by
Identifier (PRPA_MT201307UV02) message. The Patient Identifier Cross-reference Consumer
shall generate the query message whenever it needs to obtain corresponding patient identifier(s)from other Patient Identification Domain(s). The components of the message listed below arerequired, and their detailed descriptions are provided in the following subsections.

5135

The receiver shall respond to the query by sending the Patient Identifiers message(PRPA_MT201304UV02), which uses the Application Level Acknowledgement transmission
wrapper. This satisfies the requirements of original mode acknowledgment; no intermediate
Accept Acknowledgement message is to be sent. All appropriate identifiers shall be returned in asingle response; therefore no continuation queries are allowed in this transaction.

Rev. 9.0 Final Text – 2012-08-31

196

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.45.4.1.2.1 Major Components of the Patient Registry Query by Identifier
PatientIdentifier Parameter
5140

This required parameter specifies the identifier associated with the person whose information is
being queried. For this parameter item, a single patient identifier is specified in thePatientIdentifier.value attribute. Please see Appendix E for the use of the II data type for patient
identifiers.
DataSource Parameter

5145

This optional parameter specifies the assigning authority/authorities of the Patient Identity
Domain(s) whose identifiers need to be returned. If no such parameter is supplied, the PIXManager is required to return the identifiers from all known Patient Identity Domains.
3.45.4.1.2.2 Message Information Model of the Patient Registry Query by Identifier
Message

5150

5155

Below is the Message Information Model for the Query by Identifier message, as restricted forthis transaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Registry Query by Identifier(PRPA_RM201307UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201307UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:
Exactly one PatientIdentifier parameter SHALL be present
Exactly one PatientIdentifier.value attribute SHALL be present
If one or more DataSource parameters are present, each SHALL contain exactly one
DataSource.value parameter

5160

The optional attributes ParameterList.id, QueryByParameter responseElementGroupId,
QueryByParameter.modifyCode, and QueryByParameter.executionAndDeliveryTime were
removed from the model
QueryByParameter.responsePriorityCode is required and is fixed to I (Immediate)
QueryByParameter.statusCode is defaulted to "new".

5165

Rev. 9.0 Final Text – 2012-08-31

197

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Figure 3.45.4.1.2-1: Message Information Model for the Query by Identifier message

The attributes of this model are described in the following table.
5170

Table 3.45.4.1.2-2: Model Attributes
PRPA_HD201307IHE
Patient Registry Query by IdentifierThis HMD extract defines the message used toquery a patient registry for a list of identifiers.
Derived from Figure 3.45.4.1.2-1(PRPA_RM201307IHE)

QueryByParameter

The entry point for the domain content in this query

queryId [1..1]
QueryByParameter (II)Unique identifier for the query

statusCode [1..1] (M)QueryByParameter (CS) {CNE:QueryStatusCode,
fixed value="new"}

There are no continuations necessary for this type of query, so thestatus is always "new"responsePriorityCode [1..1]
QueryByParameter (CS) {CNE:QueryPriority, fixed

The PIX manager is required to send an immediate response.

Rev. 9.0 Final Text – 2012-08-31

198

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201307IHE
Patient Registry Query by IdentifierThis HMD extract defines the message used toquery a patient registry for a list of identifiers.
Derived from Figure 3.45.4.1.2-1(PRPA_RM201307IHE)

value="I"}
DataSource

Optional parameter specifying the assigning authority of a Patient
Identity Domain

value [1..1]
ParameterItem (II)The identifier for the Patient Identity Domain's assigning authority.
IHE restriction:
The value.root attribute SHALL be a valid ISO OID
The value.extension attribute SHALL NOT be present

semanticsText [1..1]
ParameterItem (ST){default= "DataSource.id"}
PatientIdentifier
value [1..1] (M)ParameterItem (II)The patient identifier known to the PIX Consumer

semanticsText [1..1]
ParameterItem (ST){default= "Patient.id"}

The Patient Identifier Cross-reference Consumer shall provide the patient identifier in thePatientIdentifier.value attribute according to the rules specified in ITI TF-2x: Appendix E.
5175

5180

5185

If the requesting system wishes to select the Patient Identity Domains from which patient
identifiers are returned, it does so by sending as many DataSource parameters as domains forwhich it wants to receive patient identifiers. Each instance of the DataSource parameter shallprovide the Assigning Authority identifier for a specific domain using the DataSource.value
attribute. Note that the DataSource.value.extension attribute shall not be provided, and the
DataSource.value.root attribute shall contain a valid ISO OID. The responding system shallreturn the Patient.id value for each requested domain, if a value is known. Note that the value ofPatient.id.root attribute shall match the DataSource.value.root attribute representing thecorresponding Assigning Authority.
If no DataSource parameter is specified the Patient Identifier Cross-reference Manager shallreturn patient identifiers for all domains for which it possesses a corresponding identifier (subject
to local publication restrictions).
3.45.4.1.2.3 Control Act and Transmission Wrappers
Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.

5190
Table 3.45.4.1.2-4: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

Rev. 9.0 Final Text – 2012-08-31

199

QUQI_MT021001UV01 – Query Control Act
Request: Query By Parameter

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Transmission Wrapper

Trigger Event Control Act Wrapper

The value of interactionId SHALL be set to
PRPA_IN201309UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN

The value of processingModeCode SHALL be set to T

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201309UV02

The acceptAckCode SHALL be set to AL

The value of authorOrPerformer.typeCode SHALL
be set to AUT

There SHALL be only one receiver Device

5195

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition are at
Edition2008/processable/multicacheschemas/PRPA_IN201309UV02.xsd).
3.45.4.1.2.4 Web Services Types and Messages
The Patient Registry Query by Identifier message and response will be transmitted using Web
Services, according to the requirements specified in ITI TF-2x: Appendix V.

5200

The following WSDL naming conventions SHALL apply:

Query by Identifier -> "PRPA_IN201309UV02_Message"
Query Response-> "PRPA_IN201310UV02_Message"

The following WSDL snippet describes the types for these messages:
5205

5210

5215

5220

5225

5230

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201309UV02.xsd"/><xsd:element name="PRPA_IN201309UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201310UV02.xsd"/><xsd:element name="PRPA_IN201310UV02"/></xsd:schema></types>…

The messages are described by the following snippet:…
<message name="PRPA_IN201309UV02_Message"><part element="hl7:PRPA_IN201309UV02" name="Body"/></message><message name="PRPA_IN201310UV02_Message"><part element="hl7:PRPA_IN201310UV02" name="Body"/></message>Rev. 9.0 Final Text – 2012-08-31

200

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The port types for the WSDL describing the Resolved Duplicates Service are described together
with the expected actions of the actors which receive these messages in sections ITI TF-2b:3.45.4.1.3.
5235

3.45.4.1.3 Expected Actions
The Patient Identifier Cross-reference Manager shall be capable of accepting attributes as
specified in Table 3.45.4.1.2-1 above.

5240

The Patient Identifier Cross-reference Manager shall be capable of accepting multiple concurrent
PIX Query requests (Get Corresponding Identifiers messages) and responding correctly using the
Return Corresponding Identifiers message.
3.45.4.1.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXManager":"get identifiers" query-> "PRPA_IN201309UV02_Message""get identifiers" response -> "PRPA_IN201310UV02_Message"
portType-> "PIXManager_PortType"get identifiers operation -> "PIXManager_PRPA_IN201309UV02"
SOAP 1.2 binding-> "PIXManager_Binding_Soap12"
SOAP 1.2 port-> "PIXManager_Port_Soap12"

5245

5250

The following WSDL snippets specify the PIXV3 Query Port Type and Binding definitions,according to the requirements specified in ITI TF-2x: Appendix V.
5255

5260

3.45.4.1.3.1.1 Port Type<portType name="PIXManager_PortType"><operation name="PIXManager_PRPA_IN201309UV02"><input message="tns:PRPA_IN201309UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201309UV02"/><output message="tns:PRPA_IN201310UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201310UV02"/></operation></portType>3.45.4.1.3.1.2 Bindings
5265

5270

SOAP 1.2 binding:…

<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXManager_PRPA_IN201309UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201309UV02"/><input><wsoap12:body use="literal"/></input>

Rev. 9.0 Final Text – 2012-08-31

201

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
5275

5280

…

<output><wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Manager implementing the PIXV3 profile is available online
on the IHE FTP site, see ITI TF-2x: Appendix W.
3.45.4.1.3.2 Message Examples
5285

Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.45.4.2 Return Corresponding Identifiers
3.45.4.2.1 Trigger Events
The Patient Identifier Cross-reference Manager’s response to the Get Corresponding Identifiers
message will trigger the following message:

5290

Patient Registry Get Identifiers Query Response (PRPA_TE201310UV02)
This query response returns all other identifiers associated with a particular person identifier.
3.45.4.2.2 Message Semantics

5295

The Return Corresponding Identifiers message is conducted by the HL7 Patient Identifiers
message. The Patient Identifier Cross-reference Manager shall generate this message in direct
response to the Patient Registry Query by Identifier message previously received. This message
satisfies the Application Level, Original Mode Acknowledgement for the query message.
3.45.4.2.2.1 Major Components of the Get Corresponding Identifiers Query
Response
Patient

5300

The Patient class is the entry point to the R-MIM for the Patient Identifiers(PRPA_RM201304UV02). This is where at least one of the requested patient IDs will be listed.
PersonThe Person class contains the name of the patient for additional verification purposes.
Provider Organization

5305

The Patient class is optionally scoped by the provider organization where this person is a patient.
The HL7 definition of the CMET requires that the provider organization needs to be identified
by an id attribute, and at least one of address, telecommunications address, or contact person to
be present. The id attribute SHALL have only a root, expressed as an ISO OID, and at least one

Rev. 9.0 Final Text – 2012-08-31

202

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5310

of the id attributes of the Patient class SHALL have a matching root component. (see ITI TF-2x:
Appendix E on the use of the II data type for patient identifiers).
Other Identifiers

5315

5320

The OtherIDs class can optionally be used to capture other identifiers associated with the personsuch as driver’s license number or social security number). It is important to recognize that the
HL7 RIM distinguishes between person-level IDs and patient-level IDs. In this transaction,
however, the Patient Identity Cross-Reference Manager has the option to send all identifiers in
the id attributes of the Patient class. If that is the case, the OtherIDs class shall not be used. For
the purposes of interoperability where both HL7 V3 and HL7 v2.x based transactions are used,
and the OtherIDs class is present, the following requirement is imposed on the OtherIDs.id
attribute and on the scopingOrganization.id attribute:
OtherIDs.id.root SHALL be identical to scopingOrganization.id.root
scopingOrganization.id.extension SHALL NOT have any value
3.45.4.2.2.2 Message Information Model of the Patient Identifiers Message

5325

5330

Below is the Message Information Model for the Patient Identifiers message, as restricted for thistransaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Identifiers (PRPA_RM201304UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201304UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:• The focal entity choice is restricted to be only a person• All optional classes are removed, except for the provider organization, and other identifiers• All optional attributes in the Patient and Person class are removed

Rev. 9.0 Final Text – 2012-08-31

203

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5335

Figure 3.45.4.2.2-1: Message Information Model for the Patient Identifiers message

The attributes of this model are described in the following table.
Table 3.45.4.2.2-3: Model Attributes
PRPA_HD201304IHE
PatientIdentifiersThis HMD extract defines the message used torespond to the Patient Registry Query By Identifier
Derived from Figure 3.45.4.2.2-1(PRPA_RM201304IHE)

Patient

The primary record for the focal person in a Patient Identity CrossReference Manager

classCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Linked patient identifiers from one or more Patient Identity
Domains

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human beingclassCode [1..1] (M)Structural attribute; this is a "person" entity

Both Person.name and Patient.id must be non-null
Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Rev. 9.0 Final Text – 2012-08-31

Structural attribute; this is a specific person

204

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201304IHE
PatientIdentifiersThis HMD extract defines the message used torespond to the Patient Registry Query By Identifier
Derived from Figure 3.45.4.2.2-1(PRPA_RM201304IHE)

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role"

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)

3.45.4.2.2.3 Control Act and Transmission Wrappers
5340

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.45.4.4.2-5: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

MFMI_MT700711UV01 – Master File/Registry
Query Response Control Act (Role Subject)

The value of interactionId SHALL be set to
PRPA_IN201310UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN

The value of processingModeCode SHALL be set to T

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201310UV02

The acceptAckCode SHALL be set to NE

There SHALL be zero or one RegistrationEvents
present in this message.

There SHALL be only one receiver Device

If a RegistrationEvent is part of the message, there
SHALL be exactly one Patient role present in the
payload.
There SHALL be no replacementOf act-relationshippresent in this message
There SHALL be a QueryByParameter copy of theoriginal query.

5345

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemafrom the HL7 V3 2008 Normative Edition are at
Edition2008/processable/multicacheschemas/PRPA_IN201310UV02.xsd).
3.45.4.2.2.4 Web Services Types and Messages

5350

Since this is a response to a query, please see ITI TF-2b: 3.45.4.1.2.4 for the web services
components of this message.

Rev. 9.0 Final Text – 2012-08-31

205

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.45.4.2.3 Expected Actions - Patient Identifier Cross-reference Manager
The Patient Identifier Cross-reference Manager shall return the attributes within the message thatare required by the HL7 standard, as shown in Figure 3.45.4.2.2-1.
5355

5360

5365

5370

5375

5380

A RegistrationEvent, and the associated Patient class are returned only when the Patient
Identifier Cross-reference Manager recognizes the specified Patient ID in the query parameter,
and an identifier exists for the specified patient in at least one other domain. The Patient
Identifier Cross-reference Manager shall use at one or more Patient.id attributes (and, optionally,
zero or more OtherIDs.id attributes) to convey the patient IDs which uniquely identify the patient
within each Patient Identification Domain. The identifiers are captured using an Instance
Identifier (II) data type. See ITI TF-2x: Appendix E for a detailed description of the use of the IIdata type for patient identifiers.
It is wholly the responsibility of the Patient Identifier Cross-reference Manager to perform thematching of patient identifiers based on the patient identifier it receives. The information
provided by the Patient Identifier Cross-reference Manager to the Patient Identifier Crossreference Consumer is a list of cross-referenced identifiers in one or more of the domains
managed by the Patient Identifier Cross-reference Manager, in addition to the original identifier
used in the query. The identifier used in the query is returned only in the copy of theQueryByParameter parameter list. The list of cross-references is not made available until the setof policies and processes for managing the cross-reference function have been completed. The
policies of administering identities adopted by the cooperating domains are completely internal
to the Patient Identifier Cross-reference Manager and are outside of the scope of this framework.
Possible matches should not be communicated until the healthcare institution policies andprocesses embodied in the Patient Identifier Cross-reference Manager reach a positive matchingdecision.
The Patient Identifier Cross-reference Manager shall respond to the query request as describedby the following 6 cases:
Case 1: The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sentby the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, and corresponding
identifiers exist for the specified patient in at least one of the domains requested in
DataSource.value (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.)
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

5385

A single RegistrationEvent class is returned, where at least one of the identifiers, which thePatient Identifier Cross-reference Manager did recognize as belonging to a requested domain, isreturned in Patient.id. Subsequent such identifiers, if any, are returned in either Patient.id or
OtherIDs.id, not including the queried-for patient identifier that is returned in theQueryByParameter parameter list (control act wrapper).

5390

Case 2: The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sentby the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, there are noRev. 9.0 Final Text – 2012-08-31

206

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
specific domains requested in the query (no DataSource parameters are present), andcorresponding identifiers exist for the specified patient in at least one other domain known to thePatient Identifier Cross-reference Manager (one identifier per domain).
5395

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

5400

5405

A single RegistrationEvent class is returned, where at least one of the identifiers, which thePatient Identifier Cross-reference Manager did recognize as belonging to a domain different fromthe domain of the queried-for patient identifier, is returned in Patient.id. Subsequent such
identifiers, if any, are returned in either Patient.id or OtherIDs.id, not including the queried-for
patient identifier, which is returned in the QueryByParameter parameter list (control act
wrapper).
Case 3: The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sent
in PatientIdentifier.value, but no identifier exists for that patient in any of the domains sent in
DataSource.value.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
NF (no data found, no errors) is returned in QueryAck.queryResponseCode (control act
wrapper).
No RegistrationEvent is returned.

5410

The queried-for patient identifier is returned in the QueryByParameter parameter list (control act
wrapper).
Case 4: The Patient Identifier Cross-reference Manager does not recognize the Patient ID sent in
the PatientIdentifier.value.

5415

AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
No RegistrationEvent is returned.
The queried-for patient identifier is returned in the QueryByParameter parameter list (control act
wrapper).

5420

An AcknowledgmentDetail class is returned in which the attributes typeCode, code, and location
are valued as follows.
Attribute

VALUE

typeCodeEcode

204 (Unknown Key Identifier)location

XPath expression for the value element of the PatientIdentifier parameter

Case 5: The Patient Identifier Cross-reference Manager does not recognize one or more of thePatient Identification Domains for which an identifier has been requested.
5425

AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
Rev. 9.0 Final Text – 2012-08-31

207

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________No RegistrationEvent is returned.
The queried-for patient identification domains are returned in the QueryByParameter parameter
list (control act wrapper).
5430

For each domain that was not recognized, an AcknowledgmentDetail class is returned in which
the attributes typeCode, code, and location are valued as follows:
Attribute

5435

VALUE

typeCodeE

Code

204 (Unknown Key Identifier)Location

XPath expression for the value element of the DataSource parameter(which includes the repetition number of the parameter)

Case 6: The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sentby the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, and corresponding
identifiers exist for the specified patient in at least one of the domains requested in
DataSource.value, and there are multiple identifiers within at least one of the requested domains.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

5440

5445

A single RegistrationEvent class is returned, where at least one of the identifiers, which thePatient Identifier Cross-reference Manager did recognize as belonging to a requested domain, isreturned in Patient.id. Subsequent such identifiers, if any, are returned in either Patient.id or
OtherIDs.id, not including the queried-for patient identifier that is returned in theQueryByParameter parameter list (control act wrapper).
If the Patient Identifier Cross-reference Manager chooses to return multiple identifiers
associated with the same domain, it shall return these identifiers either grouped in a single
instance of the OtherIDs class, or all represented via repetitions of the Patient.id attribute.
3.45.4.2.3.1 Web Services Port Type and Binding Definitions
The WSDL snippets for this message are shown in ITI TF-2b: 3.45.4.1.3.1
3.45.4.2.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.

5450

3.45.4.2.4 Expected Actions - Patient Identifier Cross-reference Consumer

5455

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. The identifiers found in both Patient.id and OtherIDs.id attributes shall beconsidered together to form a complete list of patient identifiers from the different Patient
Identity domains (either requested or available).

Rev. 9.0 Final Text – 2012-08-31

208

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________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.
5460

5465

This allows Patient Identifier Cross-reference Consumers 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 Consumers not capable of handling this situation, ignoring the entire list of different
identifiers prevents the consumer from presenting incomplete data.
3.45.5 Security Requirements
No transaction specific security considerations.
3.45.5.1 Audit Record Considerations
When grouped with ATNA Secure Node or Secure Application actors, this transaction is to beaudited as “Query Information” event, as defined in ITI TF-2a: Table 3.20.6-1. The following
tables show items that are required to be part of the audit record for this transaction.

5470

3.45.5.1.1 Patient Identifier Cross-reference Consumer audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

Source (Patient Identifier Cross-reference Consumer) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager) (1)Audit Source (Patient Identity Cross-reference Consumer) (1)Patient (0..n)Query Parameters(1)Where:

Rev. 9.0 Final Text – 2012-08-31

209

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Patient(AuditMessage/
ParticipantObjectIdentifi
cation)Query

Rev. 9.0 Final Text – 2012-08-31

210

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ParticipantObjectTypeCodeRole

5475

M

“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDU

not specialized

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

3.45.5.1.2 Patient Identifier Cross-reference Manager audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

Source (Patient Identifier Cross-reference Manager) (1)Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Manager) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Rev. 9.0 Final Text – 2012-08-31

211

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Patient(AuditMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized“2” (system object)

The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDU

not specialized

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYMParticipantObjectDetailU

the QueryByParameter segment of the query, base64 encoded
not specialized

5480

3.46 PIXV3 Update Notification
This section corresponds to Transaction ITI-46 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-46 is used by the Patient Identifier Cross-reference Consumer andPatient Identifier Cross-reference Manager actors.
5485

3.46.1 Scope
The scope is identical to the scope of transaction ITI-10, described in section ITI TF-2a: 3.10.1.
3.46.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIXV3 Update
Notification

Actor: Patient Identifier Cross-reference Manager
5490

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 PatientRev. 9.0 Final Text – 2012-08-31

212

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Identification Domains by providing a list of patient ID “aliases” via notification to a configured
list of interested Patient Identifier Cross-reference Consumers.
Corresponding HL7 v3 Application Roles:
5495

Patient Registry Informer (PRPA_AR201301UV02)
Actor: Patient Identifier Cross-reference Consumer
Role: Receives notifications from the Patient Identifier Cross-reference Manager of changes topatient ID aliases. Typically the Patient Identifier Cross-reference Consumer uses thisinformation to maintain information links about patients in a different patient ID domain.

5500

Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)
3.46.3 Referenced Standards
HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008)

5505

Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.
3.46.4 Interaction Diagrams

Patient Identifier
Cross-Reference
Consumer

Patient Identifier
Cross-ReferenceManager

Patient Registry Record Revised
PRPA_IN201302UV02

3.46-1: Update Patient Information Sequence5510

3.46.4.1 Update Patient Information
3.46.4.1.1 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

Rev. 9.0 Final Text – 2012-08-31

213

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
5515

5520

configuration of the domains of interest to a Patient Cross-reference Consumer is maintained by
the Patient Cross-reference Manager.
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:
Patient Registry Record Revised (PRPA_TE201302UV02)
This trigger event signals that patient information was revised in a patient registry.
3.46.4.1.2 Message Semantics

5525

The PIX Update Notification transaction is conducted by the Patient Revise(PRPA_MT201302UV02) message. The Patient Identifier Cross-reference Manager initiates thistransaction whenever identifier list information is updated for a patient.
Each message shall be acknowledged by the HL7 V3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.

5530

5535

5540

5545

5550

It is wholly the responsibility of the Patient Identifier Cross-reference Manager to perform thematching of patient identifiers based on the patient traits it receives. The information provided by
the Patient Identifier Cross-reference Manager to Patient Identifier Cross-reference Consumer
Actors shall only contain a list of cross-referenced identifiers for the domains of interest as
configured with the Patient Identifier Cross-reference Manager in two or more of the domains
managed by the Patient Identifier Cross-reference Manager. Multiple notifications may need to
be sent. For example:
Consumer CON_A is configured to receive update notifications for domains DOM_A and
DOM_AD. Notifications are sent as follows:
A PIXV3 Patient Registry Record Add message is sent for a patient for DOM_A. The
update notification shall contain the patient identifier for DOM_A.
A PIXV3 Patient Registry Record Add message is processed for DOM_AD. The Patient
Identifier Cross-reference Manager cross references this patient with DOM_A. The
update notification shall contain the patient identifiers for both DOM_A and
DOM_AD.
A PIXV3 Patient Registry Record Revise message is processed for DOM_AD changing
the patient address. The Patient Identifier Cross-reference Manager cross references
determines this patient is no longer the same patient as DOM_A. Two update
notifications shall be sent. One containing the patient identifier for DOM_A. The
other one containing the patient identifier for DOM_AD.
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 completely internal to the Patient Identifier
Cross-reference Manager and are outside of the scope of this transaction. Possible matches

Rev. 9.0 Final Text – 2012-08-31

214

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5555

5560

should not be communicated until the healthcare institution policies and processes embodied in
the Patient Identifier Cross-reference Manager reach a positive matching decision.
The Patient Identifier Cross-reference Manager shall have configuration indicating which
Identity Consumers are interested in receiving the PIXV3 Update Notification Transactions. Thisconfiguration information shall include identification of the identity consumer systems interested
in receiving notifications and, for each of those systems, a list of the patient identifier domains ofinterest. The Patient Identifier Cross-reference Manager should account for consumers interested
in all domains.
Each message shall be acknowledged by the Accept Acknowledgment message sent by thereceiver of the Patient Registry Record Revise message to its sender.
3.46.4.1.2.1 Major Components of the Patient Registry Record Revised

5565

Patient
The Patient class is the entry point to the R-MIM for the Patient Revise(PRPA_RM201302UV02). This is where the updated list of patient identifiers will be present.
PersonThe Person class contains the name of the patient for additional verification purposes.

5570

5575

Provider Organization
The Patient class is optionally scoped by the provider organization where this person is a patient.
The HL7 definition of the CMET requires that the provider organization needs to be identified
by an id attribute, and at least one of address, telecommunications address, or contact person to
be present. The id attribute SHALL have only a root, expressed as an ISO OID, and at least oneof the id attributes of the Patient class SHALL have a matching root component (see ITI TF-2x:
Appendix E on the use of the II data type for patient identifiers).
Other Identifiers

5580

5585

The OtherIDs class can be optionally used to capture other identifiers associated with the personsuch as driver’s license number or social security number). It is important to recognize that the
HL7 RIM distinguishes between person-level IDs and patient-level IDs. In this transaction,
however, the Patient Identity Cross-Reference Manager has the option to send all identifiers in
the id attributes of the Patient class. If that is the case, the OtherIDs class shall not be used. For
the purposes of interoperability where both HL7 V3 and HL7 v2.x based transactions are used,
and the OtherIDs class is present, the following requirement is imposed on the OtherIDs.id
attribute and on the scopingOrganization.id attribute:
OtherIDs.id.root SHALL be identical to scopingOrganization.id.root
scopingOrganization.id.extension SHALL NOT have any value

Rev. 9.0 Final Text – 2012-08-31

215

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.46.4.1.2.2 Message Information Model of the Patient Registry Record Revise
Message
5590

5595

5600

Below is the Message Information Model for the Patient Identifiers message, as restricted for thistransaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Revise (PRPA_RM201302UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model (note that the resulting model is
identical to the one described in ITI TF-2b: 3.45.4.2.2.2):
The focal entity choice is restricted to be only a person
All optional classes are removed, except for the provider organization, and otheridentifiers
All optional attributes in the Patient and Person class are removed

Figure 3.46.4.1.2-1: Message Information Model for the Patient Identifiers message

5605

The attributes of this model are described in the following table.

Rev. 9.0 Final Text – 2012-08-31

216

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.46.4.1.2-4: Model Attributes
PRPA_HD201302IHE
PatientRevise

This HMD extract defines the message used tosend a Patient Update Notification
Derived from Figure 3.46.4.1.2-1(PRPA_RM201302IHE)

Patient

The primary record for the focal person in a Patient Identity CrossReference Manager

classCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Linked identifiers from one or more Identity Domains

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human being
Both Person.name and Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role"

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)

3.46.4.1.2.3 Control Act and Transmission Wrappers
5610

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.46.4.1.2-2 contains the Transmission and Control Act wrappers used for thetwo interactions, and the associated constraints.
Table 3.46.4.1.2-6: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201302UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201302UV02

The value of processingModeCode SHALL be set to T

RegistrationEvent.statusCode SHALL be set to“active”

The acceptAckCode SHALL be set to AL

There SHALL be no InReplacementOf act
relationship for these interactions.

There SHALL be only one receiver Device

Rev. 9.0 Final Text – 2012-08-31

217

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5615

The composite message schemas which describe the full payload of these interactions, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemafrom the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201302UV02.xsd)
3.46.4.1.2.4 Web Services Types and Messages
The Patient Registry Record Revised message will be transmitted using Web Services, according
to the requirements specified in ITI TF-2x: Appendix V.

5620

The following WSDL naming conventions SHALL apply:“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:
5625

5630

5635

5640

5645

5650

5655

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201302UV02.xsd"/><xsd:element name="PRPA_IN201302UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…

The messages are described by the following snippet:…
<message name="PRPA_IN201302UV02_Message"><part element="hl7:PRPA_IN201302UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Identity Feed Service are described together
with the expected actions of the actors which receive these messages in section ITI TF-2b:
3.46.4.1.3.
3.46.4.1.3 Expected Actions - Patient Identifier Cross-reference Consumer
Whenever the Patient Identifier Cross-reference Consumer receives updated identifier
information in a Patient Revise message that results in a change to the cross-referencing of aRev. 9.0 Final Text – 2012-08-31

218

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5660

patient, the actor shall update its internal identifier information for the affected patient(s) in all
domains in which it is interested. The identifiers found in both Patient.id and OtherIDs.id
attributes shall be considered together to form a complete list of patient identifiers from thedifferent Patient Identity domains in which this actor is interested.

5665

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.

5670

This allows Patient Identifier Cross-reference Consumers 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 Consumers not capable of handling this situation, ignoring the entire list of different
identifiers prevents the consumer from presenting incomplete data.
3.46.4.1.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXConsumer”.
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXConsumer":PIX update message-> "PRPA_IN201302UV02_Message"
acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "PIXConsumer_PortType"get identifiers operation -> "PIXConsumer_PRPA_IN201302UV02"
SOAP 1.2 binding-> "PIXConsumer_Binding_Soap12"
SOAP 1.2 port-> "PIXConsumer_Port_Soap12"

5675

5680

The following WSDL snippets specify the Patient Update Port Type and Binding definitions,according to the requirements specified in ITI TF-2x: Appendix V.
5685

5690

3.46.4.1.3.1.1 Port Type<portType name="PIXConsumer_PortType"><operation name="PIXConsumer_PRPA_IN201302UV02"><input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201302UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.46.4.1.3.1.2 Bindings
5695

5700

SOAP 1.2 binding:…

<binding name="PIXConsumer_Binding_Soap12" type="PIXConsumer_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXConsumer_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/>

Rev. 9.0 Final Text – 2012-08-31

219

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5705

5710

…

<input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Consumer implementing the PIXV3 profile is available
online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.46.4.1.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
5715

5720

3.46.5 Security Requirements
No transaction specific security considerations.
3.46.5.1 Audit Record Considerations
When grouped with ATNA Secure Node or Secure Application actors, this transaction is to beaudited as “Patient Record” event, as defined in ITI TF-2a: Table 3.20.6-1. The following tables
show items that are required to be part of the audit record for this transaction.
3.46.5.1.1 Patient Identifier Cross-reference Manager audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)

Source (Patient Identifier Cross-reference Manager) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Manager) (1)Patient IDs(1..n) (represents the components of PID-3)
Where:

Rev. 9.0 Final Text – 2012-08-31

220

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

the patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

5725
Destination
AuditMessage/
ActiveParticipant

Patient IDs(AuditMessage/
ParticipantObjectIdentifi
cation)3.46.5.1.2 Patient Identifier Cross-reference Consumer audit message:
Event

Field Name

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

Rev. 9.0 Final Text – 2012-08-31

221

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
EventActionCodeM“U” (update)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)

Source (Patient Identifier Cross-reference Manager) (1)Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Consumer) (1)Patient IDs(1..n) (represents the components of PID-3)

Where:
SourceAuditMessage/
ActiveParticipant

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI.

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized“1” (Person)

5730
Destination
AuditMessage/
ActiveParticipant

Patient IDs(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

the patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

Rev. 9.0 Final Text – 2012-08-31

222

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.47 Patient Demographics Query HL7 V35735

This section corresponds to Transaction ITI-47 of the IHE Technical Framework. Transaction
ITI-47 is used by the Patient Demographics Consumer and Patient Demographics Supplieractors. Additional components to be included if the Pediatric Demographics option is supported
are also indicated in ITI TF-2b: 3.47.4.1.2.1 to 3.47.4.1.2.4.
3.47.1 Scope

5740

The scope is identical to ITI TF-2a: 3.21.1.
3.47.2 Use Case Roles
Patient
Demographics
Supplier

Patient
Demographics
Consumer

Patient
Demographics
Query HL7 V3

Actor: Patient Demographics Consumer5745

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.
Corresponding HL7 v3 Application Roles:
Person Registry Query Placer (PRPA_AR201303UV02)
Actor: Patient Demographics Supplier5750

Role: Returns demographic information for all patients matching the demographic criteria
provided by the Patient Demographics Consumer.
Corresponding HL7 v3 Application Roles:
Person Registry Query Fulfiller (PRPA_AR201304UV02)
3.47.3 Referenced Standards

5755

HL7 Version 3 Edition 2008, Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008)
Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.

Rev. 9.0 Final Text – 2012-08-31

223

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
5760

3.47.4 Interaction Diagrams
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient Registry Find Candidates Query
PRPA_IN201305UV02
Patient Registry Find Candidates Query Response
PRPA_IN201306UV02
General Query Activate Query Continue
QUQI_IN000003UV01
Patient Registry Find Candidates Query Response
PRPA_IN201306UV02
Figure 3.46.4-1: Find Candidates Query

3.47.4.1 Patient Demographics Query
3.47.4.1.1 Trigger Events
5765

A Patient Demographics Consumer’s need to select a patient based on demographic information
about patients whose information matches a set of known data will trigger the Patient
Demographics Query based on the following HL7 trigger event:Find Candidates Query (PRPA_TE201305UV02)

5770

An application, in the role of Query Placer, sends a query-by-parameter message to request thatthe application return all person records that match the demographic information sent in thequery parameters.
3.47.4.1.2 Message Semantics

5775

The Find Candidates Query is supported by the Patient Registry Query by Demographics(PRPA_MT201306UV02) message. The Patient Demographics Consumer shall generate thequery message whenever it needs to select from a list of patients whose information matches a
set of demographic data.

Rev. 9.0 Final Text – 2012-08-31

224

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5780

5785

The components of the Patient Registry Query by Demographics message with cardinality
greater than 0 (as shown below) are required, and the detailed description of the message isprovided in ITI TF-2b: 3.47.4.1.2.1 to 3.47.4.1.2.4. Additional components to be included if thePediatric Demographics option is supported are also indicated in ITI TF-2b: 3.47.4.1.2.1 to3.47.4.1.2.4.
The receiver shall respond to the query by sending the Patient Registry Find Candidates
Response message (PRPA_MT201310UV02), which uses the Application Level
Acknowledgement transmission wrapper. This satisfies the requirements of original mode
acknowledgment; no intermediate Accept Acknowledgement is to be sent. The response message
shall contain demographic records that reflect the best fit to all of the search criteria received in
the Patient Registry Query by Demographics message.
3.47.4.1.2.1 Major Components of the Patient Registry Query by Demographics
LivingSubjectName Parameter

5790

5795

5800

This optional parameter specifies the name of the person whose information is being queried.
For this parameter item, a single person name (PN) data item shall be specified in the
LivingSubjectName.value attribute. Only certain name parts within the PN data type (e.g., familyname) may be specified. If the sender needs to indicate that the name parts specified are notlimited to an exact match, then the use attribute of the value element shall be set to "SRCH".
Handling of phonetic issues, alternate spellings, upper and lower case, partial matching, 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, however, the MatchAlgorithm parameter may be used to indicate more specificrequirements for the Supplier, based on an existing agreement on allowable values for
MatchAlgorithm.value.
LivingSubjectAdministrativeGender Parameter

5805

This optional parameter specifies the administrative gender of the person whose information is
being queried. For this parameter item, a single administrative gender code shall be specified in
the LivingSubjectAdministrativeGender.value attribute.
LivingSubjectBirthTime Parameter

5810

This optional parameter specifies the birth data and time of the person whose information is
being queried. This parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00
EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959
through March 31, 1960).
PatientAddress Parameter
This optional parameter specifies one or more addresses associated with the person whose
information is being queried.

5815

Rev. 9.0 Final Text – 2012-08-31

225

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
LivingSubjectId Parameter

5820

This optional repeating parameter specifies an identifier associated with the patient whose
information is being queried (e.g., a local identifier, or an account identifier). If multiple
instances of this parameter are provided in the query, all of the associated identifiers must match.
The identifier specified in the LivingSubjectId.value attribute is expressed using the II data type.
Please see Appendix E for the use of the II data type for patient identifiers.
OtherIDsScopingOrganization Parameter

5825

5830

This optional repeating parameter specifies the assigning authority/authorities of the Patient
Identity Domain(s) for which identifiers are to be returned. The identifier specified in the
OtherIDsScopingOrganization.value attribute shall be expressed using the II data type, where theroot element contains a valid ISO OID, and there is no extension element. If no such parameter is
supplied, the patient demographics supplier is required to return the identifiers from all Patient
Identity Domains known to it. Any parameter value which is not recognized by the target patient
information source shall cause an error condition.
Additional components to be included if the Pediatric Demographics option is supported are also
indicated below:
MothersMaidenName Parameter

5835

This optional parameter specifies the maiden name of the mother of the person whose
information is being queried. For this parameter item, a single person name (PN) data item shallbe specified in the Person.value attribute. Within the PN data type, the given name and familyname may be specified. If the sender needs to indicate that the name parts specified are notlimited to an exact match, then the use attribute of the value element shall be set to "SRCH".
PatientTelecom Parameter

5840

This optional parameter specifies the primary telephone number or email address of the person
whose information is being queried.
Additional components to be included if the Pediatric Demographics option is supported are also
indicated below:
MothersMaidenName Parameter

5845

This optional parameter specifies the maiden name of the mother of the person whose
information is being queried. For this parameter item, a single person name (PN) data item shallbe specified in the Person.value attribute. Within the PN data type, the given name and familyname may be specified. If the sender needs to indicate that the name parts specified are notlimited to an exact match, then the use attribute of the value element shall be set to "SRCH".
PatientTelecom Parameter

5850

This optional parameter specifies the primary telephone number or email address of the person
whose information is being queried.

Rev. 9.0 Final Text – 2012-08-31

226

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.1.2.2 Message Information Model of the Patient Registry Query by
Demographics Message
5855

Below is the Message Information Model for the Query by Demographics message, as restricted
for this transaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Registry Query by Demographics(PRPA_RM201306UV02) RMIM. If the Pediatric Demographics option is supported, there aresomewhat fewer constraints on the RMIM; these are also indicated.

5860

The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201306UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:• Exactly one value attribute shall be present in each parameter• Only the LivingSubjectId, OtherIDsScopingOrganization, and LivingSubjectName
parameters can have more than one instance• The optional attributes ParameterList.id, MatchCriterionList.id, QueryByParameter
responseElementGroupId, QueryByParameter.modifyCode, andQueryByParameter.executionAndDeliveryTime were omitted from the model• QueryByParameter.responsePriorityCode is required and is fixed to I (Immediate)• QueryByParameter.responseModalityCode is required and is fixed to R (Real Time)• QueryByParameter.statusCode is defaulted to "new".
• The data type of MatchAlgorithm.value is constrained to ST• The data type of MinimumDegreeMatch.value is constrained to INT• The data type of LivingSubjectName.value is constrained to PN• The optional SortControl was omitted from the model• The optional MatchWeight was omitted from the model• The following optional parameters were omitted from the model:• PatientTelecom (not omitted if Pediatric Demographics option is supported)• PrincipalCareProviderId• PrinicpalCareProvisionId• MothersMaidenName (not omitted if Pediatric Demographics option is supported)• LivingSubjectDeceasedTime• PatientStatusCode• LivingSubjectBirthPlaceName• LivingSubjectBirthPlaceAddress

5865

5870

5875

5880

5885

Rev. 9.0 Final Text – 2012-08-31

227

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

Figure 3.47.4.1.2-1: Message Information Model for the Query by Demographics message

The attributes of this model are described in the following table:
5890
Table 3.47.4.1.2-1: Model Attributes
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)

QueryByParameter

The entry point for the domain content in this query

queryId [1..1]
QueryByParameter (II)Unique identifier for the query

statusCode [1..1] (M)QueryByParameter (CS) {CNE:QueryStatusCode,default="new"}

The status of the query, default is "new"responseModalityCode [1..1]
QueryByParameter (CS) {CNE:ResponseModality,
fixed value="R"}

The mode of the response – always real-time.

responsePriorityCode [1..1]
QueryByParameter (CS) {CNE:QueryPriority, fixedvalue="I"}

The Patient Demographics Supplier is required to send an
immediate response.

initialQuantity [0..1]
QueryByParameter (INT)

Defines the maximum size of the response that can be
accepted by the requesting application

initialQuantityCode [0..1]
QueryByParameter (CE){CWE:QueryRequestLimit, default="RD"}Defines the units associated with the initialQuantity; default is"records".

Rev. 9.0 Final Text – 2012-08-31

228

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)

MatchAlgorithm

This parameter conveys instructions to the patient demographics
supplier specifying the preferred matching algorithm to use

value [1..1]
ParameterItem (ST)The name of the algorithm

semanticsText [1..1]
ParameterItem (ST){default= "MatchAlgorithm"}
MinimumDegreeMatch

This parameter conveys instructions to the patient demographics
supplier specifying minimum degree of match to use in filteringresultsvalue [1..1]
ParameterItem (INT)The numeric value of the degree of match

semanticsText [1..1]
ParameterItem (ST){default= "MatchAlgorithm"}
This query parameter is a code representing the administrative
gender of a person in a patient registry.

LivingSubjectAdministrativeGender
value [1..1]
ParameterItem (CE) {CWE:AdministrativeGender}
semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.administrativeGender"}LivingSubjectBirthTime

This query parameter is the birth date of a living subject.

value [1..1]
ParameterItem (IVL<TS>)

A date or date range. This parameter can convey an exact moment(e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g.,January 1960), or even a range of dates (e.g., December 1, 1959
through March 31, 1960).

semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.birthTime"}
LivingSubjectId
value [1..1] (M)ParameterItem (II)A patient identifier, used to assist in finding a match for the query.

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.id"}
LivingSubjectName

This query parameter is the name of a person. If multiple instancesof LivingSubjectName are provided, the receiver must consider
them as possible alternatives, logically connected with an "or".

value [1..1]
ParameterItem (PN)

The name "use" attribute can convey that a name is to be matchedusing "fuzzy" matching, and does not require exact match. Onlysome of the name parts may be populated. If, for example, only afamily name part of a person's name is sent, then the query would
match all persons with that family name regardless of their given
names or initials.

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.name"}
This query parameter is a postal address for corresponding with a

PatientAddress

Rev. 9.0 Final Text – 2012-08-31

229

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)
patient

value [1..1]
ParameterItem (AD)semanticsText [1..1]
ParameterItem (ST){default= "Patient.addr"}
OtherIDsScopingOrganization

Optional parameter specifying the assigning authority of a Patient
Identity Domain

value [1..1]
ParameterItem (II)The identifier for a Patient Identity Domain's assigning authority.
IHE restriction:
The value.root attribute SHALL be a valid ISO OID
The value.extension attribute SHALL NOT be present

semanticsText [1..1]
ParameterItem (ST){default="OtherIDs.scopingOrganization.id"}

When Patient Demographics option is supported, the following sections may be included.
MothersMaidenName

Design Comments: This query parameter is the maiden name of a
focal person's mother. It is included as a parameter because it is acommon attribute for confirming the identity of persons in someregistries. This parameter does not map to a single RIM attribute,instead, in RIM terms Mother's maiden name is the person namepart of "family" with an EntityNamePartQualifier of "birth" for the
person who is the player in a PersonalRelationship of type of"mother" to the focal person.

value [1..1]

Design Comments: A person name. In this case it may consist of
only the given name part, the family name part, or both.

ParameterItem (PN)
semanticsText [1..1]
ParameterItem (ST){default="Person.MothersMaidenName"}
PatientTelecom

Design Comments: This query parameter is a telecommunications
address for communicating with a living subject in the context ofthe target patient registry. It could be a telephone number, fax
number or even an email address.

value [1..1]

Design Comments: A telecommunications address. The scheme
attribute specifies whether this is a telephone number, fax number,email address, etc.

ParameterItem (TEL)

3.47.4.1.2.3 Control Act and Transmission Wrappers
5895

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.

Rev. 9.0 Final Text – 2012-08-31

230

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.47.4.1.2-7: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

QUQI_MT021001UV01 – Query Control Act
Request: Query By Parameter

The value of interactionId SHALL be set to
PRPA_IN201305UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN

The value of processingModeCode SHALL be set to T

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201305UV02

The acceptAckCode SHALL be set to AL

If an authorOrPerformer participation is present, thevalue of authorOrPerformer.typeCode SHALL be set
to AUT

There SHALL be only one receiver Device

5900

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201305UV02.xsd)
3.47.4.1.2.4 Web Services Types and Messages

5905

The Patient Registry Query by Demographics message will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.
The following WSDL naming conventions SHALL apply:
query message

5910

5915

5920

-> "PRPA_IN201305UV02_Message"

The following WSDL snippet describes the type for this message:…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201305UV02.xsd"/><xsd:element name="PRPA_IN201305UV02"/></xsd:schema></types>…

The message is described by the following snippet:

5925

5930

…
<message name="PRPA_IN201305UV02_Message"><part element="hl7:PRPA_IN201305UV02" name="Body"/></message>…

The port types for the WSDL describing the Patient Demographics Service are described
together with the expected actions of the actors which receive these messages in section ITI TF2b: 3.47.4.2.3.

Rev. 9.0 Final Text – 2012-08-31

231

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.1.3 Expected Actions
3.47.4.1.3.1 Immediate Response

5935

The Patient Demographics Supplier shall immediately return a Find Candidates Response
message as specified below in ITI TF-2b: 3.47.4.2. The response message uses the Application
Acknowledgement transmission wrapper, as specified in ITI TF-2x: Appendix O.1.3, and noother acknowledgments are part of this transaction.
3.47.4.1.3.2 Query Parameter Processing
The Patient Demographics Supplier shall be capable of accepting, searching on, and responding
with attributes in the Query Person by Demographics message.

5940

Handling of phonetic issues, alternate spellings, upper and lower case, partial matching, 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, except as already discussed in the LivingSubjectName parameter description.

5945

3.47.4.1.3.3 Incremental Response Processing
The Patient Demographics Supplier, which supports the Continuation Option, shall be capable ofaccepting and processing the QueryByParameter.responsePriorityCode attribute. In particular,
the Patient Demographics Supplier shall respond in immediate mode.

5950

Also, the Patient Demographics Supplier shall be able to interpret
QueryByParameter.initialQuantity to return successive responses of partial lists of records.
When processing incremental responses, the Patient Demographics Consumer shall request
additional responses using the Query Control Act Request Continue/Cancel message(QUQI_MT000001UV01), as described in ITI TF-2b: 3.47.4.3.
3.47.4.1.3.4 Web Services Port Type and Binding Definitions

5955

These definitions are part of the query response message. Please see ITI TF-2b: 3.47.4.2.3 formore information.
3.47.4.1.3.5 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.47.4.2 Patient Demographics Query Response

5960

3.47.4.2.1 Trigger Events
The Patient Demographics Supplier’s response to the Find Candidates Query message istriggered by the following trigger:
Find Candidates Response (PRPA_TE201306UV02)

Rev. 9.0 Final Text – 2012-08-31

232

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

5965

An application returns a Patient Registry Find Candidates Response message populated withinformation it holds for each person whose record matches the demographic information sent asparameters in a query-by-parameter message.
3.47.4.2.2 Message Semantics

5970

5975

The Patient Registry Find Candidates Response message (PRPA_MT201310UV02) is sent by
the Patient Demographics Supplier in direct response to the query (PRPA_MT201306UV02) or,
if the Continuation Option is supported, the query continuation (QUQI_MT000001UV01)
message previously received. The components of the message with cardinality greater than 0 (asshown below) are required, and the detailed description of the message is provided in ITI TF-2b:
3.47.4.2.2.1 to 3.47.4.2.2.4. All other attributes of the message are optional.
3.47.4.2.2.1 Major Components of the Patient Registry Find Candidates Response
Message
This message shares all the major components of the Patient Activate/Revise messages, as
described in ITI TF-2b: 3.44.4.1.2.1. The only additional component is theQueryMatchObservation class.
Query Match Observation

5980

The QueryMatchObservation class is used to convey information about the quality of the matchfor each record returned by the query response.
3.47.4.2.2.2 Message Information Model of the Patient Registry Find Candidates
Response Message

5985

5990

5995

6000

Below is the Message Information Model for the Patient Registry Find Candidates Response
message, as restricted for this transaction. The purpose of the model is to describe the data
elements relevant for this transaction. It is a strict common subset of the Patient Registry Find
Candidates Response (PRPA_RM201310UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201310UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:• The focal entity choice is restricted to be only a person• The relationship holder of the personal relationship is restricted to be a person (using CMET
COCT_MT030207UV)• The following roles are omitted:• asPatientOfOtherProvider• birthPlace• guarantor• guardian• contactParty• asMember
Rev. 9.0 Final Text – 2012-08-31

233

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________•
6005• careGiver• asStudent
The following participations are omitted:• subjectOf (administrativeObservation)• coveredPartyOf (coverage)

Figure 3.47.4.2.2-1: Message Information Model for the Patient Registry Find Candidates
Response message

6010

The attributes of this model are described in the following table. Note that CMETs are notdiscussed, as the HL7 definitions for them are being used.

Rev. 9.0 Final Text – 2012-08-31

234

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.47.4.2.2-8: Model Attributes
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

Patient

The primary record for the focal person in a Patient Demographics
SupplierclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Patient identifiers. Patient Identifiers from different Identity
Domains may be contained either here, or in the OtherIDs.id
attributes, but not in both places. At least one Patient Identifier shallbe present in this attribute

Patient (SET<II>)statusCode [1..1]

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

Patient (CS) {CNE:active, fixed value= "active"}
confidentialityCode [0..*]

Value(s) that control the disclosure of information about this living
subject as a patient

Patient (SET<CE>) {CWE:Confidentiality}
veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status granted by the scoperorganization, often resulting in preferred treatment and special
considerations. Examples include board member, diplomat.

PersonA subtype of LivingSubject representing a human being
Either Person.name or Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
telecom [0..*]

Telecommunication address(es) for communicating with this person

Person (BAG<TEL>)
administrativeGenderCode [0..1]

A value representing the gender (sex) of this person. Note: this
attribute does not include terms related to clinical gender which is acomplex physiological, genetic and sociological concept that
requires multiple observations in order to be comprehensively
described.

Person (CE) {CWE:AdministrativeGender}

birthTime [0..1]

The date and time this person was born

Person (TS)deceasedInd [0..1]

An indication that this person is dead

Person (BL)deceasedTime [0..1]

The date and time this person died

Person (TS)multipleBirthInd [0..1]

An indication that this person was part of a multiple birth

Person (BL)multipleBirthOrderNumber [0..1]

Rev. 9.0 Final Text – 2012-08-31

The order in which this person was born if part of a multiple birth235

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

Person (INT)
addr [0..*]Address(es) for corresponding with this person

Person (BAG<AD>)maritalStatusCode [0..1]

A value representing the domestic partnership status of this person

Person (CE) {CWE:MaritalStatus}
religiousAffiliationCode [0..1]

A value representing the primary religious preference of this person

Person (CE) {CWE:ReligiousAffiliation}
raceCode [0..*]A set of values representing the races of this person

Person (SET<CE>) {CWE:Race}ethnicGroupCode [0..*]A set of values representing the ethnic groups of this person

Person (SET<CE>) {CWE:Ethnicity}
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role" except
for Citizen, or Employee.,

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., identifiers from a different Patient
Identity Domain).

Role (SET<II>)
PersonalRelationship

A personal relationship between the focal living subject and anotherliving subject

classCode [1..1] (M)Structural attribute; this is a "personal relationship" role

Role (CS) {CNE:PRS, fixed value= "PRS"}
id [0..*]

Identifier(s) for this personal relationshipRole (SET<II>)code [1..1] (M)Role (CE) {CWE:PersonalRelationshipRoleType}A required value specifying the type of personal relationshipbetween the relationshipHolder and the scoping living subject
drawn from the PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

CitizenUsed to capture person information relating to citizenship.

classCode [1..1] (M)Structural attribute; this is a "citizen" role

Role (CS) {CNE:CIT, fixed value= "CIT"}
id [0..*]

Identifier(s) for the focal person as a citizen of a nationRole (SET<II>)
NationA politically organized body of people bonded by territory andknown as a nation.

classCode [1..1] (M)Structural attribute; this is a 'nation' type of entity

Organization (CS) {CNE:NAT, fixed value= "NAT"}
determinerCode [1..1] (M)Structural attribute; this is a specific entity

Organization (CS) {CNE:INSTANCE, fixed value="INSTANCE"}

Rev. 9.0 Final Text – 2012-08-31

236

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

code [1..1] (M)A value that identifies a nation state

Organization (CD) {CWE:NationEntityType}name [0..1]

A non-unique textual identifier or moniker for this nation

Organization (ON)
Employee

A relationship of the focal person with an organization to receive
wages or salary. The purpose of this class is to identify the type of
relationship the employee has to the employer rather than the natureof the work actually performed. For example, it can be used tocapture whether the person is a Military Veteran or not..

classCode [1..1] (M)Structural attribute; this is an "employee" role

Employee (CS) {CNE:EMP}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
occupationCode [0..1]

A code qualifying the classification of kind-of-work based upon arecognized industry or jurisdictional standard. OccupationCode isused to convey the person's occupation as opposed to jobClassCode(not used in this transaction) which characterizes this particular job.
For example, it can be used to capture whether the person is a
Military Veteran or not.

Employee (CE) {CWE:EmployeeOccupationCode}

LanguageCommunication

A language communication capability of the focal person

languageCode [1..1] (M)A value representing a language for which the focal person has
some level of proficiency for written or spoken communication.
Examples: Spanish, Italian, German, English, American Sign

LanguageCommunication (CE){CWE:HumanLanguage}
preferenceInd [0..1]

An indicator specifying whether or not this language is preferred by
the focal person for the associated mode

LanguageCommunication (BL)QueryMatchObservation

Used to convey information about the quality of the match for eachrecord.

classCode [1..1] (M)Observation (CS) {CNE:, default= "OBS"}

Structural attribute – this is an observation

moodCode [1..1] (M)Observation (CS) {CNE:, default= "EVN"}

Structural attribute – this is an eventcode [1..1] (M)Observation (CD)
{CWE:QueryMatchObservationType}A code, identifying this observation as a query match observation.

value [1..1] (M)QueryMatchObservation (INT)

A numeric value indicating the quality of match for this record. It
shall correspond to the MinimumDegreeMatch.value attribute of theoriginal query, and it shall have the same meaning (e.g., percentage,
indicating confidence in the match).

Rev. 9.0 Final Text – 2012-08-31

237

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.2.2.3 Control Act and Transmission Wrappers
6015

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.47.4.4.2-9: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

MFMI_MT700711UV01 – Master File/Registry Query
Response Control Act (Role Subject)

The value of interactionId SHALL be set to
PRPA_IN201306UV02

The value of ControlActProcess.moodCode SHALL be set
to EVNThe value of processingModeCode SHALL be set
to T

The trigger event code in ControlActProcess.code SHALL
be set to PRPA_TE201306UV02

The acceptAckCode SHALL be set to NE

There SHALL be zero or more RegistrationEvents present
in this message.

There SHALL be only one receiver Device

For each matching record returned, there SHALL be exactly
one RegistrationEvent present in this message.
If a RegistrationEvent is part of the message, there SHALL
be exactly one Patient role present in the payload.
There SHALL be no replacementOf act-relationship present
in this message
There SHALL be a QueryByParameter copy of the original
query.
The QueryAck.resultTotalQuantity,
QueryAck.resultCurrentQuantity, andQueryAck.resultRemainingQuantity attributes SHALL havethe appropriate values populated.

6020

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201306UV02.xsd).
3.47.4.2.2.4 Web Services Types and Messages
The Patient Registry Query by Demographics message will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.

6025

The following WSDL naming conventions SHALL apply:
response message-> "PRPA_IN201306UV02_Message"

The following WSDL snippet describes the type for these message:

6030

6035

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201306UV02.xsd"/><xsd:element name="PRPA_IN201306UV02"/>
Rev. 9.0 Final Text – 2012-08-31

238

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</xsd:schema></types>
…

6040

6045

The message is described by the following snippet:…
<message name="PRPA_IN201306UV02_Message"><part element="hl7:PRPA_IN201306UV02" name="Body"/></message>…

3.47.4.2.3 Expected Actions

6050

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 to Patient Demographics Consumers is a list of possible matching patients from thepatient information source associated with the value that the Consumer sent in the Device classof the transmission wrapper of the query message.
If OtherIDsScopingOrganization parameters were part of the query, and they were recognized by
the Patient Demographics Supplier as identifying known Patient Identity Domains, the response
will also, for each patient, contain any Patient ID values found in the specified domains.

6055

The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier and are outside of the scope of this framework.
The Patient Demographics Supplier shall respond to the query request as described by thefollowing 3 cases:

6060

Case 1 The Patient Demographics Supplier finds (in the patient information source associatedwith Receiver.Device in the query transmission wrapper) at least one patient record matching thecriteria sent in the query parameters. There were no OtherIDsScopingOrganization parameters in
the query.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

6065

6070

6075

One RegistrationEvent (and the associated Patient role, subject of that event) is returned from thepatient information source for each patient record found. If the Patient Demographics Supplier
returns data for multiple patients, it shall return these data in successive occurrences of theRegistrationEvent class within the transmission wrapper.
For each patient, one or more identifiers from the Patient ID Domain associated with the target
patient information source identified by Receiver.Device are represented as Patient.id attributes.
If an incremental number of records are specified in QueryByParamter.initialQuantity (i.e., theConsumer supports the Continuation option), and the number of records to be sent exceeds that
incremental number, the Supplier shall return only up to the incremental number of records. If
the Supplier supports the Continuation option, it shall correctly populate the resultTotalQuantity,
resultCurrentQuantity, and resultRemainingQuantity attributes of the QueryAck class in thecontrol act wrapper. If the Supplier does not support the Continuation option, in addition to

Rev. 9.0 Final Text – 2012-08-31

239

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
returning only up to the incremental number of records requested, it shall return AE (application
error in the Acknowledgement.typeCode (transmission wrapper) and AE (application error) is
returned in QueryAck.queryResponseCode (control act wrapper).
6080

6085

The Consumer may then send a query continuation message as a subsequent query request for
the next increment of responses.
Case 2: The Patient Demographics Supplier finds (in the patient information source associatedwith Receiver.Device in the query transmission wrapper) at least one patient record matching thecriteria sent in the query parameters. One or more OtherIDsScopingOrganization parameters arepresent in the query; the Supplier recognizes all the requested domains.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

6090

6095

6100

6105

6110

One RegistrationEvent (and the associated Patient role, subject of that event) is returned fromthe patient information source for each patient record found. If the Patient Demographics
Supplier returns data for multiple patients, it shall return these data in successive occurrences of
the RegistrationEvent class within the transmission wrapper.
For each patient, the identifiers from all the Patient ID Domains requested via the
OtherIDsScopingOrganization parameter are returned either as values of the Patient.id attribute,or as values of the OtherIDs.id attribute. The same patient identifier value shall not appear inboth the Patient.id and OtherIDs.id attributes. The Patient Demographics consumer shallconsider the identifiers from both places as equivalently valid. If the Patient Demographics
supplier cannot provide a patient ID for some of the requested Patient ID Domains, then an
OtherIDs.id attribute shall have an appropriate null value, and the ScopingOrganization classshall identify the corresponding domain.
If an incremental number of records are specified in QueryByParamter.initialQuantity, and thenumber of records to be sent exceeds that incremental number, and the Patient Demographics
Supplier supports the Continuation Option, the Supplier returns only the incremental number ofrecords, correctly populating the resultTotalQuantity, resultCurrentQuantity, andresultRemainingQuantity attributes of the QueryAck class in the control act wrapper. The
consumer will sent a query continuation message as a subsequent query request for the next
increment of responses. If the Supplier does not support the Continuation Option, then AE(application error) is returned in the Acknowledgement.typeCode (transmission wrapper) and AE(application error) is returned in QueryAck.queryResponseCode (control act wrapper).
Case 3: The Patient Demographics Supplier does not recognize one or more
OtherIDsScopingOrganization parameters as representing valid Patient Identity Domains.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
No RegistrationEvent is returned.

6115

The queried-for patient identification domains are returned in the QueryByParameter parameter
list (control act wrapper).

Rev. 9.0 Final Text – 2012-08-31

240

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________For each domain that was not recognized, an AcknowledgmentDetail class is returned in which
the attributes typeCode, code, and location are valued as follows:
Attribute

VALUE

typeCodeEcode

204 (Unknown Key Identifier)location

XPath expression for the value element of the OtherIDsScopingOrganization parameter(which includes the repetition number of the parameter)3.47.4.2.3.1 Web Services Port Type and Binding Definitions
6120

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PDSupplier”.
The following WSDL naming conventions SHALL apply:

6125

6130

6135

wsdl:definitions/@name="PDSupplier":
patient demographics query-> "PRPA_IN201305UV02_Message"
patient demographics response -> "PRPA_IN201306UV02_Message"
continuation query-> "QUQI_IN000003UV01_Message"
accept acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "PDSupplier_PortType"get candidates operation-> "PDSupplier_PRPA_IN201305UV02"
continuation operation->"PDSupplier_PRPA_IN201305UV02_Continue"
cancel operation-> "PDSupplier_PRPA_IN201305UV02_Cancel"
SOAP 1.2 binding-> "PDSupplier_Binding_Soap12"
SOAP 1.2 port-> "PDSupplier_Port_Soap12"

The following WSDL snippets specify the Patient Demographics Query Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
3.47.4.2.3.1.1 Port Type

6140

6145

6150

6155

<portType name="PDSupplier_PortType"><operation name="PDSupplier_PRPA_IN201305UV02"><input message="tns:PRPA_IN201305UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201305UV02"/><output message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201306UV02"/></operation><operation name="PDSupplier_QUQI_IN000003UV01_Continue"><input message="tns:QUQI_IN000003UV01_Message" wsaw:Action="urn:hl7org:v3:QUQI_IN000003UV01_Continue"/><output message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201306UV02"/></operation><operation name="PIXManager_QUQI_IN000003UV01_Cancel"><input message="tns:QUQI_IN000003UV01_Message" wsaw:Action="urn:hl7-org:v3:
QUQI_IN000003UV01_Cancel"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation>Rev. 9.0 Final Text – 2012-08-31

241

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</portType>3.47.4.2.3.1.2 Bindings
6160

6165

6170

6175

6180

6185

6190

6195

SOAP 1.2 binding:…

<binding name="PDSupplier_Binding_Soap12" type="PDSupplier_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PDSupplier_PRPA_IN201305UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201305UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Continue"><wsoap12:operation soapAction="urn:hl7org:v3:QUQI_IN000003UV01_Continue"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Cancel"><wsoap12:operation soapAction="urn:hl7-org:v3:
QUQI_IN000003UV01_Cancel"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

An informative WSDL for the Patient Demographics Supplier implementing the PDQV3 profile
is available online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.47.4.2.3.2 Message Examples
6200

Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.

Rev. 9.0 Final Text – 2012-08-31

242

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.3 Patient Demographics Query HL7V3 Continuation
3.47.4.3.1 Trigger Events

6205

A Patient Demographics Consumer’s need to get another set of matching records to a previously
sent Patient Demographics query will trigger the Patient Demographics Query Continuation
based on the following HL7 trigger event:
Query General Activate Query Continuation (QUQI_TE000003UV01)
An application, in the role of Query Placer, sends a query continuation message to request thatthe application return up to a specified number of matching records based on a previous
demographics query.

6210

3.47.4.3.2 Message Semantics
The Query continuation is supported by the Query Control Act Request Continue / Cancel(QUQI_MT000001UV01) message. The Patient Demographics Consumer shall generate thecontinuation message whenever it needs to receive another set of matching records based on the
results of a previously sent query.

6215

If the Supplier supports the Continuation Option, it shall respond to the continuation request bysending the Patient Registry Find Candidates Response message (PRPA_MT201310), whichuses the Application Level Acknowledgement transmission wrapper. This satisfies therequirements of original mode acknowledgment; no intermediate Accept Acknowledgement is tobe sent.

6220

If a cancellation request is sent by the Patient Demographics Consumer, then the receiver shall
respond by sending an Accept Acknowledgement (see ITI TF-2x: Appendix O for thedescriptions of the Accept Acknowledgement transmission wrapper).
3.47.4.3.2.1 Major Components of the Query Continuation Message

6225

This message contains no domain payload, it is built from a transmission and control act
wrappers.
3.47.4.3.2.2 Message Information Model of the Query Continuation Message
Please see ITI TF-2x: Appendix O for the description of the transmission and control act
wrappers used by this message. The next section discusses the wrappers, and the specificconstraints relevant to this transaction.

6230

3.47.4.3.2.3 Control Act and Transmission Wrappers
Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.47.4.3.2-1 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.

Rev. 9.0 Final Text – 2012-08-31

243

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
6235

Table 3.47.4.3.2-1: Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

QUQI_MT000001UV01 – Query Control Act
Request Continue / Cancel

The value of interactionId SHALL be set to
QUQI_IN000003UV01

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE000003UV01

The value of processingModeCode SHALL be set to T

QueryContinuation.queryId SHALL be set to theoriginal query identifier

The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device
The Acknowledgement.typeCode SHALL be set to AA
The TargetMessage.id SHALL be the message ID of
the immediately preceding Query response message

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/QUQI_IN000003UV01.xsd)
6240

3.47.4.3.2.4 Web Services Types and Messages
The Query Continuation message will be transmitted using Web Services, according to therequirements specified in ITI TF-2x: Appendix V.
The following WSDL naming conventions SHALL apply:
query continuation

6245

6250

6255

-> "QUQI_IN000003UV01_Message"

The following WSDL snippet describes the type for this message:…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/QUQI_IN000003UV01.xsd"/><xsd:element name="QUQI_IN000003UV01"/></xsd:schema></types>…

The message is described by the following snippet:
6260

6265

…
<message name="QUQI_IN000003UV01_Message"><part element="hl7:QUQI_IN000003UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Demographics Service are described
together with the expected actions of the actors which receive these messages in section ITI TF2b: 3.47.4.2.3.

Rev. 9.0 Final Text – 2012-08-31

244

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.3.3 Expected Actions

6270

6275

6280

6285

6290

If a number of records is specified in the initialQuantity of the original quantity, and the Patient
Demographics Supplier supports the Continuation Option, the Patient Demographics Supplier
Actor shall return an incremental response of that number of records when the number ofmatching records it finds exceeds the number of records specified. In subsequent querycontinuation messages, the Patient Demographics Consumer may specify a different number ofrecords to be returned from now on for this query session by populating the continuationQuantity
attribute. In addition, the consumer may specify from which record the next set of matches
should start by populating the startResultNumber attribute. If the Patient Demographics Supplierdoes not support the Continuation Option and the number of matching records to the original
query exceeds the number specified, then, in addition to returning up to that number of records,
the Supplier shall return AE (application error) in the Acknowledgement.typeCode (transmission
wrapper) and AE (application error) in QueryAck.queryResponseCode (control act wrapper).
The Patient Demographics Supplier shall always populate the resultTotalQuantity,
resultCurrentQuantity, and resultRemainingQuantity in the QueryAck class. This information
will indicate to the Patient Demographics Consumer whether there are any remaining records tobe returned in subsequent continuations.
The Patient Demographics Consumer shall indicate a query session cancellation by sending acontinuation message, and setting the continuationQuantity attribute to 0, and setting thestatusCode to "aborted". In such case, the Patient Demographics Supplier shall respond with an
Accept Acknowledgement (as described in ITI TF-2x: Appendix O).
Sending a query cancellation message is optional. The Patient Demographics Supplier may
simply not send any continuation messages once a record has been selected. How long thePatient Demographic Supplier retains query results (for incremental response) is an
implementation decision and therefore beyond the scope of IHE.
3.47.4.3.3.1 Web Services Port Type and Binding Definitions
This information is part of the specification of the Patient Demographics Query response in ITI
TF-2b: 3.47.4.2.3.1.

6295

An informative WSDL for the Patient Demographics Supplier implementing the PDQV3 profile
is available online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.47.4.2.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.

6300

3.47.5 Security Requirements
No transaction specific security considerations.

Rev. 9.0 Final Text – 2012-08-31

245

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

6305

3.47.5.1 Audit Record Considerations
When grouped with ATNA Secure Node or Secure Application actors, this transaction is to beaudited as “Query Information” event, as defined in ITI TF-2a: Table 3.20.6-1. The following
tables show items that are required to be part of the audit record for this transaction.
3.47.5.1.1 Patient Demographics Consumer audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Source (Patient Demographics Consumer) (1)
Human Requestor (0..n)
Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Consumer) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Rev. 9.0 Final Text – 2012-08-31

246

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

6310
Patient(AuditMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AuditMessage/
ParticipantObjectIdentifi
cation)The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized
EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

PARTICIPANTOBJECTIDTYP
ECODE

M

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDU

not specialized

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

3.47.5.1.2 Patient Demographics Source audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

Source (Patient Demographics Consumer) (1)Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Supplier) (1)Patient (0..n)Query Parameters(1)Where:

Rev. 9.0 Final Text – 2012-08-31

247

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Destination

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointIDM

the machine name or IP address, as specified in RFC 3881.

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID

M

The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYU

not specialized

ParticipantObjectDetailUnot specialized

6315

Patient(AuditMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTIDU

not specialized

ParticipantObjectNameU

not specialized

PARTICIPANTOBJECTQUERYM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

Rev. 9.0 Final Text – 2012-08-31

248

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

3.48 Intentionally Left Blank
3.49 Convey Printed Referral Request
6320

This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow(XDW) Profile.

3.50 Request Referral
This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow(XDW) Profile.
6325

3.51 Multi-Patient Stored Query
This section corresponds to Transaction ITI-51 of the IHE Technical Framework. Transaction
ITI-51 is used by the Document Consumer and Document Registry actors.
3.51.1 Scope

6330

The Multi-Patient Stored Query supports a variety of queries for multiple patients. It is based on
the Registry Stored Query transaction [ITI-18]. The main difference is the set of queries, whichis specified in this transaction.
3.51.2 Use Case Roles
Document
ConsumerDocument
Registry

Multi-patientStored Query

Actor: Document Consumer6335

Role: Issues a Multi-Patient Stored Query to retrieve metadata based on criteria common tomultiple patients
Actor: Document Registry
Role: Responds to a Multi-Patient Stored Query by providing the metadata or object referencesof registry objects which satisfy the query parameters

6340

3.51.3 Referenced Standard
Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V Web Services for IHE Transactions.
ebRIM

OASIS ebXML Registry Information Model v3.0

Rev. 9.0 Final Text – 2012-08-31

249

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

6345

ebRS

OASIS ebXML Registry Services Specifications v3.0

ITI-18ITI TF-2a: 3.18: Registry Stored QueryAppendix V

ITI TF-2x: Appendix V: Web Services for IHE Transactions
Contains references to all Web Services standards and requirements of use

3.51.4 Interaction Diagram
Document
SourceDocument
Registry

Multi-Patient Stored
Query Request
Multi-Patient Stored
Query Response

6350

3.51.4.1 Multi-Patient Stored Query Request
This is a query request from the Document Consumer to the Document Registry. The query
request contains:• A reference to a pre-defined query stored on the Document Registry actor• Parameters to the query6355

3.51.4.1.1 Trigger Events
The message is initiated when a Document Consumer wants to query for metadata based on
criteria spanning multiple patients (multiple Patient IDs).
3.51.4.1.2 Message Semantics

6360

The message semantics are identical to those documented for the Registry Stored Query [ITI-18]
transaction except where noted below. The following sections document the differences.
Document Source and Document Registry actors that support the Asynchronous Web Services
Exchange option shall support Asynchronous Web Services requirements as defined in ITI TF2x: V.5.
3.51.4.1.2.1 Query Definitions

6365

This transaction defines the following Stored Queries that may query for multiple Patient Ids.

Rev. 9.0 Final Text – 2012-08-31

250

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.51.4.1.2.1.1 FindDocumentsForMultiplePatients

6370

This Multi-Patient Query is semantically identical to the FindDocuments Stored Query (see ITI
TF-2a: 3.18.4.1.2.3.7.1) except:• $XDSDocumentEntryPatientId is optional (may have zero values).
• $XDSDocumentEntryPatientId may contain multiple values.
• At least one of the ClassCode, EventCodeList, or HealthcareFacilityTypeCode shall be
specified in the provided set of parameters.
Returns: XDSDocumentEntry or ObjectRef objects matching the query parameters
Parameter Name

AttributeMult$XDSDocumentEntryPatientId

XDSDocumentEntry. patientId

O

M$XDSDocumentEntryClassCode1 2

XDSDocumentEntry. classCodeO

M$XDSDocumentEntryTypeCode1

XDSDocumentEntry.typeCodeO

M$XDSDocumentEntryPracticeSettingCode1

XDSDocumentEntry.
practiceSettingCodeO

M$XDSDocumentEntryCreationTimeFrom

Lower value of
XDSDocumentEntry.
creationTimeO--$XDSDocumentEntryCreationTimeTo

Upper value of
XDSDocumentEntry.
creationTimeO--$XDSDocumentEntryServiceStartTimeFrom

Lower value of
XDSDocumentEntry.
serviceStartTimeO--$XDSDocumentEntryServiceStartTimeTo

Upper value of
XDSDocumentEntry.
serviceStartTimeO--$XDSDocumentEntryServiceStopTimeFrom

Lower value of
XDSDocumentEntry.
serviceStopTimeO--$XDSDocumentEntryServiceStopTimeTo

Upper value of
XDSDocumentEntry.
serviceStopTimeO--$XDSDocumentEntryHealthcareFacilityTypeCode1 2

XDSDocumentEntry.
healthcareFacilityTypeCodeO

M$XDSDocumentEntryEventCodeList1 2

XDSDocumentEntry.
eventCodeList3O

M$XDSDocumentEntryConfidentialityCode1

XDSDocumentEntry.
confidentialityCode3O

M$XDSDocumentEntryAuthorPerson4

XDSDocumentEntry. author

O

M$XDSDocumentEntryFormatCode

XDSDocumentEntry. formatCodeO

M$XDSDocumentEntryStatus

XDSDocumentEntry. status

R

M

1

6375

Opt

1

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.

Rev. 9.0 Final Text – 2012-08-31

251

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2

At least one of $XDSDocumentEntryClassCode, $XDSDocumentEntryEventCodeList, or$XDSDocumentEntryHealthcareFacilityTypeCode shall be specified.
36380

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

4

The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows
the use of the following wildcard characters: % to match any (or no) characters and _ to match asingle character. The match shall be applied to the text contained in the Value elements of theauthorPerson Slot on the author Classification (value strings of the authorPerson sub-attribute)
3.51.4.1.2.1.2 FindFoldersForMultiplePatients

6385

This Multi-Patient Query is semantically identical to the FindFolders Stored Query (see ITI TF2a: 3.18.4.1.2.3.7.3) except:
1. $XDSFolderPatientId is optional (may have zero values).
2. $XDSFolderPatientId may contain multiple values.
3. $XDSFolderCodeList shall be a required parameter.

6390

Returns: XDSFolder or ObjectRef objects matching the query parameters
Parameter Name

Attribute

Opt

Mult

$XDSFolderPatientId

XDSFolder.patientId

O

M$XDSFolderLastUpdateTimeFrom

XDSFolder. lastUpdateTime
lower valueO--$XDSFolderLastUpdateTimeTo

XDSFolder. lastUpdateTime
upper boundO--$XDSFolderCodeList1,3

XDSFolder. codeList

R

M$XDSFolderStatus

XDSFolder.status

R

M

1

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.
36395

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

3.51.4.1.2.2 Multi-Patient Stored Query IDs
The following Query Ids shall be used to represent these queries.
Query Name
FindDocumentsForMultiplePatients
FindFoldersForMultiplePatients

Rev. 9.0 Final Text – 2012-08-31

Query ID
urn:uuid:3d1bdb10-39a2-11de-89c22f44d94eaa9f
urn:uuid:50d3f5ac-39a2-11de-a1cab366239e58df

252

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.51.4.1.2.3 Web Services Transport
6400

6405

The query request and response shall be transmitted using Web Services, according to therequirements specified in ITI TF-2x: Appendix V. The specific values for the WSDL describing
the Multi-Patient Stored Query Service are described in this section.
The Document Registry actor shall accept a Multi-Patient Stored Query Request formatted as a
SIMPLE SOAP message and respond with a Multi-Patient Stored Query Response formatted asa SIMPLE SOAP message. The Document Consumer actor shall generate the Multi-PatientStored Query Request formatted as a SIMPLE SOAP message and accept a Multi-Patient Stored
Query Response formatted as a SIMPLE SOAP message.
IHE-WSP201) The attribute /wsdl:definitions/@name shall be “DocumentRegistry”.
The following WSDL naming conventions shall apply:

6410

6415

wsdl:definitions/@name="DocumentRegistry":
query message-> "MultiPatientStoredQuery_Message"
query response-> "MultiPatientStoredQueryResponse_Message"
portType-> "DocumentRegistry_PortType"operation-> "DocumentRegistry_MultiPatientStoredQuery"
SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port-> "DocumentRegistry_Port_Soap12"

IHE-WSP202) The targetNamespace of the WSDL shall be “urn:ihe:iti:xds-b:2007”

6420

6425

6430

These are the requirements for the Multi-Patient Stored Query transaction presented in the orderin which they would appear in the WSDL definition:
1. The following types shall be imported (xsd:import) in the /definitions/types section:
2. namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0",
schemaLocation="query.xsd"
3. The /definitions/message/part/@element attribute of the Multi-Patient Stored Query Request
message shall be defined as “query:AdhocQueryRequest”
4. The /definitions/message/part/@element attribute of the Multi-Patient Stored Query
Response message shall be defined as “query:AdhocQueryResponse”
5. The /definitions/portType/operation/input/@wsaw:Action attribute for the Multi-PatientStored Query Request message shall be defined as“urn:ihe:iti:2009:MultiPatientStoredQuery”
6. The /definitions/portType/operation/output/@wsaw:Action attribute for the Multi-PatientStored Query Response message shall be defined as“urn:ihe:iti:2009:MultiPatientStoredQueryResponse”
7. The /definitions/binding/operation/soap12:operation/@soapAction attribute should be
defined as “urn:ihe:iti:2009:MultiPatientStoredQuery”

6435

The following WSDL fragment shows an example of Multi-Patient Stored Query transaction
definition:

6440<?xml version="1.0" encoding="utf-8"?><definitions ...>...
<types>Rev. 9.0 Final Text – 2012-08-31

253

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

6445
6450
6455
6460
6465

<xsd:schema elementFormDefault="qualified" targetNamespace="urn:ihe:iti:xds-b:2007"><xsd:importnamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
schemaLocation="schema\query.xsd"/>...
</xsd:schema></types><message name="RegistryStoredQuery_Message"><documentation>Multi-Patient Stored Query</documentation><part name="body" element="query:AdhocQueryRequest"/></message><message name="RegistryStoredQueryResponse_Message"><documentation>Multi-Patient Stored Query Response</documentation><part name="body" element="query:AdhocQueryResponse"/></message>...
<portType name="MPQRegistry_PortType"><operation name="MultiPatientStoredQuery"><input message="ihe:RegistryStoredQuery_Message"
wsaw:Action="urn:ihe:iti:2009:MultiPatientStoredQuery"/><output message="ihe:RegistryStoredQueryResponse_Message"
wsaw:Action="urn:ihe:iti:2009:MultiPatientStoredQueryResponse"/></operation>...
</portType>...
</definitions>

A full WSDL for the Document Consumer and Document Registry actors is found in ITI TF-2x:
Appendix W.
6470

6475

3.51.4.1.2.4 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <a:Action/>,<a:MessageID/>, <a:ReplyTo/>…; these WS-Addressing headers are populated according to ITI
TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP message isomitted for brevity; in a real scenario the empty element will be populated with the appropriate
metadata.
Samples presented in this section are also available online on the IHE FTP site, see ITI TF-2x:
Appendix W.

6480
6485
6490
6495

3.51.4.1.2.4.1 Sample Multi-Patient Stored Query SOAP Request<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2009:MultiPatientStoredQuery</a:Action><a:MessageID>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:MessageID><a:ReplyTo s:mustUnderstand="1">><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To>http://localhost/service/IHEMPQRegistry.svc</a:To></s:Header><s:Body><query:AdhocQueryRequest
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/><!-- FindDocumentsForMultiplePatients -->Rev. 9.0 Final Text – 2012-08-31

254

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________

6500
6505
6510
6515

<rim:AdhocQuery id="urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f"><rim:Slot name="$XDSDocumentEntryStatus"><rim:ValueList><rim:Value>('urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Approved')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryClassCode"><rim:ValueList><rim:Value>'26436-6'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryClassCodeScheme"><rim:ValueList><rim:Value>'LOINC'</rim:Value></rim:ValueList></rim:Slot>--><!-- Note the lack of a specification of the $XDSDocumentEntryPatientId parameter

6520
6525

</rim:AdhocQuery></query:AdhocQueryRequest></s:Body></s:Envelope>

3.51.4.1.2.4.2 Sample Multi-Patient Stored Query SOAP Response
6530
6535
6540
6545
6550

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2009:MultiPatientStoredQueryResponse</a:Action><a:RelatesTo>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:RelatesTo></s:Header><s:Body><query:AdhocQueryResponse
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><!-- Internal details of ExtrinsicObjects are not shown --><rim:ExtrinsicObject/><rim:ExtrinsicObject/><rim:ExtrinsicObject/><rim:ExtrinsicObject/><rim:ExtrinsicObject/><rim:ExtrinsicObject/></rim:RegistryObjectList></query:AdhocQueryResponse></s:Body></s:Envelope>

3.51.4.1.3 Expected Actions
See Registry Stored Query [ITI-18] for Expected Actions.
6555

3.51.5 Security Considerations
All of the Security Considerations found in ITI-18 apply with the following further profiling.

Rev. 9.0 Final Text – 2012-08-31

255

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
It is expected that the ATNA Secure Node authentication would be used to restrict access to the
MPQ transaction. It is expected that few systems would be allowed to request the LeafClass
return result.
6560

3.51.5.1 Security Audit Considerations
The Actors involved shall record audit events for each patient identity that has been included in
the result according to the following. It is important for security auditing that the audit message
contain one patient identity to better handle these messages in the Audit Record Repository:
3.51.5.1.1 Document Consumer audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-51”,“IHE Transactions”,“Multi-Patient Query”0

UserIDC

When WS-Addressing is used: <ReplyTo/>

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“true”

Source (Document Consumer) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)Audit Source (Document Consumer) (1)Patient (1)Query Parameters(1)SourceAuditMessage/
ActiveParticipantM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

Access Control role(s) the user holds that allows this transaction.

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

Rev. 9.0 Final Text – 2012-08-31

256

Human
Requestor(if known)
AuditMessage/
ActiveParticipant

6565

RoleIDCode

Where:
Destination
AuditMessage/

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specializedM

The patient ID in HL7 CX format.

U

not specialized

PARTICIPANTOBJECTQUERYParticipantObjectDetailUnot specializedU

not specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

PARTICIPANTOBJECTIDTYP
ParticipantObjectSensitivity

MU

not specialized

M

Stored Query ID (UUID)PARTICIPANTOBJECTID
ParticipantObjectName

Query
Parameters(AuditMessage/
ParticipantObjectIdenti
fication)

PARTICIPANTOBJECTID
ParticipantObjectName
PARTICIPANTOBJECTQUERYParticipantObjectDetail

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Query”)C

If known the value of <ihe:HomeCommunityId/>

M

the AdhocQueryRequest, base64 encoded.

U

not specialized

3.51.5.1.2 Document Registry audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Query”)

Source (Document Consumer) (1)Destination (Document Registry) (1)Audit Source (Document Registry) (1)Patient (0..1)
Query Parameters(1)6570

Where:

Rev. 9.0 Final Text – 2012-08-31

257

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AuditMessage/
ParticipantObjectIdenti
fication)

UserIDC

When WS-Addressing is used: <ReplyTo/>

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

UserID

M

SOAP endpoint URI.

AlternativeUserIDM

the process ID as used within the local operating system in the local
system logs.

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address, as specified in RFC 3881.

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(2, RFC-3881, “Patient Number”)

ParticipantObjectSensitivityU

not specialized

PARTICIPANTOBJECTID
ParticipantObjectName

Query
Parameters(AuditMessage/
ParticipantObjectIdenti
fication)M

The patient ID in HL7 CX format.

U

not specialized

PARTICIPANTOBJECTQUERYParticipantObjectDetailUnot specializedU

not specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode
ParticipantObjectSensitivity
PARTICIPANTOBJECTID
ParticipantObjectName
PARTICIPANTOBJECTQUERYParticipantObjectDetailRev. 9.0 Final Text – 2012-08-31

M
U

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Query”)
not specialized

M

Stored Query ID (UUID)C

If known the value of <ihe:HomeCommunityId/>

M

the AdhocQueryRequest, base64 encoded.

U

not specialized

258

Copyright © 2012 IHE International, Inc.