Integrating the Healthcare Enterprise

5

10

IHE IT Infrastructure
Technical Framework
Volume 2b(ITI TF-2b)
Transactions Part B –Sections 3.29 – 3.64

15

20

Revision 14.0 – Final Text
July 21, 201725

Please verify you have the most recent version of this document, which is published here.

Copyright © 2017 IHE International, Inc.

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

30

35

40

45

50

55

60

65

1 Introduction ................................................................................................................................ 7
1.1 Overview of the Technical Framework .............................................................................. 8
1.2 Overview of IT Infrastructure Technical Framework Volumes 2a, 2b, 2x, and 3 .............. 8
1.3 Audience ............................................................................................................................. 9
1.4 Relationship to Standards ................................................................................................... 9
1.5 Relationship to Real-world Architectures ........................................................................... 9
1.6 Comments ......................................................................................................................... 10
1.7 Copyright Permission........................................................................................................ 10
2 Conventions ............................................................................................................................. 11
2.1 The Generic IHE Transaction Model ................................................................................ 11
2.2 HL7 Profiling Conventions ............................................................................................... 12
2.3 Use of Coded Entities and Coding Schemes..................................................................... 12
3 IHE Transactions ...................................................................................................................... 13
3.29 Intentionally Left Blank ................................................................................................... 13
3.30 Patient Identity Management [ITI-30] .............................................................................. 13
3.30.1
Scope .................................................................................................................. 13
3.30.2
Use Case Roles ................................................................................................... 13
Referenced Standards ......................................................................................... 14
3.30.33.30.4
Message sets and options.................................................................................... 14
3.30.5
Common HL7 Message Segments ..................................................................... 15
3.30.6
Interactions ......................................................................................................... 32
3.31 Patient Encounter Management [ITI-31] .......................................................................... 41
Scope .................................................................................................................. 41
3.31.1
3.31.2
Use Case Roles ................................................................................................... 41
3.31.3
Referenced Standards ......................................................................................... 41
3.31.4
Definition of the concept “Movement” .............................................................. 41
3.31.5
Message sets and options.................................................................................... 43
Common HL7 Message Segments ..................................................................... 50
3.31.6
3.31.7
Interactions ......................................................................................................... 52
3.32 Distribute Document Set on Media [ITI-32] .................................................................... 89
3.32.1 Scope ........................................................................................................................ 90
3.32.2 Use Case Roles ......................................................................................................... 90
3.32.3 Referenced Standard ................................................................................................ 90
3.32.4 Interaction Diagram.................................................................................................. 91
3.32.5 Security considerations............................................................................................. 98
3.33 Intentionally Left Blank .................................................................................................... 99
3.34 Retrieve Form [ITI-34] .................................................................................................. 100
3.34.1 Scope ...................................................................................................................... 100
3.34.2 Use Case Roles ....................................................................................................... 100
3.34.3 Referenced Standards ............................................................................................. 100
3.34.4 Interaction Diagram................................................................................................ 101__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

2

Copyright © 2017 IHE International, Inc.

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

75

80

85

90

95

100

105

110

3.34.5 Protocol Requirements ........................................................................................... 106
3.35 Submit Form [ITI-35] .................................................................................................... 109
3.35.1 Scope ...................................................................................................................... 109
3.35.2 Use Case Roles ....................................................................................................... 109
3.35.3 Referenced Standards ............................................................................................. 109
3.35.4 Interaction Diagram................................................................................................ 110
3.35.5 Protocol Requirements ........................................................................................... 111
3.35.6 Security Considerations.......................................................................................... 114
3.36 Archive Form [ITI-36] ................................................................................................... 115
3.36.1 Scope ...................................................................................................................... 115
3.36.2 Use Case Roles ....................................................................................................... 115
3.36.3 Referenced Standards ............................................................................................. 115
3.36.4 Interaction Diagram................................................................................................ 116
3.36.5 Protocol Requirements ........................................................................................... 117
3.36.6 Security Considerations.......................................................................................... 119
3.37 Retrieve Clarifications [ITI-37] ..................................................................................... 120
3.37.1 Scope ...................................................................................................................... 120
3.37.2 Use Case Roles ....................................................................................................... 120
3.37.3 Referenced Standards ............................................................................................. 120
3.37.4 Interaction Diagram................................................................................................ 121
3.37.5 Protocol Requirements ........................................................................................... 124
3.38 Cross Gateway Query [ITI-38] ...................................................................................... 127
3.38.1 Scope ...................................................................................................................... 127
3.38.2 Use Case Roles ....................................................................................................... 127
3.38.3 Referenced Standard .............................................................................................. 128
3.38.4 Interaction Diagram................................................................................................ 128
3.38.5 Protocol Requirements ........................................................................................... 133
3.39 Cross Gateway Retrieve [ITI-39] ................................................................................... 136
3.39.1 Scope ...................................................................................................................... 136
3.39.2 Use Case Roles ....................................................................................................... 136
3.39.3 Referenced Standard .............................................................................................. 137
3.39.4 Interaction Diagram................................................................................................ 137
3.39.5 Protocol Requirements ........................................................................................... 139
3.39.6 Security Considerations.......................................................................................... 143
3.40 Provide X-User Assertion [ITI-40] ................................................................................ 144
3.40.1
Scope ................................................................................................................ 144
3.40.2
Use Case Roles ................................................................................................. 144
3.40.3 Referenced Standards ............................................................................................. 144
3.40.4 Interaction Diagram................................................................................................ 146
3.41 Provide and Register Document Set-b [ITI-41] .............................................................. 155
3.41.1 Scope ...................................................................................................................... 155
3.41.2 Actor Roles ............................................................................................................. 155
3.41.3 Referenced Standards ............................................................................................. 155
3.41.4 Interaction Diagrams .............................................................................................. 156__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

3

Copyright © 2017 IHE International, Inc.

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

115

120

125

130

135

140

145

150

155

3.41.5 Security Considerations.......................................................................................... 162
3.42 Register Document Set-b [ITI-42] .................................................................................. 166
3.42.1 Scope ...................................................................................................................... 166
3.42.2 Actor Roles ............................................................................................................. 166
3.42.3 Referenced Standards ............................................................................................. 166
3.42.4 Interaction Diagram................................................................................................ 166
3.42.5 Security Considerations.......................................................................................... 173
3.43 Retrieve Document Set [ITI-43] ..................................................................................... 177
3.43.1 Scope ...................................................................................................................... 177
3.43.2 Use Case Roles ....................................................................................................... 177
3.43.3 Referenced Standard .............................................................................................. 178
3.43.4 Interaction Diagram................................................................................................ 178
3.43.5 Protocol Requirements ........................................................................................... 182
3.43.6 Security Considerations.......................................................................................... 190
3.44 Patient Identity Feed HL7 V3 [ITI-44] .......................................................................... 194
3.44.1 Scope ...................................................................................................................... 194
3.44.2 Use Case Roles ....................................................................................................... 194
3.44.3 Referenced Standards ............................................................................................. 195
3.44.4 Interaction Diagrams .............................................................................................. 195
3.44.5 Security Requirements ........................................................................................... 215
3.45 PIXV3 Query [ITI-45] ................................................................................................... 219
3.45.1 Scope ...................................................................................................................... 219
3.45.2 Use Case Roles ....................................................................................................... 219
3.45.3 Referenced Standards ............................................................................................. 219
3.45.4 Interaction Diagrams .............................................................................................. 220
3.45.5 Security Requirements ........................................................................................... 233
3.46 PIXV3 Update Notification [ITI-46] ............................................................................. 237
3.46.1 Scope ...................................................................................................................... 237
3.46.2 Use Case Roles ....................................................................................................... 237
3.46.3 Referenced Standards ............................................................................................. 237
3.46.4 Interaction Diagrams .............................................................................................. 238
3.46.5 Security Requirements ........................................................................................... 245
3.47 Patient Demographics Query HL7 V3 [ITI-47] ............................................................. 247
3.47.1 Scope ...................................................................................................................... 247
3.47.2 Use Case Roles ....................................................................................................... 248
3.47.3 Referenced Standards ............................................................................................. 248
3.47.4 Interaction Diagrams .............................................................................................. 249
3.47.5 Security Requirements ........................................................................................... 271
3.48 Retrieve Value Set [ITI-48] ........................................................................................... 275
3.48.1 Scope ...................................................................................................................... 275
3.48.2 Use case roles ......................................................................................................... 275
3.48.3 Referenced Standards ............................................................................................. 276
3.48.4 Interaction Diagram................................................................................................ 276
3.48.5 Protocol Requirements ........................................................................................... 278__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

4

Copyright © 2017 IHE International, Inc.

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

160

165

170

175

180

185

190

195

200

3.48.6 Security Requirements ........................................................................................... 283
3.49 Convey Printed Referral Request [ITI-49] ..................................................................... 286
3.50 Request Referral [ITI-50] ............................................................................................... 286
3.51 Multi-Patient Stored Query [ITI-51] .............................................................................. 286
3.51.1 Scope ...................................................................................................................... 286
3.51.2 Use Case Roles ....................................................................................................... 286
3.51.3 Referenced Standard .............................................................................................. 286
3.51.4 Interaction Diagram................................................................................................ 287
3.51.5 Security Considerations.......................................................................................... 292
3.52 Document Metadata Subscribe [ITI-52] ........................................................................ 296
3.52.1 Scope ...................................................................................................................... 296
3.52.2 Use Case Roles ....................................................................................................... 296
3.52.3 Referenced Standards ............................................................................................. 297
3.52.4 Interaction Diagram................................................................................................ 297
3.52.5 Subscription Topics and Filter Expressions ........................................................... 302
3.52.6 Security Considerations.......................................................................................... 310
3.53 Document Metadata Notify [ITI-53] .............................................................................. 315
3.53.1 Scope ...................................................................................................................... 315
3.53.2 Use Case Roles ....................................................................................................... 315
3.53.3 Referenced Standards ............................................................................................. 316
3.53.4 Interaction Diagram................................................................................................ 316
3.53.5 Security Considerations.......................................................................................... 320
3.54 Document Metadata Publish [ITI-54] ............................................................................ 324
3.54.1 Scope ...................................................................................................................... 324
3.54.2 Use Case Roles ....................................................................................................... 324
3.54.3 Referenced Standards ............................................................................................. 325
3.54.4 Interaction Diagram................................................................................................ 325
3.54.5 Security Considerations.......................................................................................... 327
3.55 Cross Gateway Patient Discovery [ITI-55] .................................................................... 331
3.55.1 Scope ...................................................................................................................... 331
3.55.2 Use Case Roles ....................................................................................................... 332
3.55.3 Referenced Standard .............................................................................................. 333
3.55.4 Interaction Diagram................................................................................................ 333
3.55.5 Security Considerations.......................................................................................... 358
3.55.6 Protocol Requirements ........................................................................................... 361
3.56 Reserved for Patient Location Query [ITI-56] ............................................................... 367
3.57 Reserved for Update Document Set [ITI-57] ................................................................. 367
3.58 Reserved for Provider Information Query [ITI-58] ....................................................... 367
3.59 Reserved for Provider Information Feed [ITI-59] ......................................................... 367
3.60 Retrieve Multiple Value Sets [ITI-60] ........................................................................... 367
3.60.1 Scope ...................................................................................................................... 367
3.60.2 Use case roles ......................................................................................................... 367
3.60.3 Referenced Standards ............................................................................................. 367
3.60.4 Interaction Diagram................................................................................................ 368__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

5

Copyright © 2017 IHE International, Inc.

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

205

210

3.60.5 Protocol Requirements ........................................................................................... 373
3.60.6 Security Requirements ........................................................................................... 375
3.61 Register On-Demand Document Entry [ITI-61] ............................................................ 376
3.61.1 Scope ...................................................................................................................... 376
3.61.2 Use Case Roles ....................................................................................................... 376
3.61.3 Referenced Standard .............................................................................................. 376
3.61.4 Interaction Diagram................................................................................................ 377
3.61.7 Security Considerations.......................................................................................... 381
3.62 Reserved for Remove Metadata [ITI-62] ....................................................................... 384
3.63 Reserved for Cross Gateway Fetch [ITI-63] .................................................................. 384
3.64 Reserved for Notify XAP-PID Link Change [ITI-64] ................................................... 384__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

6

Copyright © 2017 IHE International, Inc.

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

215

1 Introduction

220

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 a forum
for encouraging integration efforts. It defines a technical framework for the implementation of
established messaging standards to achieve specific clinical goals. It includes a rigorous testingprocess for the implementation of this framework. And it organizes educational sessions andexhibits at major meetings of medical professionals to demonstrate the benefits of thisframework and encourage its adoption by industry and users.

225

230

235

240

245

The approach employed in the IHE initiative is to support the use of existing standards, e.g.,
HL7®1, ASTM, DICOM®2, ISO, IETF, OASIS and others as appropriate, rather than to define
new standards. 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

HL7 is the registered trademark of Health Level Seven International.

DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards
publications relating to digital communications of medical information.

2__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

7

Copyright © 2017 IHE International, Inc.

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

1.1 Overview of the Technical Framework
250

255

260

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 14.0 for Final Text, specifies the IHE transactions defined andimplemented as of July 21, 2017. The latest version of the document is always available via theInternet at http://ihe.net/Technical_Frameworks.
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.

265

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:

270

275

•

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-1: 1.6.3.

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

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:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

8

Copyright © 2017 IHE International, Inc.

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

Volume 2a: Sections 3.1 - 3.28 corresponding to transactions [ITI-1] through [ITI-28].

•

Volume 2b: Sections 3.29 - 3.64 corresponding to transactions [ITI-29] through [ITI-64].

Volume 2x contains all appendices providing technical details associated with the transactions.
Volume 3, Section 4 contains specifications that are used by multiple transactions.
Volume 3, Section 5 contains Content Specifications.
290

1.3 Audience
The intended audience of this document is:295•

IT departments of healthcare institutions•

Technical staff of vendors planning to participate in the IHE initiative•

Experts involved in standards development•

Those interested in integrating healthcare information systems and workflows

1.4 Relationship to Standards

300

305

310

315

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
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,__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

9

Copyright © 2017 IHE International, Inc.

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

325

330

335

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
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 http://www.ihe.net/ITI_Public_Comments orby sending an email to the co-chairs and secretary of the IT Infrastructure domain committees at
iti@ihe.net.
340

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.
The National Electrical Manufacturers Association (NEMA) has granted permission to the IHE
to incorporate portions of the DICOM standard.

345

All rights reserved. Material drawn from these documents is credited where used.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

10

Copyright © 2017 IHE International, Inc.

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

2

Conventions

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

2.1 The Generic IHE Transaction Model
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.

355

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

360

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. 14.0 Final Text – 2017-07-21

11

Copyright © 2017 IHE International, Inc.

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

Actor

Actor
MSG1

MSG2
MSG3

365

370

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
375

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

2.3 Use of Coded Entities and Coding Schemes
380

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. 14.0 Final Text – 2017-07-21

12

Copyright © 2017 IHE International, Inc.

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

3 IHE Transactions
385

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.

3.29 Intentionally Left Blank
3.30 Patient Identity Management [ITI-30]
390

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

395

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

400

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
Source405

Patient
Demographics
Consumer

Patient Identifier
Cross-ReferenceManager

Patient Identity
Management

Actor: Patient Demographics SupplierRole: Adds and modifies patient demographics.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

13

Copyright © 2017 IHE International, Inc.

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

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, 15415

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.

420

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 Sections 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 Section 3.30.4.3).
3.30.4.1 Required message subset with option “Merge”

425
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

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. 14.0 Final Text – 2017-07-21

14

Copyright © 2017 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
430

435

440

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.4.4 Acknowledgement Support
An actor that claims support for the Acknowledgement Support Option shall be capable of using
the enhanced acknowledgement mode as defined in the HL7 v2.x standard. See HL7 Volume 2C,
Section C.2.3 for further details.

445

3.30.4.5 Ambulatory Patient Data
If the Patient Demographics Supplier supports the Ambulatory Patient Data Option, it SHALL
supply the patient address in field PID-11 for ambulatory patients whenever this address isknown.
3.30.5 Common HL7 Message Segments

450

This section describes the common HL7 message segments used in transaction ITI-30.
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

455

Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)
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.
Table 3.30-1: MSH - Message Header
SEQ

LEN

DT

Usage

Card.

1

1

ST

R

[1..1]

TBL#

ITEM#
00001

Element nameField 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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

15

Copyright © 2017 IHE International, Inc.

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

460

465

SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

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

O

[0..1]

0155

00015

Accept Acknowledgement Type

16

2

ID

O

[0..1]

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

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.
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 ITI TF-2x: Appendix C.
MSH-3 Sending Application (HD) and MSH-5 Receiving Application (HD), required. See theconstrainable profile definition of data type HD.

470

MSH-4 Sending Facility (HD) and MSH-6 Receiving Facility (HD), required. See theconstrainable profile definition of data type HD.
MSH-9 Message Type (MSG), required:
Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>475

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:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

16

Copyright © 2017 IHE International, Inc.

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

480

Definition: This field contains a number or other identifier that uniquely identifies the message inthe 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.
MSH-12 Version ID (VID), required:
Components: <Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version ID
(CE)>

485

Definition: This field is matched by the receiving system to its own version to be sure themessage will be interpreted correctly.
The first component SHALL be populated with the value "2.5" representing HL7 Version 2.5.
MSH-15 Accept Acknowledgment Type (ID), optional.

490

As a minimal requirement for all actors, the Original Acknowledgement Mode shall besupported, in which case this field of the message will remain empty.
If an actor declares the “Acknowledgement Support” Option, it shall be able to use Enhanced
Acknowledgement Mode.
MSH-16 Application Acknowledgment Type (ID), optional.

495

As a minimal requirement for all actors, the Original Acknowledgement Mode shall besupported, in which case this field of the message will remain empty.
If an actor declares the “Acknowledgement Support” Option, it shall be able to use Enhanced
Acknowledgement Mode.
MSH-17 Country Code (ID), required if available.

500

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.

505

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.

510

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

17

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
is the forward-compatible version of 8859/1 and includes new characters such as the Euro
currency symbol.
515

ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X 02081990).
UNICODE UTF-8: UCS Transformation Format, 8-bit form.

520

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 = Italian525

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.

530

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

535

SEQ

LEN

DT

Usage

1

3

ID

X

[0..0]

Card.

TBL#

2

26

TS

R

[1..1]

3

26

TS

C

[0..1]

4

3

IS

O

[0..1]

0062

5

250

XCN

O

[0..*]

0188

6

26

TS

C

7

241

HD

RE

0003

ITEM#

Element name00099

Event Type Code

00100

Recorded Date Time

00101

Date/Time Planned Event

00102

Event Reason Code00103

Operator ID[0..1]

01278

Event Occurred[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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

18

Copyright © 2017 IHE International, Inc.

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

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
update of 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 thedate/time of the planned event. For consistency of use, IHE recommends that the content
of the specific field of PV2 be also copied to EVN-3.

545

550

National extensions of this transaction may extend the condition above.
EVN-6 Event Occurred (TS): Conditional. This field contains the date/time that the event reallyoccurred.
Condition predicate:

555

560

•

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).
3.30.5.3 PID - Patient Identification segment
Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.2)

565

The PID segment is used by all applications as the primary means of communicating patient
identification information. This segment contains permanent patient identifying and demographic
information that, for the most part, is not likely to change frequently.
Table 3.30-3: PID - Patient Identification segment
SEQ

LEN

DT

Usage

1
2

Card.

TBL#

ITEM#

Element name

4

SI

O

[0..1]

00104

Set ID - PID

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

19

Copyright © 2017 IHE International, Inc.

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

LEN

DT

Usage

6

250

XPN

O
(Note 1)

7

26

TS

8

1

IS

Card.

TBL#

ITEM#

Element name[0..1]

00109

Mother’s Maiden Name

CE
(Note 1)[0..1]

00110

Date/Time of Birth

CE(Note 1)

[1..1]

0001

00111

Administrative Sex

00112

Patient Alias

0005

00113

Race

00114

Patient Address

00115

County Code

9

250

XPN

X

[0..1]

10

250

CE

O

[0..1]

11

250

XAD

CE
(Note 1)[0..*]

12

4

IS

X

[0..1]

13

250

XTN

O
(Note 1)[0..*]

00116

Phone Number - Home

14

250

XTN

O

[0..*]

00117

Phone Number - Business

15

250

CE

O

[0..1]

0296

00118

Primary Language

16

250

CE

O

[0..1]

0002

00119

Marital Status

17

250

CE

O

[0..1]

0006

00120

Religion

18

250

CX

C

[0..1]

00121

Patient Account Number

19

16

ST

X

[0..1]

00122

SSN Number - Patient

20

25

DLN

X

[0..1]

00123

Driver's License Number - Patient

21

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
(Note 1)[0..1]

00127

Multiple Birth Indicator

25

2

NM

O
(Note 1)[0..1]

00128

Birth Order

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

CE

[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
(Note 1)[0..1]

01537

Last Update Date/Time

34

241

HD

O
(Note 1)[0..1]

01538

Last Update Facility

35

250

CE

CE

[0..1]

0446

01539

Species Code

36

250

CE

C

[0..1]

0447

01540

Breed Code

37

80

ST

O

[0..1]

01541

Strain

0289

0189
0136

0136

00739

Nationality

00740

Patient Death Date and Time

00741

Patient Death Indicator__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

20

Copyright © 2017 IHE International, Inc.

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

LEN

DT

Usage

38

250

CE

O

[0..2]

01542

Production Class Code

39

250

CWE

O

[0..*]

01840

Tribal Citizenship

Note 1:

Card.

TBL#

ITEM#

Element name

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

570
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).
575

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.
As shown in the constrained profile definition of data type CX in ITI TF-2x: Appendix N.1,
subfields CX-1 “ID number”, CX-4 “Assigning authority” are required, and CX-5 “Identifier
Type Code” is required if known for each identifier.

580

This field may be populated with various identifiers assigned to the patient by various assigningauthorities.
The authorized values for subfield CX-5 “Identifier Type Code” are given in HL7 Table 0203
(HL7 Version 2.5, Chapter 2A, Section 2A.17.5).
Values commonly used for Identifier Type Code in the context of PID-3 are as follows:

585

590

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.

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

21

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PID-6 – Mother’s Maiden Name (XPN), conditional:
600

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.
PID-7 – Date/Time of Birth (TS), conditional.
Condition predicate:

605

610

•

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), registrationof 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).

•

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)or to the year and month of birth (e.g., 195411).

PID-8 – Administrative Sex (IS), conditional.
Condition predicate:615•This field is required if available in the following 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).

•

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

Description

F

Female

M

Male

O

Other

U

Unknown

A

AmbiguousN

Not applicable

Comment

620
PID-10 – Race (CE), optional: The patient race is information of critical medical importance inpractices such as imaging. Therefore this information shall be present if known, except whereprohibited. For example, France prohibits inclusion of Patient Race.
PID-11 – Patient Address (XAD), conditional:
625

Condition predicate:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

22

Copyright © 2017 IHE International, Inc.

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

630•

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), registrationof an 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:This 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), Conditional.

635

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.
Relationship to encounter: A patient account can span more than one enterprise encounter.

640

Condition predicate: 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.
Additional requirements for the presence of value in these fields may be documented in national
extensions of this transaction.
PID-24 – Multiple Birth Indicator (ID), conditional.
Condition predicate:645This 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.
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.

650

PID-29 – Patient Death Date and Time (TS), conditional:
Condition predicate:655•This field is required in the Patient Discharge message of transaction ITI-31 if theencounter is terminated by the patient’s death and the death date is known. It provides thedate/time of the patient’s death.

•

In all other Patient Discharge messages, it shall not be populated.

PID-30 – Patient Death Indicator (ID), conditional:
Condition predicate:•This field is required to be populated with value “Y” in the Patient Discharge message oftransaction ITI-31 when the encounter is terminated by the patient’s death.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

23

Copyright © 2017 IHE International, Inc.

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

Otherwise it is optional.

PID-31 – Identity Unknown Indicator (ID), conditional:
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), registrationof 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).

•

In all other messages, it is optional.

665

The possible values are “Y”, and “N” which is the default.
670

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:
Condition predicate:675•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), registrationof 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).

•

In all other messages, it is optional.

The field is repeatable. The possible values are taken from HL7 user-defined Table 0445:
680

User-defined Table 0445: Identity Reliability Code
Value
AL

Description

Comment (added by IHE for this profile)

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:
Condition predicate:
685

690

•

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), registrationof 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).

•

In the cases of messages A08 and A31, the content of this field is equal to the value in
EVN-6-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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

24

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PID-34 – Last Update Facility (HD), conditional.
Condition predicate:695This 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.
PID-35 – Species Code (CE) and PID-36 – Breed Code (CE), conditional:
Condition predicate:

700

705

•

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 ITI31).

3.30.5.4 PV1 - Patient Visit segment
Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.3)
The PV1 segment is used by Registration/Patient Administration applications to communicate
information on an account or visit-specific basis.
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]

00135

Preadmit Number

6

80

PL

C

[0..1]

00136

Prior Patient Location

7

250

XC
N

O

[0..*]

0010

00137

Attending Doctor

8

250

XC
N

O

[0..*]

0010

00138

Referring Doctor

9

250

XC
N

X

[0..0]

0010

00139

Consulting Doctor

10

3

IS

O

[0..1]

0069

00140

Hospital Service

11

80

PL

C

[0..1]

00141

Temporary Location

12

2

IS

O

[0..1]

0087

00142

Preadmit Test Indicator

13

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

O

[0..*]

0010

00147

Admitting Doctor

0004
0007

ITEM#

ELEMENT NAME

00131

Set ID - PV1

00132

Patient Class

00133

Assigned Patient Location

00134

Admission Type__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

25

Copyright © 2017 IHE International, Inc.

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

LEN

DT
N

Usage

Card.

TBL#

ITEM#

18

2

IS

O

[0..1]

0018

00148

Patient Type

19

250

CX

C

[0..1]

00149

Visit Number

20

50

FC

O

[0..*]

0064

00150

Financial Class

21

2

IS

O

[0..1]

0032

00151

Charge Price Indicator

22

2

IS

O

[0..1]

0045

00152

Courtesy Code

23

2

IS

O

[0..1]

0046

00153

Credit Rating

24

2

IS

O

[0..*]

0044

00154

Contract Code

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

36

3

IS

O

[0..1]

0112

00166

Discharge Disposition

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

C

[0..1]

0326

01226

Visit Indicator

52

250

XC
N

X

[0..*]

0010

01274

Other Healthcare Provider

0021

0111

ELEMENT NAME__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

26

Copyright © 2017 IHE International, Inc.

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

General conditions of use:

715•

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” (NotApplicable).

•

The condition predicates described below only apply to the use of this segment in thecontext of transaction ITI-31.

PV1-2 – Patient Class (IS), required:
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 User-defined
Table 0004 - Patient Class for suggested values.
720

User-defined Table 0004: Patient Class
Value

Description

E

Emergency

I

InpatientO

OutpatientP

Preadmit

R

Recurring patient

B

Obstetrics

C

Commercial AccountN

Not ApplicableU

Unknown

Comment

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

Conditions of use:•

Transaction ITI-30 uses only the value “N” (Not Applicable) in all messages that containthe PV1 segment.

•

In transaction ITI-31

730•

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

27

Copyright © 2017 IHE International, Inc.

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

In all other messages of transaction ITI-31, it is required if known to the sender.

PV1-6 – Prior Patient Location (PL), conditional:
Condition predicate:

740

745

•

This field is required in the Transfer (A02)•

In all other messages of transaction ITI-31, it is optional.

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

750

Condition predicate: This field is used by the option “Temporary Patient Transfers Tracking” oftransaction ITI-31 (messages A09, A10, A32, A33).
PV1-19 – Visit Number (CX), Conditional. This fields contains the unique identifier assigned tothe encounter.

755

Condition predicate: 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.
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.
Condition predicate:760•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.
765

PV1-45 – Discharge Date / Time (TS), required if available. This field contains the date/time ofthe discharge (end of the encounter).
PV1-51 – Visit Indicator (IS), Conditional.
This field specifies the level on which data are being sent. It is the indicator used to send data at
two levels, visit and account. HL7 recommends sending an ‘A’ or no value when the data in the__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

28

Copyright © 2017 IHE International, Inc.

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

770

message are at the account level, or ‘V’ to indicate that the data sent in the message are at thevisit level.
Condition predicate: This field SHALL be valued with value “V” if the field PV1-19 “Visit
Number” is present. The field MAY be omitted otherwise.
3.30.5.5 MRG – Merge segment
Standard Reference: HL7 Version 2.5, Chapter 3 (Section 3.4.9)

775This 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

X

3

250

CX

4

250

5

TBL#

ITEM#

Element name[1..*]

00211

Prior Patient Identifier List

[0..0]

00212

Prior Alternate Patient ID

O[0..1]

00213

Prior Patient AccountNumberCX

X[0..0]

00214

Prior Patient ID

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

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)

785

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

LEN

DT

Usage

Card.

1

60

2

2

3

TBL
#

ITEM #ELEMENT NAME

EI

C

[0..1]

01206

Role Instance ID

ID

R[1..1]

0287

00816

Action Code

250

CE

R

[1..1]

0443

01197

Role-ROL

4

250

XCN

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

29

Copyright © 2017 IHE International, Inc.

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

LEN

DT

Usage

Card.

TBL
#

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

XAD

O

[0..*]

00679

Office/Home
Address/Birthplace

12

250

XTN

O

[0..*]

00678

Phone

0406

ITEM #ELEMENT NAME

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

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

795

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)

800

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.
Table 3.30-7: OBX Segment
SEQ

LEN

1

4

2

2

DT

Usage

Card.

SI

O

[0..1]

ID

C[1..1]

TBL#
0125

ITEM#

Element name00569

Set ID – OBX

00570

Value Type__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

30

Copyright © 2017 IHE International, Inc.

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

LEN

3

250

4

DT

Usage

Card.

TBL#

CE

R

[1..1]

00571

Observation Identifier

20

ST

C

[0..1]

00572

Observation Sub-ID

5

99999

VariesC[1..1]

00573

Observation Value

6

250

CE

O

[0..1]

00574

Units

7

60

ST

O

[0..1]

00575

References Range

8

5

IS

O

[0..1]

00576

Abnormal Flags

9

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

0078

ITEM#

Element name

OBX-2 Value Type (ID), conditional.
This field contains the type of observation.
805

Example: “NM” for a numeric observation such as patient weight or patient height.
Condition predicate: This field SHALL be valued if OBX-5 “Observation Value” is present. It
MAY be valued otherwise.
OBX-3 Observation Identifier (CE), required

810

The usage of LOINC vocabulary is strongly recommended. Details of this free vocabulary can befound 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” in the caseof LOINC is “LN”. Example of the code used with the patient weight:
3142-7^BODY WEIGHT (STATED)^LN

815
OBX-4 Observation Sub-ID (CE), conditional
This field is used to distinguish between multiple OBX segments with the same observation ID.

820

Condition predicate: When field OBX-3 “Observation Identifier” has an identical value in two or
more OBX segments of the message, field OBX-4 “Observation Sub-ID” SHALL be populatedwith a distinct value in each of these OBX segments.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

31

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
OBX-5 Observation Value (Varies), conditional.
This field contains the value of the observation itself.

825

Condition predicate: This field SHALL be valued if OBX-11 “Observation Result Status” hasanother value than “X”, “D”, “N” or “I” and if OBX-8 “Abnormal Flags” is empty. In all othercases this field MAY be valued.
OBX-11 Observation Result Status (ID), required.
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:

830

OBX|1|NM|3142-7^BODY WEIGHT (STATED)^LN||62|kg|||||F
OBX|2|NM|8303-0^BODY HEIGHT^LN||1.70|m|||||F

3.30.5.8 AL1 – Patient Allergy Information segment
Standard Reference: HL7 Version 2.5, Chapter 3, Section 3.4.6
835

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

840

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

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. 14.0 Final Text – 2017-07-21

32

Copyright © 2017 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

3.30.6.2 Create New Patient - ADT^A28^ADT_A05
850

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

Message Static Definition

855

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. 14.0 Final Text – 2017-07-21

33

Copyright © 2017 IHE International, Inc.

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

Meaning

Usage

Card.

HL7 chapter

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

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
6

DRG

Diagnosis Related GroupO[0..1]------ 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

3.30.6.2.3

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”.
860

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.
The ROL segment following the PV1/PV2 segments is not supported here, for the same reason.

865

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. 14.0 Final Text – 2017-07-21

34

Copyright © 2017 IHE International, Inc.

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

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

875

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

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

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

ROL

Role

O

[0..*]

15------ INSURANCE end__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

35

Copyright © 2017 IHE International, Inc.

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

Usage

Card.

HL7 chapter

ACC

Accident InformationO[0..1]

6

UB1

Universal Bill InformationO[0..1]

6

UB2

Universal Bill 92 InformationO[0..1]

6

3.30.6.3.3
880

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

885

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.
The ROL segment following the PV1/PV2 segments is not supported here, for the same reason.

890

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

895

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 Merge two patients - ADT^A40^ADT_A39
This message is to be supported with the “Merge” Option of transaction ITI-30.

900

3.30.6.4.1

Trigger Event

905

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

Message Static Definition__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

36

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.30-11: Static definition of ADT^A40^ADT_A39
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]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3

PV1

Patient Visit

X[0..0]

3

---

910

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.

915

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

920

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.
If the receiver does not recognize the supplier patient identifiers to be merged, it shall take noaction. This situation is not an error.

925

If the receiver does not support the Merge Option of this transaction, it shall application-reject
the message (see ITI TF-2x: C.2.3).
3.30.6.5 Change Patient Identifier List - ADT^A47^ADT_A30
3.30.6.5.1

930

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.
This message is not used to update other patient demographics information. The A31 trigger
event should be used for this purpose.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

37

Copyright © 2017 IHE International, Inc.

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

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]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3---

3.30.6.5.3

940

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

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
This message is to be supported with the “Link/Unlink” Option of transaction ITI-30.

950

3.30.6.6.1

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

This message is not used to update other patient demographics information. The A31 trigger
event should be used for that purpose.
MSH-9 is valued to ADT^A24^ADT_A24.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

38

Copyright © 2017 IHE International, Inc.

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

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

Segment

960

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

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).
965

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

970

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.

975

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

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).
980

MSH-9 is valued ADT^A37^ADT_A37.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

39

Copyright © 2017 IHE International, Inc.

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

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

Segment

985

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

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

990

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…).
In case the receiver did not recognize the link between these two patient identifier lists, no action
is performed and no error condition exists.

995

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

40

Copyright © 2017 IHE International, Inc.

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

3.31 Patient Encounter Management [ITI-31]
1000

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.
3.31.1 Scope

1005

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.

1010

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
Consumer

Patient
Encounter Source

Patient Encounter
Management

Actor: Patient Encounter Supplier1015

Role: Sends inserts, cancels and updates of patient encounters and movements.
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, 151020

3.31.4 Definition of the concept “Movement”
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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

41

Copyright © 2017 IHE International, Inc.

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

1025

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. Thisaction is possible only with the option “Historic Movement Management” of transaction
ITI-30.

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

1030

1035

1040

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

1045

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:

1050
A04
Emergency &attending
doctor U

A06

A02
Location BB& attending
doctor X

A03
Location GG& attending
doctor X__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

42

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.5 Message sets and options

1055

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 event1060

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

ADT^A03^ADT_A03

cancelA11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

The 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, shallsupport these 5 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

Figure 3.31-1: Interaction Diagram for the Basic Subset

1065

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:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

43

Copyright © 2017 IHE International, Inc.

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

Table 3.31-2: Message Subset for Inpatient/outpatient Encounter Management Option
Trigger / Action

Category of event

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

Pre-admit patient

cancelA11

ADT^A11^ADT_A09

ADT^A03^ADT_A03

A13

ADT^A13^ADT_A01

A05

ADT^A05^ADT_A05

A38

ADT^A38^ADT_A38

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

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

Patient Encounter
Supplier

1075

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”
Option__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

44

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.5.3 Pending Event Management Option
1080

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:
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

A11

ADT^A11^ADT_A09

ADT^A03^ADT_A03

A13

ADT^A13^ADT_A01

A38

ADT^A38^ADT_A38

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 17 trigger events and messages.
1085

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

1090

1095

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

45

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
1100
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
1105This 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 event1110

insertAdmit inpatientA01

ADT^A01^ADT_A01

Register outpatient

A04

ADT^A04^ADT_A01

Discharge patient

A03

Change attending doctor

A54

cancelA11

ADT^A11^ADT_A09

ADT^A03^ADT_A03

A13

ADT^A13^ADT_A01

ADT^A54^ADT_A54

A55

ADT^A55^ADT_A52

Leave of absence

A21

ADT^A21^ADT_A21

A52

ADT^A52^ADT_A52

Return from leave of absence

A22

ADT^A22^ADT_A21

A53

ADT^A53^ADT_A52

Move account information

A44

ADT^A44^ADT_A43

A system implementing this option shall support these 12 trigger events and messages.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

46

Copyright © 2017 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

1115

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:1120

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

Discharge patient

A03

Patient departing - Tracking
Patient arriving - Tracking

A11

ADT^A11^ADT_A09

ADT^A03^ADT_A03

A13

ADT^A13^ADT_A01

A09

ADT^A09^ADT_A09

A33

ADT^A33^ADT_A21

A10

ADT^A10^ADT_A09

A32

ADT^A32^ADT_A21__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

47

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
A system implementing this option shall support these 9 trigger events and messages.
Figure 3.31-5 below depicts the messages added by this option to the basic subset.

Patient Encounter
Source1125

Patient 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

3.31.5.6 Historic Movement Management
This option adds the capability to cancel or update safely any Movement.
1130

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

1135

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:

1140

•

It enables unique identification of the Movement (including admission and discharge).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

48

Copyright © 2017 IHE International, Inc.

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

1145

1150

1155

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.

•

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 Section 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 isabout 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.

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).
1160

Implementation note: The Patient Encounter Consumer must support transaction log update tomaintain integrity of the Movement records.
3.31.5.7 Acknowledgement Support

1165

An actor that claims support for the Acknowledgement Support Option shall be capable of using
the enhanced acknowledgement mode as defined in the HL7 v2.x standard. See HL7 Volume 2C,
Section C.2.3 for further details.
3.31.5.8 Ambulatory Patient Data
If the Patient Encounter Supplier supports the Ambulatory Patient Data Option, it SHALL
supply:the patient address in field PID-11 for ambulatory patients whenever this address is known

1170

the referring doctor in field PV1-8, if known, when registering an outpatient (MSH-9 Message
Type is ADT^A04) or when pre-registering a patient (MSH-9 Message Type is ADT^A05)
the ambulatory status of the patient into field PV1-15 if this information is known.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

49

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.5.9 Maintain Demographics Option
1175

This option adds support to manage “Update patient information” and “Merge patient identifierlist” in the context of an encounter.
The following is the required message set to support the “Maintain Demographics Option”:
Trigger / Action

Category of event1180

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
list

A40

ADT^A40^ADT_A39

cancelA11

ADT^A11^ADT_A09

A13

ADT^A13^ADT_A01

A Patient Encounter Supplier or Patient Encounter Consumer supporting the Maintain
Demographics Option shall support these 7 trigger events and messages.
Figure 3.31-6 depicts the messages added by this option to the basic subset.

Figure 3.31-6: Additional Interactions for “Maintain Demographics” Option

1185

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

1190

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

50

Copyright © 2017 IHE International, Inc.

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

1195

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.

1200

Table 3.31-6: ZBE segment description
SEQ

LEN

DT

Usage

Card.

ELEMENT NAME

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)

5

ID

R

[1..1]

Historical Movement Indicator (values: Y / N)

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

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.
ZBE-4 – Action (ID): Required. Three possible values:

1210

•

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:
1215•‘Y’ when the message is related to a Historic Movement.

•‘N’ when the message is related to the current (last or next) movement.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

51

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.
1220

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

1225

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.
3.31.7.1 Admit/Visit Notification (ADT^A01^ADT_A01)
3.31.7.1.1

1230

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

1235

Message Static Definition
Table 3.31-7: Static definition of message ADT^A01^ADT_A01
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

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

52

Copyright © 2017 IHE International, Inc.

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

1240

Meaning

Usage

Card.

HL7 chapter
6

DRG

Diagnosis Related GroupO[0..1]------ 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.1.3

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

1245

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.

1250

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

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

53

Copyright © 2017 IHE International, Inc.

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

trigger event A01) or registered for an outpatient visit (via trigger event A04). See Section
3.31.5.8 for the message to be used to cancel a pre-admit notification, and Section 3.31.5.14 forthe message to be used to cancel a pending admit notification.
MSH-9 is valued ADT^A11^ADT_A09.
3.31.7.2.2

1260

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

3.31.7.2.3

Comments on segment usageNone.
3.31.7.2.4
1265

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.

1270

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

1275

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

54

Copyright © 2017 IHE International, Inc.

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

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

Segment

1280

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

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]

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.
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

55

Copyright © 2017 IHE International, Inc.

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

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

1290

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.

1295

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

1300

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

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..*]__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

56

Copyright © 2017 IHE International, Inc.

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

1305

Meaning

Usage

Card.

HL7 chapter

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

O[0..*]

15

ROL

Role

---

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

1310

1315

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.
Within a Patient Discharge message, if the encounter has been terminated by the patient's death,then the field PID-30 Patient Death Indicator shall be populated. In this case PID-29 Patient
Death Date and Time shall be populated as well, provided that the value is known.
3.31.7.4.4

Expected actions

The receiver shall update the patient’s status to “discharged” (or “visit ended”).
1320

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 inpatient nor
outpatient visit opened for this patient) the message is discarded but no error condition is raised.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

57

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.5 Cancel Discharge/End Visit – ADT^A13^ADT_A01
3.31.7.5.1
1325

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

1330

Message Static Definition
Table 3.31-11: Static definition of message ADT^A13^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

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. 14.0 Final Text – 2017-07-21

58

Copyright © 2017 IHE International, Inc.

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

Meaning

PDA

Patient Death and Autopsy

3.31.7.5.3

Comments on segment usage

Usage

Card.

HL7 chapterO[0..1]

3

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

3.31.7.5.4

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

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

1345

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

1350

Message Static Definition
Table 3.31-12: Static definition of message ADT^A08^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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

59

Copyright © 2017 IHE International, Inc.

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

Usage

Card.

HL7 chapter

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

1355

Meaning

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

1360

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.

1365

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

60

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.7 Pre-Admit (ADT^A05^ADT_A05)
3.31.7.7.1

1370

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).
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]

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. 14.0 Final Text – 2017-07-21

61

Copyright © 2017 IHE International, Inc.

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

1375

1380

Meaning

PDA

Patient Death and Autopsy

3.31.7.7.3

Comments on segment usage

Usage

Card.

HL7 chapterO[0..1]

3

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

1385

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.

1390

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.8 Cancel Pre-Admit – ADT^A38^ADT_A38
3.31.7.8.1

1395

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

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. 14.0 Final Text – 2017-07-21

62

Copyright © 2017 IHE International, Inc.

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

1400

Meaning

Usage

Card.

HL7 chapter

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

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.

1410

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.9 Change Outpatient to Inpatient (ADT^A06^ADT_A06)
3.31.7.9.1

1415

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

63

Copyright © 2017 IHE International, Inc.

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

1420

Meaning

Usage

Card.

HL7 chapter

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

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

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:
1425

1430

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.
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

64

Copyright © 2017 IHE International, Inc.

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

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

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.

1445

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

1450

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.
3.31.7.10.2 Message Static Definition

1455

Table 3.31-16: Static definition of message ADT^A07^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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

65

Copyright © 2017 IHE International, Inc.

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

Meaning

Usage

Card.

HL7 chapter

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
6

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

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:
1460

1465

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

1470

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

66

Copyright © 2017 IHE International, Inc.

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

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.

1480

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

1485

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 be reflectedin the institution’s bed census.
1490

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

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

PDA

Patient Death and AutopsyO[0..1]

3__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

67

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.11.3 Comments on segment usage
1495

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.

1500

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.

1505

1510

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
1515

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.
3.31.7.12.2 Message Static Definition

1520

Table 3.31-18: Static definition of message ADT^A12^ADT_A12
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. 14.0 Final Text – 2017-07-21

68

Copyright © 2017 IHE International, Inc.

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

Meaning

Usage

Card.

HL7 chapter

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
1525

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.

1530

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
1535

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

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

69

Copyright © 2017 IHE International, Inc.

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

1540

Meaning

Usage

Card.

HL7 chapter

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

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

O[0..1]

6

ROL

Role

---

--- INSURANCE end

ACC

Accident Information

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.

1545

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.

1550

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
shall application-reject the message (see ITI TF-2x: C.2.3).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

70

Copyright © 2017 IHE International, Inc.

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

Cancel Pending Admit – ADT^A27^ADT_A21

3.31.7.14.1 Trigger Event
1555

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

1560

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

1565

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.

1570

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
shall application-reject the message (see ITI TF-2x: C.2.3).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

71

Copyright © 2017 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
1575

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

1580

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 communicatedin ROL segments immediately following the PV1/PV2 segments.

1585

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 Section
3.30.5.2.

1590

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. 14.0 Final Text – 2017-07-21

72

Copyright © 2017 IHE International, Inc.

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

1595

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
shall application-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
1600

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

1605

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.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 Section 3.30.5.2.

1610

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.

1615

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. 14.0 Final Text – 2017-07-21

73

Copyright © 2017 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
shall application-reject the message (see ITI TF-2x: C.2.3).
1620

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

3.31.7.17.2 Message Static Definition
Table 3.31-23: Static definition of message ADT^A16^ADT_A16
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

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

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

O[0..1]

6

ROL

Role

---

--- INSURANCE end

ACC

Accident Information__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

74

Copyright © 2017 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.
1630

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

1635

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
shall application-reject the message (see ITI TF-2x: C.2.3).

1640

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

3.31.7.18.2 Message Static Definition
Table 3.31-24: Static definition of message ADT^A25^ADT_A21
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

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. 14.0 Final Text – 2017-07-21

75

Copyright © 2017 IHE International, Inc.

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

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.

1655

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
shall application-reject the message (see ITI TF-2x: C.2.3).

1660

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

3.31.7.19.2 Message Static Definition
Table 3.31-25: Static definition of message ADT^A54^ADT_A54
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

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

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 communicatedin 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. 14.0 Final Text – 2017-07-21

76

Copyright © 2017 IHE International, Inc.

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

1675

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.

1680

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

1685

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

1690

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
1695

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. 14.0 Final Text – 2017-07-21

77

Copyright © 2017 IHE International, Inc.

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

1700

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

1705

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

1710

Table 3.31-27: Static definition of message ADT^A21^ADT_A21
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

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

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.

1720

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. 14.0 Final Text – 2017-07-21

78

Copyright © 2017 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).
1725

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

3.31.7.22.2 Message Static Definition
Table 3.31-28: Static definition of message ADT^A52^ADT_A52
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

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

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.

1740

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

79

Copyright © 2017 IHE International, Inc.

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

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.
MSH-9 is valued ADT^A22^ADT_A21.
3.31.7.23.2 Message Static Definition

1750

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

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.

1760

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.

1765

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

80

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.31.7.24
Cancel Patient Return from a Leave of Absence –ADT^A53^ADT_A52
3.31.7.24.1 Trigger Event
1770

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.
3.31.7.24.2 Message Static Definition
Table 3.31-30: Static definition of message ADT^A53^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.24.3 Comments on segment usage
1775

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
The receiver shall cancel the patient’s return from leave of absence.

1780

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 return from leave ofabsence previously notified, or no active encounter, or patient unknown) the message isdiscarded, but no error condition is raised.

1785

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
1790

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

81

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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
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..*]

PID

Patient IdentificationR[1..1]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3------ PATIENT end

3.31.7.25.3 Comments on segment usage
1795

None.
3.31.7.25.4 Expected actions
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.

1800

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.

1805

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
This message is only used within the context of the “Temporary Patient Transfers Tracking”
Option.
1810

1815

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

82

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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

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

3.31.7.26.3 Comments on segment usage
1820

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

1825

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.

1830

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.26.4 Expected actions

1835

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.

1840

In case this message conflicts with the current situation, the message is discarded but no error
condition is raised.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

83

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.27

Cancel Patient Departing – Tracking – ADT^A33^ADT_A21

3.31.7.27.1 Trigger Event
1845

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.
MSH-9 is valued ADT^A33^ADT_A21.

1850

3.31.7.27.2 Message Static Definition
Table 3.31-33: Static definition of message ADT^A33^ADT_A21
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

3.31.7.27.3 Comments on segment usage

1855

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.
3.31.7.27.4 Expected actions

1860

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

84

Copyright © 2017 IHE International, Inc.

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

1865

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

Patient Arriving – Tracking – ADT^A10^ADT_A09

3.31.7.28.1 Trigger Event
1870

1875

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

1880

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

1885

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

85

Copyright © 2017 IHE International, Inc.

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

1890

One or more OBX segments may be present to carry “permanent observations” such as thepatient weight or height.
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.

1895

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

1900

3.31.7.29

Cancel Patient Arriving – Tracking – ADT^A32^ADT_A21

3.31.7.29.1 Trigger Event

1905

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

3.31.7.29.3 Comments on segment usage
1910

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

86

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Location may contain (if known) the original patient location prior to the erroneous A10 (patient
arriving-tracking) event.
1915

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

1920

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.

1925

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

Update Patient Movement Information – ADT^Z99^ADT_A01

3.31.7.30.1 Trigger Event
1930

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.
3.31.7.30.2 Message Static Definition

1935

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

87

Copyright © 2017 IHE International, Inc.

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

Meaning

Usage

Card.

HL7 chapter

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
6

GT1

Guarantor

O[0..*]------ 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

6

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.30.3 Comments on segment usage
The ZBE segment is mandatory in this message. See the description of this segment in Section
3.31.6.1.
3.31.7.30.4 Expected actions
1940

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.

1945

A receiver not supporting the Historic Movement Management Option shall application-reject
the message (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

1950

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

88

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
MSH-9 is valued ADT^A40^ADT_A39.
3.31.7.31.2 Message Static Definition
Table 3.31-37: Static definition of message ADT^Z40^ADT_A39
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]

3

PD1

Additional Demographics

O[0..1]

3

MRG

Merge InformationR[1..1]

3

PV1

Patient Visit

X[0..0]

3

---

1955

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.

1960

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.31.7.31.4 Expected actions

1965

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.
If the receiver does not recognize the supplier patient identifiers to be merged, it shall take noaction. This situation is not an error.

1970

3.32 Distribute Document Set on Media [ITI-32]
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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

89

Copyright © 2017 IHE International, Inc.

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

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.
3.32.2 Use Case Roles
Portable MediaCreatorPortable Media
Importer

DistributeDocument Set on
Media

1980

Actor: Portable Media Creator
Role: Assemble the media content and store it on the media to be distributed.
Actor: Portable Media Importer
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.

1985

3.32.3 Referenced Standard
ITI TF-3: 4 Metadata used in Document Sharing profiles
DICOM PS 3.10 Media Storage and File Format for Data Interchange (DICOM file format).
http://dicom.nema.org/

1990

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.

1995

XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtmbasic.
MDN: RFC3798 Message Disposition Notification. http://www.rfc-editor.org/rfc/rfc3798.txt__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

90

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.32.4 Interaction Diagram
PortableMedia
CreatorPortable
Media
Importer
Distribute Document
Set on Media

2000

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.

2005

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
restricted subset 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
to comply with the interoperability restrictions on recording format. This media
specification relies on the healthcare experience gained by CD-R media widely used inradiology and cardiology. It is defined by Annex F in Part 12 of the DICOM standard andis 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 thedirectory and 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 tothe email message header to facilitate recognizing the message. This specification isdefined in the annexes to part 12 of the DICOM standard called: ZIP File Media andEmail media. The ZIP over Email Response Option enables the Portable Media Importerto send an acknowledgment message to the Portable Media Importer.

2010

2015

2020

2025

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

91

Copyright © 2017 IHE International, Inc.

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

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

2035

2040

The message semantics of this transaction are described in terms of content specifications for the
media.
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
The following restrictions are needed to ensure broad interoperability:

2045

2050

•

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 meansno packet 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
characters with no extension. Specifically, it is not permitted to name DICOM files basedon their SOP Instance UID, since that would exceed the 8 character limit and use theillegal period character, and it is not permitted to add a “.dcm” extension or similar.

Note:

2055

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

92

Copyright © 2017 IHE International, Inc.

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

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

The media shall contain at the “root” directory level, as shown in the figure above:
2060

2065

•

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 Portable Data for Imaging (PDI) Profile). The presence or absence of thesefiles shall not affect performance of this transaction.

XDS Metadata
Other file ignored by the metadata
Simple part document
Multi part document

2070

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:•
2075

A METADATA.XML file containing the XDS Registry metadata, as described in ITI TF3: 4.3.1.2.2. This shall include the metadata as specified in ITI TF-3: Table 4.3.1-3
Metadata Attribute Optionality. This may include XDSFolder objects, associations, andother 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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

93

Copyright © 2017 IHE International, Inc.

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

2080

2085

•

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.2.3.2-1, 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)2090

Figure 3.32.4.1-3: Structure on the media of a directory which is functionally equivalent to“XDS multipart document”

2095

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.

2100

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 ITI TF-3: Table 4.1-5, URI attribute for details):<ExtrinsicObject id="Document1" mimeType="text/xml"... (with URI set to “DOC00001.XML”)<ExtrinsicObject id="Document2" mimeType="text/xml"... (with URI set to “DOC00002/DOC00002.XML”)

2105

2110

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:

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.
There shall also be a README.TXT file located in the root directory that shall contain:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

94

Copyright © 2017 IHE International, Inc.

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

2115

•

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)

2120

2125

2130

•

•

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.

2135

2140

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 createdthe interchange media•

a link to an entry point for accessing the web content of the IHE_PDI directory•a link to the README.TXT file•a link to additional non-constrained data (if it exists)•a manifest which lists the data that can be imported by a Portable Media Importer (i.e., all
DICOM content on the media)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

95

Copyright © 2017 IHE International, Inc.

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

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 equivalent on 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
2150

2155

2160

If the ZIP over Email Response Option is supported and a response was requested, the Portable
Media Importer shall send a response, based on the [MDN] mechanism, depending of the successof 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 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.

2165

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

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.
If the ZIP over Email Option is supported, the subject line of the email shall contain the phrase:
2175•

XDM/1.0/DDM
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

96

Copyright © 2017 IHE International, Inc.

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

2185

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.

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

2195

2200

2205

2210

1. The Portable Media Creator 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 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 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 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 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 shall have the ability to coerce the confidentiality code in
the metadata associated with the document from the codes used by the Exporter to thecodes used by the Importer.

2215

The Portable Media Importer shall abide by the XDS Affinity Domain Policies represented by
the confidentialityCode in the metadata associated with the document. The Portable MediaCreator likely will have user access controls or business rule capabilities to determine the details__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

97

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
of how confidentiality codes apply to query results. The details of this are product specific andnot 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.
2220

2225

2230

3.32.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.
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.32.5.1 Audit Record Considerations
The Distribute Document Set on Media Transaction is a PHI-Export for the Portable MediaCreator and a PHI-Import for the Portable Media Importer as defined in ITI TF-2a: Table
3.20.4.1.1.1-1.

2235

3.32.5.1.1 Portable Media Creator Audit Message
The audit message for a Portable Media Creator shall comply with the specifications in Section
3.41.5.1, with the following exceptions.
1. Event / EventTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document
Set on Media").

2240

2. Source / UserID is not specialized.
3. Destination / UserID is not specialized.
4. Destination / MediaIdentifier is required.
5. Destination / MediaIdentifier / MediaType is required. The value shall be taken from CID
405, in DICOM PS 3.16.

2245

6. SubmissionSet / ParticipantObjectIDTypeCode shall be ("ITI-32", "IHE Transactions","Distribute Document Set on Media").
3.32.5.1.2 Portable Media Importer Audit Message
The audit message for a Portable Media Importer shall comply with the specifications in Section
3.41.5.2, with the following exceptions.

2250

1. Event / EventTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document
Set on Media").
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

98

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
2. Source / UserID is not specialized.
3. Source / MediaIdentifier is required.
2255

4. Source / MediaIdentifier / MediaType is required. The value shall be taken from CID
405, in DICOM PS 3.16.
5. Destination / UserID is not specialized.
6. SubmissionSet / ParticipantObjectIDTypeCode shall be ("ITI-32", "IHE Transactions","Distribute Document Set on Media").

2260

3.33 Intentionally Left Blank__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

99

Copyright © 2017 IHE International, Inc.

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

3.34 Retrieve Form [ITI-34]
2265

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 or Form Processor
Actors.
3.34.1 Scope

2270

This transaction involves a Form Filler requesting a form from a Form Manager or Form
Processor. 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 or Form
Processor will return a form or URL corresponding to the given formID, and optionally a form
instance id, or else it returns an error response. Forms are defined and constrained below by theformat options.
3.34.2 Use Case Roles
Form Filler

Form Manager

Form Processor

Retrieve Form

2275
Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form Manager
2280

Role: A system that provides forms based upon requests that provide specific formIDs, andoptionally additional work flow data. . Form data is submitted to a Form Receiver.
Actor: Form Processor
Role: A system that provides forms based upon requests that provide specific formIDs, andoptionally additional work flow data. Form data from this actor shall be submitted back to itself.
3.34.3 Referenced Standards

2285

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
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

100

Copyright © 2017 IHE International, Inc.

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

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/

2295

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.
http://www.w3.org/TR/xhtml-basic

2300
3.34.4 Interaction Diagram
Form Manager orForm Processor

Form Filler

Retrieve Form
RequestRetrieve Form
Response

3.34.4.1 Retrieve Form Request
2305

Retrieve Form involves a Form Filler requesting a form from a Form Manager or Form
Processor. 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. See Section 3.34.4.1.2 for details.

2310

The Form Filler requests that Form Filler or Form Processor use context information in theselection and/or creation of the returned form by supplying the prepopData argument with wellformed xml representing the Form Filler context. Specification of the prepopData schema is left
to content profiles. This value may be nil.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

101

Copyright © 2017 IHE International, Inc.

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

2315

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

2320

The Form Filler, based upon human decision or application of a rule for automatic operation,
requests a form hosted by a Form Manager or Form Processor.
3.34.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 thistransaction.

2325
Parameter Name

REQ

Description

prepopDataR

The xml context
information supplied by aForm 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}O

An XML attribute ofencodedResponse which
specifies the type of
expected encoded response

A string whose value is defined bycontent profiles.
Shall not be specified when the valueof encodedResponse is “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 the null string

context

R

The xml specifics ofworkflow context

Defined by content profiles; may benilinstanceIDR

An id value of a previously
submitted instance of data.

A string identifying an instance ofpreviously submitted data; may be nil.

responseContentType

Value

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).
The content of workflowData parameter shall minimally be:
2330__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

102

Copyright © 2017 IHE International, Inc.

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

2335

2340

2345

2350

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

The responseContentType attribute may be specified only when the value of theencodedResponse parameter is “true”. The value for responseContentType attribute specifies theencoding of the response from the Form Manager or Form Processor. Acceptable values aredefined by content profiles. An example of its use is to specify whether the expected response isan XML form definition or an XHTML form. Below is an example of its use:
<workflowData><formID>a String identifying the form</formID><encodedResponse>false</encodedResponse><archiveURL /><context/><instanceID/></workflowData>

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

3.34.4.1.3 Expected Actions

2360

Upon receipt of the Retrieve Form request, the Form Manager or Form Processor shall parse therequest and shall return 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 or Form Processor shallbe either a Structured (XML) or Unstructured (non-XML) element. When the encodedResponse
parameter is 'true', all anchor addresses that are not fragment identifiers shall be composed ofabsolute URIs.

2365

2370

If the responseContentType attribute is specified, then the response from the Form Manager orForm Processor shall be a Structured element with appropriate content type, for example, XML
form definition or an XHTML form. The Form Manager or Form Processor shall not throw anerror if it receives the optional responseContentType attribute.
If encodedResponse is ‘false’, then the response from the Form Manager or Form Processor shallbe a URL element that can be used directly by a web browser for retrieval and operation of theform.
The Form Manager or Form Processor may assign and return a value for a form instanceID.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

103

Copyright © 2017 IHE International, Inc.

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

2375

2380

When the Form Filler provides a valid URL in the archiveURL parameter of the request, theForm Manager or Form Processor shall return a form that shall perform an Archive Formtransaction upon form submission, in addition to any predefined actions associated with the form
submission. As shown in Section 3.36 Archive Form, this additional archival transaction is
between Form Filler and Form Archiver Actors.
When the Form Filler supplies data in the prepopData parameter, the Form Manager or Form
Processor may use this information to determine the form to be returned and to pre-populate thefields of the form. The exact use of the prepopData, and the structure, is deferred to the
publication of an IHE content profile.
The Form Manager or Form Processor shall use the values within the workflowData parameter,
as well as the optionally supplied instanceID, to determine the form to be returned and to prepopulate the fields of the form.

2385

2390

The value of the formID has been previously assigned by the Form Manager or Form Processor
to identify a form to be returned to the Form Filler using one of the named format options. A
Form Manager or Form Processor may support multiple named options, but for each formID
there is only one named option that is supported.
The Form Manager or Form Processor 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: SOAP Faults
Description of error

2395

2400

2405

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. 14.0 Final Text – 2017-07-21

104

Copyright © 2017 IHE International, Inc.

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

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 require use of ATNA.
3.34.4.2 Retrieve Form Response
3.34.4.2.1 Trigger Events

2415

This message is triggered by a Form Manager or Form Processor responding to a Retrieve Formrequest.
3.34.4.2.2 Message Semantics
The form or URL is returned.
The following parameters are specified for the response of this transaction:
Element Name

REQ

Description

Constraints

form

R

The xml element container for theform. The form element Shallcontain one of: {Structured,
Unstructured, URL} and may also
contain an instanceID.

An element of typeurn:ihe:iti:rfd:2007:formDataType, thus it has only child elements
and no value.

form/Structured

O [Note 1]

The xml element container for the
return of encoded, structured form
content.

xs:anyThe xml element container for the
return of encoded, unstructured,base64 encoded form content.

xs:base64Binary

form/Unstructured

O [Note 1]

This element may be further
constrained by content profiles.
May only be present when theForm Request has
encodedResponse value of true.

This element may be further
constrained by content profiles.
May only be present when theForm Request has
encodedResponse value of true.

form/URL

O [Note 2]

The xml element container for the
return of a pointer to the form.

xs:anyURI
Required when the Form Request
has encodedResponse value offalse.

form/instanceIDO

The xml element containing thevalue of a form instance

xs:string

contentTypeR

Has no meaning when the Form
Request encodedResponse value isfalse.

xs:string
Required; may be nil.
The value may be constrained bycontent profiles.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

105

Copyright © 2017 IHE International, Inc.

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

2420

REQ

Description

R

Constraints

Not defined.

xs:string
Required; may be nil
The value may be constrained bycontent profiles.

Note 1: When the Form Request has encodedResponse value of true, then one of the two fields is required, and the URL
field is forbidden.
Note 2: When the Form Request has encodedResponse value of false, then the URL field is required, and Structured andUnstructured are forbidden.

3.34.4.2.3 Expected Actions
2425

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

2430

2435

A Form Manager or Form Processor shall return a form. If the form is returned as a URL,
because encodedResponse is false on the request, the form shall be formatted as XHTML using
XHTML Basic and W3C HTML Compatibility Guidelines provided in the Appendix C of the
W3C XHTML 1.0 Recommendation. If the form is returned as Structured content, it shall becapable of being transformed into XHTML. In all cases, the returned form shall support theSubmit and all required Archive transactions.
3.34.4.2.3.2 XForm Option

2440

A Form Manager or Form Processor that supports the XForms Option shall additionally becapable of returning a form, 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 Basicaccording 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

2445

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 1.2.
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

106

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
These are the requirements for the Retrieve Form transaction presented in the order in which
they would appear in the WSDL definition:
2450•

The following types shall be imported (xds:import) in the /definitions/types section:
•

2455

2460

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/@soapActionRequired attributeshall be defined as “false”

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 Section 3.34.5.1 Sample SOAP Messages.
2465

An informative WSDL for the Form Manager and a full XML Schema Document for the RFD
types is available online on the IHE FTP site. See ITI TF-2x: Appendix W.
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/>,

2470<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

2475

2480

2485

<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:RetrieveForm</wsa:Action></soap:Header><soap:Body><RetrieveFormRequest xmlns="urn:ihe:iti:rfd:2007"><prepopData>...some xml content...</prepopdata><workflowData>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

107

Copyright © 2017 IHE International, Inc.

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

2490

2495

<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
2500

2505

2510

2515

2520

<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: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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

108

Copyright © 2017 IHE International, Inc.

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

3.35 Submit Form [ITI-35]
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 or Form Processor
Actors.
2525

3.35.1 Scope
This transaction involves a Form Filler submitting a form to a Form Receiver or Form Processor.
3.35.2 Use Case Roles
Form Filler

Form ReceiverForm Processor

Submit Form

2530
Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
Actor: Form Receiver2535

Role: A system that receives submitted form data from forms constructed by Form Managers.
Actor: Form Processor
Role: A system that receives submitted form data from forms constructed by this same instanceof the Form Processor.
3.35.3 Referenced Standards

2540

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
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1

2545

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

109

Copyright © 2017 IHE International, Inc.

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

Form Filler

Submit Form [ITI-35]

Ack/Nak response

2550
3.35.4.1 Submit Form
This transaction is initiated by a Form Filler submitting form instance data, using XML as aformat, to a Form Receiver or Form Processor.
3.35.4.1.1 Trigger Events
2555

The Submit Form transaction is triggered by the submission action from within the form.
3.35.4.1.2 Message Semantics
The Submit Form transaction shall carry a SubmitFormRequest element, with submitted form
data as XML child elements of the SubmitFormRequest element. Content profiles may further
constrain the content of the SubmitFormRequest element.

2560

See the schema provided with the support materials (see ITI TF-2x: Appendix W).
3.35.4.1.3 Expected Actions
Upon receipt of the Submit Form request, the Form Receiver or Form Processor shall return a
SubmitFormResponse element, or errors with SOAP Faults, for example if the posted datacannot be recognized.

2565

The Form Filler may display the results of the response from the Form Receiver or Form
Processor.
The Form Receiver or Form Processor shall use the SOAP Faults defined in Table 3.35.4.1.3-1
when appropriate. Form Fillers shall be capable of accepting other values beyond the ones
specified here.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

110

Copyright © 2017 IHE International, Inc.

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

Table 3.35.4.1.3-1: SOAP Faults
Description of error

CodeCannot recognize the posted data

SenderReason Text
Required Information Missing

An example of a SOAP Fault is:

2575

2580

2585

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

3.35.4.2 Submit Form Response
3.35.4.2.1 Trigger Events
This message is triggered by a Form Filler submitting form instance data.
3.34.4.2.2 Message Semantics
2590

2595

The Submit Form Response shall return a SubmitFormResponseType element containing:•

A responseCode string that may be constrained by Content Profiles•

An optional content element containing formData, as is returned byRetrieveFormResponse•

An optional contentType string that may be constrained by Content Profiles.

See the schema provided with the support materials (see ITI TF-2x: Appendix W).
3.35.4.2.3 Expected Actions
The Form Filler may display the results of the response from the Form Receiver or Form
Processor. The form behavior may be further profiled by content domain profiles.
3.35.5 Protocol Requirements

2600

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
The Submit Form transaction shall use SOAP 1.2.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

111

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________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

2605
These are the requirements for the Submit Form transaction presented in the order in which theywould appear in the RFD Submit Form WSDL definition:•

The following types shall be imported (xds:import) in the /definitions/types section:•

2610

Namespace=”urn:ihe:iti:rfd:2007”, schema=”RFD.xsd”•

The /definitions/message/part/@element attribute of the Submit Form Request message
shall be defined as: “ihe:SubmitFormRequest”•

The /definitions/message/part/@element attribute of the Submit Form Response message
shall be defined as: “ihe:SubmitFormResponse”•

Refer to Table 3.35.5-1 for additional attribute requirements.

2615

Table 3.35.5-1: Additional Attribute Requirements
Attribute

Value/definitions/portType/operation@nameSubmitForm/definitions/portType/operation/input/@wsaw:Actionurn:ihe:iti:2007:SubmitForm/definitions/portType/operation/output/@wsa
w:Action

urn:ihe:iti:2007:SubmitFormResponse/definitions/binding/operation/wsoap12:opera
tion/@soapActionRequired

false

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 Section 3.35.5.1 Sample SOAP Messages.
2620

For informative WSDL see ITI TF-2x: Appendix W.
The <ihe:SubmitFormRequest> element is defined as:•

One or more <xs:any> elements

This allows the Form Manager to construct forms that submit form data using any XML
representation.
2625

The <ihe:SubmitFormResponseType> element is defined as:•

An optional <ihe:content> element which is of type <ihe:formDataType> as also used in
the Retrieve Form Response. If present it shall contain:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

112

Copyright © 2017 IHE International, Inc.

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

2635

One of the following:•<ihe:Structured> containing XML encoding of a form•

<ihe:Unstructured> containing base64Binary encoding of a form•

<ihe:URL> containing the URL of a form•

An optional <ihe:instanceID> of type xs:string.

•

An optional <ihe:contentType> element, of type xs:string.

•A required <ihe:responseCode> element of type xs:string.

3.35.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/>,2640<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.35.5.1.1 Sample Submit Form SOAP Request

2645

2650

2655

<?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:SubmitForm</wsa:Action></soap:Header><soap:Body><SubmitFormRequest xmlns="urn:ihe:iti:rfd:2007">…
</SubmitFormRequest></soap:Body></soap:Envelope>

3.35.5.1.2 Sample Submit Form SOAP Response
2660

2665

2670

<?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:SubmitFormResponse</wsa:Action></soap:Header><soap:Body><SubmitFormResponseType xmlns="urn:ihe:iti:rfd:2007"><content><URL>http://somehost/xxx/services/someForm</URL>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

113

Copyright © 2017 IHE International, Inc.

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

2675

2680

<instanceID>1.2.3.4.5</instanceID></content><contentType /><responseCode /></SubmitFormResponseType></soap:Body></soap:Envelope>

3.35.6 Security Considerations
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 require use of ATNA.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

114

Copyright © 2017 IHE International, Inc.

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

2685

3.36 Archive Form [ITI-36]
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.
3.36.1 Scope
This transaction involves a Form Filler submitting form instance data to a Form Archiver.

2690
3.36.2 Use Case Roles
Form Filler

Form ArchiverArchive Form

2695

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

2700

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
IETF RFC2616 HyperText Transfer Protocol HTTP/1.1

2705

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October
2000. http://www.w3.org/TR/REC-xml.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

115

Copyright © 2017 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

2710

3.36.4.1 Archive Form
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

2715

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

2720

The Archive Form transaction shall carry an ArchiveFormRequest element, with submitted form
data as XML child elements of the ArchiveFormRequest element. Content profiles may further
constrain the content of the ArchiveFormRequest element.
See the schema provided with the support materials (see ITI TF-2x: Appendix W).
3.36.4.1.3 Expected Actions

2725

Upon receipt of the Archive Form request, the Form Archiver shall return an
ArchiveFormResponse element, or errors with SOAP Faults, for example if the posted datacannot be recognized.
The Form Filler may display the results of the response from the Form Archiver.
The Form Archiver shall use the SOAP Faults defined in Table 3.36.4.1.3-1 when appropriate.
Form Fillers shall be capable of accepting other values beyond the ones specified here.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

116

Copyright © 2017 IHE International, Inc.

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

Table 3.36.4.1.3-1: SOAP Faults
Description of error

CodeCannot recognize the posted data

SenderReason Text
Required Information Missing

An example of a SOAP Fault is:
2735

2740

2745

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

3.36.4.2 Archive Form Response
3.36.4.2.1 Trigger Events
This message is triggered by a Form Filler archiving form instance data.
2750

3.36.4.2.2 Message Semantics
An ArchiveFormResponse element is returned, which contains:•

A responseCode string that may be constrained by Content Profiles

See the schema provided with the support materials (see ITI TF-2x: Appendix W).
3.36.4.2.3 Expected Actions
2755

The Form Filler may display the results of the response from the Form Archiver. The form
behavior may be further profiled by content domain profiles.
3.36.5 Protocol Requirements

2760

The Archive Form request and response shall be transmitted using Synchronous Web Services
Exchange, according to the requirements specified in ITI TF-2x: Appendix V.
The Archive Form transaction shall use SOAP 1.2.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

117

Copyright © 2017 IHE International, Inc.

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

2765

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 Archive Form transaction presented in the order in which theywould appear in the Archive Form WSDL definition:•

The following types shall be imported (xds:import) in the /definitions/types section:•

2770

Namespace=”urn:ihe:iti:rfd:2007”, schema=”RFD.xsd”•

The /definitions/message/part/@element attribute of the Archive Form Request message
shall be defined as: “ihe:ArchiveFormRequest”•

The /definitions/message/part/@element attribute of the Archive Form Response message
shall be defined as: “ihe:ArchiveFormResponse”•

Refer to Table 3.36.5 for additional attribute requirements.
Table 3.36.5: Additional Attribute Requirements
Attribute

2775

Value

/definitions/portType/operation@nameArchiveForm/definitions/portType/operation/input/@wsaw:Actionurn:ihe:iti:2007:ArchiveForm/definitions/portType/operation/output/@wsa
w:Action

urn:ihe:iti:2007:ArchiveFormR
esponse/definitions/binding/operation/wsoap12:opera
tion/@soapActionRequired

false

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 Section 3.36.5.1 Sample SOAP Messages.
For informative WSDL see ITI TF-2x: Appendix W.
The <ihe:ArchiveFormRequest> element is defined as:

2780

•

One or more <xs:any> elements

This allows the Form Manager to construct forms that archive form data using any XML
representation.
The <ihe:ArchiveFormResponse> element is defined as:•

A required <ihe:responseCode> element of type xs:string.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

118

Copyright © 2017 IHE International, Inc.

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

3.36.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/>,2790<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.36.5.1.1 Sample Archive Form SOAP Request

2795

2800

2805

<?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:ArchiveForm</wsa:Action></soap:Header><soap:Body><ArchiveFormRequest xmlns="urn:ihe:iti:rfd:2007">…
</ArchiveFormRequest></soap:Body></soap:Envelope>

3.36.5.1.2 Sample Archive Form SOAP Response
2810

2815

2820

2825

<?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:ArchiveFormResponse</wsa:Action></soap:Header><soap:Body><ArchiveResponse xmlns="urn:ihe:iti:rfd:2007"><responseCode /></ArchiveFormResponse></soap:Body></soap:Envelope>

3.36.6 Security Considerations

2830

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 require use of ATNA.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

119

Copyright © 2017 IHE International, Inc.

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

3.37 Retrieve Clarifications [ITI-37]
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 or Form Processor
Actors.
2835

3.37.1 Scope
This transaction involves a Form Filler requesting a set of clarifications from a Form Manager orForm Processor. A Form Filler supporting the Retrieve Clarifications Option shall perform thisrequest periodically, based upon a duration defined by or agreed upon with the Form Manager /Form Receiver or Form Processor. Note that not all use cases will need to support this option.

2840

The Form Filler has an orgID, obtained by a means that is outside the scope of this transaction,and the Form Manager or Form Processor will either return a form that contains either the data to
be clarified or a set of links to other forms that can be retrieved using the Retrieve Formtransaction. All updates / clarifications / new data are submitted to the Form Receiver using theSubmit Form transaction.

2845

3.37.2 Use Case Roles
Form Filler

Form Manager

Form Processor

Retrieve
Clarifications

Actor: Form Filler
Role: A forms display and editing system capable of allowing form fields to be completed.
2850

Actor: Form Manager
Role: A system that provides clarification information based upon requests that provide specificorgIDs.
Actor: Form Processor

2855

Role: A system that provides clarification information based upon requests that provide specificorgIDs.
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

120

Copyright © 2017 IHE International, Inc.

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

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/

2865

3.37.4 Interaction Diagram
Form Manager orForm Processor

Form Filler

Retrieve Clarifications Request

Retrieve Clarifications
Response

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

3.37.4.1.1 Trigger Events

2875

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 or Form Processor. It is the responsibility of theForm 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.

2880
Parameter NameclarificationData

REQR

Description

Value

The xml representation ofclarification specific values.

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

121

Copyright © 2017 IHE International, Inc.

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

2885

2890

REQ

Description

Value

orgID

R

A string identifying theorganization

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:<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 or Form Processor shallparse the request and shall return the requested response in the RetrieveClarificationsResponse
element, or errors with SOAP Faults.

2895

The Form Manager or Form Processor 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.

2900

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

2905

The value of the orgID has been previously assigned by the Form Manager or Form Processor
and identifies 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.
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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

122

Copyright © 2017 IHE International, Inc.

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

Table 3.37.4.1.3-1: SOAP Faults
Description of error

Code

There is missing information, such as no orgID

SenderRequired Information Missing

Reason Text

No form is available

SenderUnknown orgID

An example of a SOAP Fault is:
2915

2920

2925

<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 or Form Processor use one of the named
format options. A Form Manager or Form Processor may support multiple named options, but
for each orgID there is only one named option that is supported.
2930

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 Section 3.34.4.1.4).
3.37.4.2 Retrieve Clarifications Response
3.37.4.2.1 Trigger Events

2935

The Delivery of a Form is triggered by a Form Manager or Form Processor providing a form
based upon the orgID 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.
3.37.4.2.3 Expected Actions

2940

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

123

Copyright © 2017 IHE International, Inc.

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

2945

A Form Manager or Form Processor shall return a form, whether returned as the response orreferenced by a returned URL, formatted as XHTML using XHTML Basic and W3C HTMLCompatibility 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

2950

A Form Manager or Form Processor that supports the XForms Option shall additionally becapable of returning a form, 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 Basicaccording 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

2955

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 1.2.
WSDL Namespace Definitions
ihe

2960

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:
•

2965

2970

urn:ihe:iti:rfd:2007

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”__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

124

Copyright © 2017 IHE International, Inc.

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

2975

•

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/@soapActionRequired attributeshall be defined as “false”

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 Section 3.34.5.1 Sample SOAP Messages.
2980

An informative WSDL for the Form Manager and a full XML Schema Document for the RFD
types is available online on the IHE FTP site. See ITI TF-2x: Appendix W.
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 to2985

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

2990

2995

3000

3005

3010

<?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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

125

Copyright © 2017 IHE International, Inc.

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

3015

3020

3025

3030

<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: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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

126

Copyright © 2017 IHE International, Inc.

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

3.38 Cross Gateway Query [ITI-38]
3035

This section corresponds to transaction ITI-38 of the IHE ITI Technical Framework. Transaction
ITI-38 is used by cooperating Initiating Gateway and Responding Gateway Actors.
3.38.1 Scope

3040

3045

The scope of the Cross Gateway Query transaction is based on the Registry Stored Query [ITI18] transaction. 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 useof 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 expectedthat Asynchronous Web Services Exchange will be desired by the majority ofcommunities.

•

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 respondwith zero entries.

3050

3055

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
3060
Responding
Gateway

Initiating
Gateway

Cross Gateway
Query

Figure 3.38.2-1: Use Case Roles__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

127

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor: Initiating Gateway
Role: To formulate a Cross Gateway Query on behalf of a user.
3065

Actor: Responding Gateway
Role: To respond to a Cross Gateway Query based on the internal configuration of thecommunity.
3.38.3 Referenced Standard

3070

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

ebRS

OASIS/ebXML Registry Services Specifications v3.0

ITI TF-3:4

Metadata used in Document Sharing profiles

3075
3.38.4 Interaction Diagram
Initiating
Gateway

Responding
Gateway

Cross Gateway Query
Request
Cross Gateway Query
Response

3.38.4.1 Cross Gateway Query
3080

3085

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 [ITI-18].
transaction•

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

128

Copyright © 2017 IHE International, Inc.

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

3090

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
The message semantics are based on the Registry Stored Query. See ITI TF-2a: 3.18.4.1.2.

3095

3100

Initiating Gateways which support the On-Demand Documents Option shall be capable ofquerying for an On-Demand Document Entry either through internal mechanisms or, when the
XDS Affinity Domain Option is also declared, through interaction with an XDS Document
Consumer which supports the On-Demand Documents Option.
Responding Gateways which support the On-Demand Documents Option shall be able torespond to a query of an On-Demand Document Entry, either through internal mechanisms or,when grouped with a Document Consumer, through interaction with appropriate XDS Actors
which support On-Demand Documents. 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

3105

3110

3115

3120

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
the request.

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. 14.0 Final Text – 2017-07-21

129

Copyright © 2017 IHE International, Inc.

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

3125

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.
3.38.4.1.2.2 Specifying patient identifier

3130

3135

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

3140

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

130

Copyright © 2017 IHE International, Inc.

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

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, the Responding Gateway shall:

3150

•

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 toform a query 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 a value identifying one of the Responding Gateway’s
communities for the homeCommunityId attribute in every appropriate element. The
elements that shall include the ebRIM home attribute are:

3155

3160

3165

•

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 thelocation attribute set to one of the homeCommunityIds of the Responding Gateway.

The Initiating Gateway shall:•

On receiving the response from the Responding Gateway, verify the homeCommunityId
is present where appropriate. If homeCommunityId is not present in any of theExtrinsicObject, RegistryPackage or ObjectRef elements the Initiating Gateway shallreflect an XDSMissingHomeCommunityId to the initiator of the transaction – either theDocument Consumer or the internal actor. All XDSMissingHomeCommunityId errors
generated by the Initiating Gateway shall include, in the context of the message,
identification of the Responding Gateway that returned the invalid response and theelement or elements that were in error.

•

If the XDS Affinity Domain Option is supported and if needed, consolidate results frommultiple Responding Gateways. This includes reflecting in the consolidated results
returned in response to the originating Registry Stored Query [ITI-18] all successes andfailures received from Responding Gateways. If both successes and failures are received
from Responding Gateways, the Initiating Gateway shall return both RegistryObjectList
and RegistryErrorList in one response and specify PartialSuccess status. If an
XDSUnknownPatientId error is returned from a Responding Gateway then the Initiating

3170

3175

3180

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

131

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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 notexpecting 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].

3185

3.38.4.1.3.1 Compatibility of Options
3190

3195

The presence or absence of the optional $XDSDocumentEntryType parameter triggers the
behaviors on the Responding Gateway. If this value is specified, and the Responding Gateway(or XDS community supported by the Responding Gateway) does not support it, it shall beignored. If it is specified, and the Responding Gateway (or underlying XDS community) does
support it, the proper information is returned. See ITI TF-2a: 3.18.4.1.2.5 for more details
regarding compatibility of the Registry Stored Query transaction.
3.38.4.1.3.2 Assigning homeCommunityID to Responding Gateway

3200

As described in ITI TF-2a: 3.18.4.1.2.3.8, the homeCommunityId is used to identify acommunity. Initiating Gateways and Responding Gateways use this value to route requests,
normally through lookup in a directory. As an identifier of a community, the homeCommunityId
is a larger concept than a single Responding Gateway, which may represent one or morecommunities. In fact, a community may be represented by several Responding Gateways and a
Responding Gateway may represent many communities. Thus, the relationship between
Responding Gateways and homeCommunityIds is a multiple to multiple relationship. But thefollowing rules do apply:

3205

•

An Initiating Gateway may route query and retrieve requests either by looking up thehomeCommunityId in a directory or by sending the request to the Responding Gatewayfrom which it received the homeCommunityId. If the Initiating Gateway looks up thehomeCommunityId in a directory, the Responding Gatewaty that it finds may not be the
Responding Gateway that returned the value.

3210

•

The Responding Gateway shall accept and properly route all query and retrieve requests
containing any homeCommunityId that it returned in a prior query response.

•

If the deployment requires that the Initiating Gateway and Responding Gateway use acommon directory, then all homeCommunityIds returned by a Responding Gateway
should be available for lookup in the common directory. If a community is represented bymore than one Responding Gateway, the directory may map the homeCommunityId to
one or more of the associated Responding Gateways.

3215

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

The Initiating Gateway:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

132

Copyright © 2017 IHE International, Inc.

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

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
except that 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).

3225

•
3230

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
3235

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

3240
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:
•

3245
•

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”__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

133

Copyright © 2017 IHE International, Inc.

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

3250

•

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
Table 3.38.5-2: Additional Attribute Requirements
Attribute

3255

Value

/definitions/portType/operation@nameRespondingGateway_CrossGatewayQuery/definitions/portType/operation/input/@wsaw:Action

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

urn:ihe:iti:2007:CrossGatewayQueryRespon
se/definitions/binding/operation/wsoap12:operation/@soapAction
Required

false

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 Section 3.38.5.1 Sample SOAP Messages.
For informative WSDL for the Responding Gateway see ITI TF-2x: Appendix W.
3.38.5.1 Sample SOAP Messages

3260

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.

3265

3.38.5.1.1 Sample Cross Gateway Query SOAP Request
3.38.5.1.1.1 Synchronous Web Services Exchange

3270
3275
3280

<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://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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

134

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.38.5.1.1.2 Asynchronous Web Services Exchange
3285
3290
3295

<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
3300
3305

<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
3310
3315
3320

<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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

135

Copyright © 2017 IHE International, Inc.

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

3.39 Cross Gateway Retrieve [ITI-39]
3325

This section corresponds to transaction ITI-39 of the IHE Technical Framework. Transaction
ITI-39 is used by the Initiating Gateway and Responding Gateway Actors.
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 transactions
are:

3330

3335

•

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.

3340

3.39.2 Use Case Roles
Initiating
Gateway

Responding
Gateway

Cross Gateway
Retrieve

3345

Figure 3.39.2-1: Use Case Roles

Actor: Initiating Gateway
Role: To formulate a Cross Gateway Retrieve in response to Retrieve Document Set transactions
or other internal interaction.
3350

Actor: Responding Gateway
Role: To return the documents requested.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

136

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.
3355

ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

ITI TF-3:4

Metadata used in Document Sharing profiles

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

3.39.4 Interaction Diagram
Initiating
Gateway

Responding
Gateway

Cross Gateway
Retrieve Request
Cross Gateway
Retrieve Response

3.39.4.1 Cross Gateway Retrieve Request
The Cross Gateway Retrieve Request uses the same syntax and standards as the Retrieve
Document Set Request. See Section ITI TF-2b: 3.43.4.1.
3365

3.39.4.1.1 Trigger Events
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.

3370

3.39.4.1.2 Message Semantics
The message semantics for Cross Gateway Retrieve are the same as Retrieve Document Set (sSection 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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

137

Copyright © 2017 IHE International, Inc.

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

3380

3385

Initiating Gateways which support the On-Demand Documents Option shall be capable ofretrieving an On-Demand Document Entry either through internal mechanisms or, when the
XDS Affinity Domain Option is also declared, through interaction with an XDS Document
Consumer which supports the On-Demand Documents Option.
Responding Gateways which support the On-Demand Documents Option shall be able torespond to retrieval of an On-Demand Document Entry either through internal mechanisms or,when grouped with a Document Consumer, through interaction with appropriate XDS Actors
which support On-Demand Documents. Responding Gateways which support the Persistence ofRetrieved Documents Option shall specify the NewRepositoryUniqueId element indicating the
document is available for later retrieval and be able to return exactly the same document in all
future retrieve requests for the document identified by NewDocumentUniqueId.
3.39.4.1.3 Expected Actions
Actors supporting this transaction shall support the Expected Actions described in the Section
3.43.4.1.3.

3390

3395

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
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.
If the Responding Gateway returns any Regitry Error elements, the Responding Gateway shall
include in the location attribute all the requirements stated in Section 3.43 plus thehomeCommunityId of the Responding Gateway.

3400

3405

If the XDS Affinity Domain Option is supported, the Initiating Gateway 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.3.1 Compatibility of Options
If the Initiating Gateway does not support the On-Demand Document Option, it will never send a
Cross Gateway Retrieve request for an On-Demand Document. In this case, none of theattributes specific to On-Demand Documents will be included in the response.

3410

If the Initiating Gateway does support the On-Demand Document Option, it will only direct
Cross Gateway Retrieve requests for On-Demand Documents to responders which have returned
an On-Demand Document Entry in a Cross Gateway Query response. Thus there are nocompatibility concerns with this transaction.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

138

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.39.4.2 Cross Gateway Retrieve Response
3415

3.39.4.2.1 Trigger Events
This message will be triggered by a Cross Gateway Retrieve Message.
3.39.4.2.2 Message Semantics
The message semantics for Cross Gateway Retrieve are the same as Retrieve Document Set. See
Section 3.43.4.2.2.

3420

3.39.4.2.3 Expected Actions
Actors supporting this transaction shall support the Expected Actions described in Section
3.43.4.2.3.
3.39.5 Protocol Requirements

3425

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.
Table 3.39.5-1: WSDL Namespace Definitions

3430

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:•

3435

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

139

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.39.5-2: Requirements for portType and Binding attributes
Attribute

Value/definitions/portType/operation@nameRespondingGateway_CrossGa
tewayRetrieve/definitions/portType/operation/input/@wsaw:Action

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

urn:ihe:iti:2007:CrossGateway
RetrieveResponse/definitions/binding/operation/wsoap12:operation/@soapActionRequired

false

3440
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 Section 3.43.5.1 Sample SOAP Messages.
For informative WSDL for the Responding Gateway see ITI TF-2x: Appendix W.
3445

The <ihe:RetrieveDocumentSetRequest/> element is defined in Section 3.43.5. When usedwithin the Cross Gateway Retrieve the <ihe:HomeCommunityId/> element is required.
The <ihe:RetrieveDocumentSetResponse/> element is defined in Section 3.43.5.
3.39.5.1 Sample SOAP Messages

3450

3455

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.
3.39.5.1.1 Sample Cross Gateway Retrieve SOAP Request
3.39.5.1.1.1 Synchronous Web Services Exchange

3460
3465
3470

<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://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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

140

Copyright © 2017 IHE International, Inc.

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

<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

3490
3495
3500
3505
3510
3515

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><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
3.39.5.1.2.1 Synchronous Web Services Exchange
3520
3525
3530
3535

<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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

141

Copyright © 2017 IHE International, Inc.

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

3540
3545
3550

3555
3560
3565
3570
3575
3580
3585
3590

<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<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"><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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

142

Copyright © 2017 IHE International, Inc.

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

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:

3600

•

If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit
as if it were a Document Repository (see Section 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 Section 3.43.6).

•

In addition, if interacting with a local Document Repository, shall audit as if it were a
Document Consumer (see Section 3.43.6). One audit record shall be created for each
Document Repository contacted.

3605

The Responding Gateway:

3610

•

Shall audit the Cross Gateway Retrieve as if it were a Document Repository except thatfor EventTypeCode the Responding Gateway shall specify EV(“ITI-39”, “IHE
Transactions”, “Cross Gateway Retrieve”) (see Section 3.43.6).

•

In addition, if interacting with a local Document Repository, shall audit as if it were a
Document Consumer (see Section 3.43.6). One audit record shall be created for each
Document Repository contacted.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

143

Copyright © 2017 IHE International, Inc.

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

3.40 Provide X-User Assertion [ITI-40]
3615

This section corresponds to transaction ITI-40 of the IHE IT Infrastructure Technical
Framework.
3.40.1 Scope

3620

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.
3.40.2 Use Case Roles

Actor: X-Service User
3625

Role: User of a transaction that requires a Cross-Enterprise User Assertion
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

3630

•

OASIS http://www.oasis-open.org/committees/security/.
•

3635

SAMLCore SAML V2.0 Core standard•

WSS10 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0(WS-Security 2004)", March 2004.

•

WSS11 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1(WS-Security 2004)", February 2006.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

144

Copyright © 2017 IHE International, Inc.

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

3640

•

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•

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
3645

•

•
3650

3655

IHE Profiles•

Personnel White Pages Profile•

Enterprise User Authentication Profile•

Basic Patient Privacy Consents Profile

OASIS
•

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•

XSPA-XACMLv1.0 OASIS Standard, “Cross-Enterprise Security and Privacy
Authorization (XSPA) Profile of XACML v2.0 for Healthcare v1.0” , November
2009__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

145

Copyright © 2017 IHE International, Inc.

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

3660

Figure 3.40.1-1: X-User Assertion Messages

3.40.4.1 Provide X-User Assertion

3665

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

3670

3.40.4.1.1 Trigger
Configuration of the X-Service Provider and X-Service User indicates when the X-User
Assertion transaction is necessary.
3.40.4.1.2 Message Semantics

3675

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

146

Copyright © 2017 IHE International, Inc.

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

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 (See
Section 3.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 Record Repository.

3685

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 (See
Section 3.40.4.2 ATNA Audit encoding). For example: The XDS.b Document Consumer 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 Record Repository.

3690

The SAML 2.0 Assertion is profiled as follows (bold is used when SAML 2.0 terms are used):•3695

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).
•

•
3700

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.

3705

3710

3715

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 Assertion shall contain an AuthnStatement specify the AuthnContextClassRef orAuthnContextDeclRef•

The Assertion may contain other statements (e.g., Attributes) The <AttributeStatement>element describes a statement by the SAML authority asserting that the requesting user isassociated with the specified attributes. When Local Policy requires that the following
attributes are carried in the SAML assertion then they should be encoded as follows:•

Subject ID : The value on the Subject ID attribute shall be a plain text description of
the user's name (not user ID).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

147

Copyright © 2017 IHE International, Inc.

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

3720

This <Attribute> element shall have the Name attribute set to“urn:oasis:names:tc:xspa:1.0:subject:subject-id”. The name of the user shall beplaced in the value of the <AttributeValue> element. (Keep in mind that the term
“subject” in SAML and XACML refers to the individual making the request; inthis specification, the term “User” is generally used with the same meaning, butwhen referring to attributes defined in SAML or XACML, the naming conventionof the standard is retained.)

3725<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"><saml:AttributeValue>Walter H.Brattain IV</saml:AttributeValue></saml:Attribute>

•

•

3730

Subject Organization : The value on Subject Organization attribute shall be a plain text
description of the organization.
•

This <Attribute> element shall have the Name attribute set to“urn:oasis:names:tc:xspa:1.0:subject:organization”. In plain text, the organization thatthe user belongs to shall be placed in the value of the <AttributeValue> element.
<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization"><saml:AttributeValue>Family Medical Clinic</saml:AttributeValue></saml:Attribute>

3735

•

Subject Organization ID Attribute•

3740

This <Attribute> element shall have the Name attribute set to“urn:oasis:names:tc:xspa:1.0:subject:organization-id” A unique identifier for theorganization that the user is representing in performing this transaction shall beplaced in the value of the <AttributeValue> element. This organization ID shallbe consistent with the plain-text name of the organization provided in the User
Organization Attribute. The organization ID may be an Object Identifier (OID),
using the urn format (that is, “urn:oid:” appended with the OID); or it may be a
URL assigned to that organization.
<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"><saml:AttributeValue>http://familymedicalclinic.org</saml:AttributeValue></saml:Attribute>

3745•

Home Community ID Attribute•

3750

This <Attribute> element shall have the Name attribute set to“urn:ihe:iti:xca:2010:homeCommunityId”. The value shall be the Home
Community ID (an Object Identifier) assigned to the Community that is initiating
the request, using the urn format (that is, “urn:oid:” appended with the OID).
<saml:Attribute Name="urn:ihe:iti:xca:2010:homeCommunityId"><saml:AttributeValue>urn:oid:2.16.840.1.113883.3.190</saml:AttributeValue></saml:Attribute>

3755

•

National Provider Identifier (NPI) Attribute•

A National Provider Identifier (NPI) is a unique identifier issued to health careproviders by their national authority. (e.g., in the United States this is a 10-digit
number assigned by the Centers for Medicare and Medicaid Services (CMS)).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

148

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This attribute provides the ability to specify an NPI value as part of the SAML
assertion that accompanies a message. When a simple string is used there needs tobe a mutually agreed upon assigning authority. The Other Provider Identifier
Attribute can be used to explicitly show the assigning authority (See use in the
Other Provider Identifier Attribute below).

3760

Note: Usage of a HL7 CE type in this attribute is permitted for backward
compatibility.

3765•<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:npi"><saml:AttributeValue>1234567890</saml:AttributeValue></saml:Attribute>

3770
•
3775

3780

3785

3790

Other Provider Identifier Attribute•

A unique identifier issued to health care providers by a named authority. This
<Attribute> may be repeated.

•

This <Attribute> element SHALL have the Name attribute set to“urn:ihe:iti:xua:2017:subject:provider-identifier”. The value of the<AttributeValue> element is a child element, “id”, in the namespace “urn:hl7org:v3”, whose content is defined by the “II” (instance identifier) data type fromthe HL7 version 3 abstract data type specification. The “id” element must containa “root” attribute and an “extension” attribute. It may also contain an“assigningAuthorityName” attribute and a “displayable” attribute. The “root”
attribute shall contain an OID identifying the authority issuing the provider
identifier. The “extension” attribute shall contain the provider identifier itself. The“assigningAuthorityName” attribute may be used to include a human readable
name for the assigning authority identified by the “root” attribute. The“displayable” attribute may be included to signal that the the identifier is humanreadable (if set to “true”) or intended for machine reading (if set to “false”).
An example of the syntax of this element follows:<saml:Attribute Name="urn:ihe:iti:xua:2017:subject:provider-identifier"><saml:AttributeValue><id xmlns="urn:hl7-org:v3" xsi:type="II" extension="1234567890"
root="2.999.1.2.3.4.5" assigningAuthorityName="Example Authority"
displayable="true"/></saml:AttributeValue></saml:Attribute>

3795

3800

This <Attribute> element SHALL have the Name attribute set to“urn:oasis:names:tc:xspa:1.0:subject:npi”. An example of the syntax of thiselement follows:•

The Assertion may contain other statements (e.g., Attributes)•

The Assertion shall be signed by the X-Assertion Provider as defined in SAML Core.

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 to__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

149

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
interception 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.
3.40.4.1.2.1 Subject-Role Option
3805

3810

3815

3820

When the Subject-Role Option is used the X-Service User shall encode the relevant user subject
roles from a locally defined Code-Set into subject role <Attribute> element(s). The Subject-Rolevalues communicated are assertions from the X-Service User perspective.
The subject role <Attribute> element shall have the Name attribute set to“urn:oasis:names:tc:xacml:2.0:subject:role”. The value of the <AttributeValue> element is achild element, “Role”, in the namespace “urn:hl7-org:v3”, whose content is defined by the “CE”
(coded with equivalents) data type from the HL7 version 3 specification. The code attribute shallcontain the role code from the identified Value-Set that represents the role that the XUA user isplaying when making the request. The displayName attribute may be used to include a humanreadable representation of the role code. The codeSystem attribute shall contain the OID of thecoding system that the role code was taken from. The codeSystemName attribute shall identify
the name of the coding system. No other parts of the CE data type shall be used. The following is
an example of the syntax of this element:<saml:Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role"><saml:AttributeValue><Role xmlns="urn:hl7-org:v3" xsi:type="CE" code="46255001"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED_CT"
displayName="Pharmacist"/></saml:AttributeValue></saml:Attribute>3825
3.40.4.1.2.2 Authz-Consent Option

3830

3835

3840

When the Authz-Consent Option is supported and a policy identifier needs to be sent, the XService User shall include the document unique ID of the Patient Privacy Policy
Acknowledgement Document or include the Patient Privacy Policy Identifier for a policy that has
been previously published encoded as SAML attributes.
A Patient Privacy Policy Acknowledgement Document unique ID shall be encoded as a SAML
attribute in the IHE ITI namespace, “urn:ihe:iti:bppc:2007:docid”, with name format“urn:oasis:names:tc:SAML:2.0:attrname-format:uri”. Access to the content is not specified.
Access through an XDS/XCA/XDR/XDM mechanism is a potential approach. Similarly, thisoption does not specify how the policy documents should be used to make access control
decisions. A sample attribute fragment is given in Figure 3.40-2.
<saml2:Attribute FriendlyName="Patient Privacy Policy Acknowledgement Document"
Name="urn:ihe:iti:bppc:2007:docid"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

150

Copyright © 2017 IHE International, Inc.

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

3845

xsi:type="xs:anyURI">urn:oid:1.2.3.xxx</saml2:AttributeValue></saml2:Attribute>

Figure 3.40-2: Sample attribute holding a reference to patient acknowledgement

3850

3855

3860

A Patient Privacy Policy Identifier shall be encoded as a SAML attribute in the IHE ITI
namespace, “urn:ihe:iti:xua:2012:acp”, with name format``urn:oasis:names:tc:SAML:2.0:attrname-format:uri’’. The policy identifier shall be expressedusing the xs:anyURI data type. The referenced policy identifier is the OID of a published policy.
Access to this policy is not specified further. A sample is given in Figure 3.40-3.
<saml2:Attribute FriendlyName="Patient Privacy Policy Identifier"Name="urn:ihe:iti:xua:2012:acp"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:anyURI">urn:oid:1.2.3.yyyy</saml2:AttributeValue></saml2:Attribute>

Figure 3.40-3: Sample attribute holding a reference to a privacy policy

3.40.4.1.2.2.1 Patient Identifier Attribute

3865This attribute is optional, as it may not be needed for cases in which the data being exchanged
does not pertain to a specific patient (e.g., population health data). The value of the Patient
Identifier attribute is recommended when the InstanceAccessConsentPolicy attribute is specified
in an Authorization Decision Statement.
This <Attribute> element shall have the Name attribute set to:“urn:oasis:names:tc:xacml:2.0:resource:resource-id”.

3870

3875

3880

The patient identifier of the requesting organization shall be placed in the value of the<AttributeValue> element. The patient identifier shall consist of two parts; the OID for theassigning authority and the identifier of the patient within that assigning authority. The value
shall be formatted using the CX syntax. As an example, a patient identifier of 543797436 for an
assigning authority with an OID of 1.2.840.113619.6.197, has been encoded into the follow
SAML assertion snippet. Please note that the '&' character has been properly encoded in the
XML content in the following example.
<saml:Attribute Name="urn:oasis:names:tc:xacml:2.0:resource:resource-id"><saml:AttributeValue>543797436^^^&amp;1.2.840.113619.6.197&amp;ISO</saml:AttributeValu
e></saml:Attribute>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

151

Copyright © 2017 IHE International, Inc.

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

3885

The PurposeOfUse <Attribute> element shall have the Name attribute set to“urn:oasis:names:tc:xspa:1.0:subject:purposeofuse”. The value of the <AttributeValue> element
is a child element, “PurposeOfUse”, in the namespace “urn:hl7-org:v3”, whose content isdefined by the “CE” (coded element) data type from the HL7 version 3 specification.
The PurposeOfUse element shall contain the coded representation of the Purpose for Use that isin effect for the request.
An example of the syntax of this element is as follows:

3890

3895

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse"><saml:AttributeValue><PurposeOfUse xmlns="urn:hl7-org:v3" xsi:type="CE" code="12"
codeSystem="1.0.14265.1"
codeSystemName="ISO 14265 Classification of Purposes for processing personal healthinformation"
displayName="Law Enforcement"/></saml:AttributeValue></saml:Attribute>

3900
Codes are assigned by the local Security Domain and a Code-Set needs to be managed. A goodsource Vocabulary for PurposeOfUse is ISO 14265 – Health Informatics – Classification of
purposes for processing personal health information. The Value-Set used may include local
codes or codes drawn from formal vocabulary.
3905

The value of the Purpose of Use attribute shall be a urn:hl7-org:v3:CE element, specifying thecoded value representing the user's purpose in issuing the request, choosing from the value set
given by local Policy. The codeSystem attribute of this element must be present, and mustspecify the OID of the "Purpose of Use" code system.
3.40.4.1.2.3.1 ATNA encoding of PurposeOfUse

3910

When the PurposeOfUse Option is used the X-Service User and X-Service Provider SHALL
place the PurposeOfUse value into the ATNA Audit Message associated with the transaction
according to the Record Audit Event [ITI-20] transaction (see ITI TF-2a: 3.20.7.1.2).
3.40.4.1.3 Expected Actions

3915

3920

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

152

Copyright © 2017 IHE International, Inc.

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

3925

3930

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 (seeSection 3.40.4.2 ATNA Audit encoding). For example: The XDS.b Document Consumer
performing a Registry Stored Query records the Query event; this event record will include theidentity provided in the XUA Identity Assertion. This assures that the X-Service User and XService Provider ATNA Audit messages can be correlated at the ATNA Audit Record
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).

3935

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.

3940

3.40.4.1.3.1 Subject-Role Option
When the Subject-Role Option is used, the X-Service Provider may utilize the Subject-Rolevalues in local policy for access control decision making.
The X-Service Provider may need to bridge the Subject-Role values into local role vocabulary.
The Subject-Role may be used to populate the ATNA Audit Message.

3945

3.40.4.1.3.2 Authz-Consent Option

3950

When the Authz-Consent Option is used, the X-Service Provider may utilize the Authz-Consent
values in local policy for access control decision making. The Authz-Consent values are offeredby the X-Service User as an indicator of the specific consent or authorization that the X-Service
User has determined authorizes the transaction. The values are informative to the X-Service
Provider which may choose to ignore the values.
This may require the X-Service Provider to lookup the metadata by reference to the values given,and may require the X-Service Provider to retrieve the consent documents.
The Authz-Consent value may be used to populate the ATNA Audit Message.
3.40.4.1.3.3 PurposeOfUse Option

3955

When the PurposeOfUse Option is used the X-Service Provider SHALL place the PurposeOfUse
into the ATNA Audit Message associated with the transaction (see Section 3.40.4.1.2.3.1). This__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

153

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PurposeOfUse in the audit log can be used at the Audit Record Repository to inform reporting
such as Accounting of Disclosures or Breach Notifications. The X-Service Provider MAY use
the PurposeOfUse value in Access Control decisions.
3960

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:alias"<"user"@"issuer">"

3965

3970

where:•

alias is the optional string within the SAML Assertion's Subject element SPProvidedID
attribute•

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's Issuer element

3.40.4.3 Informative Material on WS-Trust

3975

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

154

Copyright © 2017 IHE International, Inc.

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

3.41 Provide and Register Document Set-b [ITI-41]

3980

This section corresponds to Transaction [ITI-41] of the IHE Technical Framework. Provide andRegister Document Set-b is used to transmit a set of documents and associated metadata. The
documents and metadata might be stored for later retrieval or processed in some other way
depending on the actor and workflow using the transaction.
3.41.1 Scope
The Provide and Register Document Set-b transaction passes a Document Submission Request(see ITI TF-3: 4.2.1.5) from a Content Sender to a Content Receiver.
3.41.2 Actor Roles

3985

The Roles in this transaction are defined in the following table and may be played by the actors
shown here:
Table 3.41.2-1: Actor Roles

Role:

Content Sender: A system that submits documents and associated metadata
to a Content Receiver.

Actor(s):The following actors may play the role of Content Sender:
Document Source, Metadata-Limited Document Source

Role:

Content Receiver: A system that receives a set of documents and associatedmetadata.

Actor(s):The following actors may play the role of Content Receiver:
Document Repository, Document Recipient

3990

Transaction text specifies behavior for each Role. The behavior of specific Actors may also be
specified when it goes beyond that of the general Role.
3.41.3 Referenced Standards
ebRIM

OASIS/ebXML Registry Information Model v3.0
This model defines the types of metadata and content that can be stored in an ebXML Registry, a basis
for and subset of Document Sharing metadata.

ebRS

OASIS/ebXML Registry Services Specifications v3.0
This defines the services and protocols for an ebXML Registry, used as the basis for the XDS Document
Registry

MTOM

SOAP Message Transmission Optimization Mechanism http://www.w3.org/TR/soap12-mtom/
This is a method for optimizing the transmission and/or wire format of SOAP messages.

XOP

XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/
This is a means of more efficiently of converting an XML Infoset with certain types of content into a
stream of bytes for transmission.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

155

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
See ITI TF-2x: Appendix V for other referenced standards for SOAP encoding.
See ITI TF-3: 4.2 for other referenced standards for metadata element encoding.

3.41.4 Interaction DiagramsContent
SenderContent
Receiver
Provide and Register Document Set – b
RequestProvide and Register Document Set – b
Response3995

3.41.4.1 Provide and Register Document Set-b Request

4000

The Provide and Register Document Set-b Request message is used to send patient specifichealthcare information as a set of documents and associated metadata. Metadata enables thereceiver to process the content of the message programmatically, without needing to understandthe format or contents of the documents. For more details about metadata in the context ofDocument Sharing, see ITI TF-3: 4.
A Content Sender sends documents and associated metadata to a Content Receiver.
3.41.4.1.1 Trigger Events
The Content Sender, based on a human decision or the application of a certain rule of automatic
operation, wants to submit document-related information to a Content Receiver.

4005

3.41.4.1.2 Message Semantics
The Provide and Register Document Set-b Request message shall use SOAP 1.2 and MTOM
with XOP encoding (labeled MTOM/XOP in this specification). Implementors of this transaction
shall comply with all requirements described in: ITI TF-2x: Appendix V: Web Services for IHE
Transactions.

4010

The use of MTOM/XOP is governed by the following rules:•

The Content Sender shall generate the Provide and Register Document Set-b Request
message in MTOM/XOP format.

•

The Content Receiver shall accept documents in a Provide and Register Document Set-b
Request message in MTOM/XOP format.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

156

Copyright © 2017 IHE International, Inc.

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

4020

The Provide and Register Document Set-b request message shall contain a Submission Request,
as defined in ITI TF-3: 4.1.4, and may contain documents. See ITI TF-3: 4.2.1.4 for a descriptionof the ebRS/ebRIM representation of a Submission Request. The metadata requirements for thisSubmission Request are defined in ITI TF-3: 4.3.1. The Submission Request shall containexactly one DocumentEntry object for each Document contained in the request message, andvice versa.
All DocumentEntry objects in this Submission Request shall be Stable DocumentEntry objects
and, therefore, will not be On-Demand DocumentEntry objects. Associations included in the
Submission Request may reference On-Demand DocumentEntry objects that have beenregistered previously.

4025

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.
XML namespace prefixes used in text and examples below are for informational purposes only
and are documented in ITI TF-2x: Appendix V, Table V.2.4-1.

4030

4035

The requirements for the request message are:•the Content-Type HTTP header shall have an action parameter with the value
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b•

the <wsa:Action> SOAP element shall contain the value
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b•

the <soap12:Body> shall contain one <xds:ProvideAndRegisterDocumentSetRequest>
element•

the <xds:ProvideAndRegisterDocumentSetRequest> element shall contain:

4040
•

4045

•

one <lcm:SubmitObjectsRequest> element representing the Submission Request (seeITI TF-3: 4.2.1.4 for details of expressing a Submission Request).

•

one <xds:Document> element for each <rim:ExtrinsicObject> contained in the<lcm:SubmitObjectsRequest>

the <xds:Document> element shall:•

have an @id attribute whose value matches the value of the corresponding
rim:ExtrinsicObject/@id•

contain the document using the xsi:base64Binary data type (Note: This is the logicalrepresentation of the document in the XML. The wire format may be different; see
ITI TF-2x: Appendix V.8)

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

Below is an example of the SOAP Body for a Provide and Register Document Set-b Request
message__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

157

Copyright © 2017 IHE International, Inc.

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

4055

4060

4065

<soap12:Body><xds:ProvideAndRegisterDocumentSetRequest><lcm:SubmitObjectsRequest><!-- Submission Request contents – See ITI TF-3: 4.2.1.4 --><rim:RegistryObjectList><!-- Registry Metadata goes here --></rim:RegistryObjectList></lcm:SubmitObjectsRequest><xds:Document id="Document01">SGVyZSBpcyBteSBkb2N1bWVudA==</xds:Document></xds:ProvideAndRegisterDocumentSetRequest></soap12:Body>

3.41.4.1.2.1 XDS Document Source Options
The XDS Document Source may choose to support options which are listed in ITI TF-1: Table
10.2-1b and described in the sections that follow it.
4070

If the XDS Document Source supports the Document Replacement Option, it shall be able togenerate replace semantics as defined in ITI TF-3: 4.2.2.2.3.
If the XDS Document Source supports the Document Addendum Option, it shall be able togenerate append semantics as defined in ITI TF-3: 4.2.2.2.1.

4075

If the XDS Document Source supports the Document Transformation Option, it shall be able togenerate transformation semantics as defined in ITI TF-3: 4.2.2.2.2.
If the XDS Document Source supports the Folder Management Option, it shall be able togenerate folder semantics as defined in ITI TF-3: 4.2.1.3 and ITI TF-3: 4.2.2.1.5.

4080

If the XDS Document Source supports the Asynchronous Web Services Exchange Option, it
shall be able to generate an Asynchronous Web Services request as defined in ITI TF-2x:
Appendix V.5.
Refer to ITI TF-1: 10.2.9 for support of the Basic Patient Privacy Enforcement Option.
3.41.4.1.3 Expected Actions
Upon receipt of a Provide and Register Document Set-b request, the Content Receiver shallprocess the request.

4085

If a failure is detected during processing, the Content Receiver shall return an error response to
the Content Sender, thus terminating this transaction; otherwise, the Content Receiver shallreturn a success response to the Content Sender. The various exception conditions and possible
error or warning messages are given in the ebRS standard and in ITI TF-3: 4.2.4 Success andError Reporting.

4090

The Content Receiver shall be capable of accepting submissions containing multiple documents.
Note: The Content Sender may submit single documents or multiple documents depending on its needs.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

158

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________A Content Receiver shall verify the received metadata as follows. For each DocumentEntry, theContent Receiver shall:
4095

4100

•

Verify the hash attribute, if present. If a received hash value differs from the calculated
hash of the received document, the Content Receiver shall reject the submission andreturn an XDSRepositoryMetadataError error.

•

Verify the size attribute, if present. If a received size value differs from the octet count of
the received document, the Content Receiver shall reject the submission and return an
XDSRepositoryMetadataError error.

Also, for the SubmissionSet, the Content Receiver may:•

Validate the sourceId. If the submission is not from a permitted Content Sender, thesubmission may be rejected and an error returned.

3.41.4.1.3.1 Document Recipient Expected Actions
4105

In addition to the Expected Actions of all Content Receivers (described in the beginning ofSection 3.41.4.1.3), a Document Recipient shall meet the following requirements.
A Document Recipient shall be able to interpret a submission without any context, such as
knowledge of a prior submission.

4110

The Document Recipient may validate the presence of metadata attributes. If the Document
Recipient declares the Accepts Limited Metadata Option and the limitedMetadata attribute ispresent, such validation shall not exceed the requirements in the column labeled “XDR MS”(XDR Metadata-Limited Document Source) of ITI TF-3: Table 4.3.1-3. Otherwise, such
validation shall not exceed the requirements in the column labeled “XDR DS” (XDR Document
Source) of ITI TF-3: Table 4.3.1-3.
The following shall not cause rejection of a submission:

4115

4120

4125

•

The submitted metadata includes Folders, and the Document Recipient cannot process the
Folder-specific content. The response shall contain a PartialFolderContentNotProcessed
warning and a textual description that Folder Content was not processed.

•

The submitted metadata includes document relationships, and the Document Recipient
cannot process the relationship-specific content. For each unsupported association, theresponse shall contain a warning and textual description that the relationship semantics
were not processed. The specific warning depends on the relationship:
PartialAppendContentNotProcessed, PartialReplaceContentNotProcessed,
PartialTransformContentNotProcessed, orPartialTransformReplaceContentNotProcessed.

The received documents may be processed further according to the capabilities of the system.
These capabilities are not specified by IHE.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

159

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.4.1.3.2 Document Repository Expected Actions
In addition to the Expected Actions of all Content Receivers (described at the beginning ofSection 3.41.4.1.3), a Document Repository shall meet the following requirements.
4130

On receipt of a Provide and Register Document Set-b [ITI-41] request, the Document Repository
shall, in order:
1. Validate and update select received metadata, as detailed below.
2. Make any received documents available for retrieval via the Retrieve Document Set [ITI43] transaction.

4135

3. Convey the updated metadata to the Document Registry via a Register Document Set-b[ITI-42] request.
4. Issue a Provide and Register Document Set-b [ITI-41] response.

4140

If any error is encountered during processing of this request, either at the Document Repository
or reported by the Document Registry, the Document Repository may revert any changes to theDocument Repository data store. The Document Repository shall then terminate processing thetransaction, and return an error response.
Before issuing the Register Document Set-b [ITI-42] transaction, the Document Repository shallupdate the received metadata as follows. For each received DocumentEntry, the Document
Repository shall:

4145

4150

•

Add or replace the repositoryUniqueId attribute. The emitted value shall identify theDocument Repository for retrieval of the received document.

•

Add a hash attribute if not present. The emitted value shall be the SHA1 hash of thereceived document.

•

Add a size attribute if not present. The emitted value shall be the octet count of thereceived document.

The Document Repository may add additional fields.

4155

4160

For each received DocumentEntry, the Document Repository may validate the uniqueId
attribute. The submission may be rejected and an error returned if the uniqueId attribute matchesa document within the Document Repository and the sizes or hashes of the two documents differ.
The specific error returned depends on which attribute differed (XDSNonIdenticalSize or
XDSNonIdenticalHash). The Document Repository shall not generate an error related to
duplication if the uniqueId attribute matches a document within the Document Repository andthe sizes and hashes of the two documents are the same. (The document may still be rejected by
the Document Registry; see Section 3.42.4.1.4.)
Except as outlined above (and in Section 3.41.4.1.3 Content Receiver Expect Actions), theDocument Repository shall not validate the presence or content of received metadata attributes.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

160

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The Document Repository shall make received documents available for retrieval via the Retrieve
Document Set [ITI-43] transaction. If the document’s uniqueId is already known to theDocument Repository, no action is required. Otherwise, the Document Repository shall:
4165

4170

4175

•

Store the received document octet stream•

Store the received DocumentEntry mimeType and uniqueId, and associate them with thereceived document octet stream.

Making the document retrievable before registering is necessary since a Document Registry may
validate storage of a document before issuing the Register Document Set-b response; or, aDocument Consumer may attempt to retrieve a document before the Register Document Set-b
response is received.
The Document Repository shall issue a Register Document Set-b [ITI-42] request to theDocument Registry with the (updated) received metadata. If the Register Document Set-b [ITI42] response includes any errors or warnings, the Document Repository shall include all such
errors and warnings in the Provide and Register Document Set-b [ITI-41] response.
3.41.4.2 Provide and Register Document Set-b Response
The Content Receiver shall send a Provide and Register Document Set-b Response message
when the processing of a Provide and Register Document Set-b Request is complete.
3.41.4.2.1 Trigger Events

4180

The request message has been received and processed by the Content Receiver
3.41.4.2.1.1 Document Repository Trigger Events
The Document Repository shall send the Provide and Register Document Set-b Response after
receipt of the response to the corresponding Register Document Set-b [ITI-42] transaction fromthe Document Registry.

4185

•

If the response to the Register Document Set-b [ITI-42] transaction indicates success,then the Document Repository shall send a successful response message.

•

If the response to the Register Document Set-b [ITI-42] transaction indicates failure, thenthe Document Repository shall send a failure response message.

3.41.4.2.2 Message Semantics
4190

The Provide and Register Document Set-b Response message shall use SOAP 1.2 and MTOM
with XOP encoding (labeled MTOM/XOP in this specification). Implementors of this transaction
shall comply with all requirements described in: ITI TF-2x: Appendix V: Web Services for IHE
Transactions.
The use of MTOM/XOP is governed by the following rules:

4195

•

The Content Receiver shall generate the Provide and Register Document Set-b Response
message in MTOM/XOP format, even though there is no base64Binary content included.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

161

Copyright © 2017 IHE International, Inc.

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

4200

4205

The Content Sender shall accept the Provide and Register Document Set-b Response
message in MTOM/XOP format.

The Provide and Register Document Set-b Response message shall carry the status of therequested operation. The response message may carry warning messages. If the requested
operation fails, the response message shall carry at least one error message. The conditions offailure and possible warning and error messages are given in the ebRS standard and detailed in
ITI TF-3: 4.2.4 Error Reporting. This transaction does not support a partial success response.
XML namespace prefixes used in text and in examples below are for informational purposes
only and are documented in ITI TF-2x: Appendix V, Table 2.4-1.
The requirements for the response message are:

4210

•

the Content-Type HTTP header shall have an action parameter with the value
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse•the <wsa:Action> SOAP header shall contain the value
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse•the <soap12:Body> soap element shall contain one <rs:RegistryResponse> element

See ITI TF-3: 4.2.4.1 for examples of response messages.
3.41.4.2.2.1 XDS Document Repository Message Semantics
4215

If the XDS Document Repository supports the Asynchronous Web Services Exchange Option
and it receives an Asynchronous Web Services request, it shall respond as defined in ITI TF-2x:
Appendix V.5.
3.41.4.2.3 Expected Actions
The Content Sender should examine the status and messages returned and take appropriate
action.

4220

3.41.5 Security Considerations
Relevant XDS Affinity Domain security considerations are discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3.41.5.1 Audit Record Considerations

4225

The Provide and Register Document Set-b transaction is either a PHI-Import event or a PHIExport event, depending on actor, as defined in ITI TF-2a: Table 3.20.4.1.1.1-1, with thefollowing exceptions.
3.41.5.1.1 Document Source Audit Message__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

162

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4230
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

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

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 (ifknown)
AuditMessage/
ActiveParticipant

Destination

AuditMessage/
ActiveParticipant

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

4235__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

163

Copyright © 2017 IHE International, Inc.

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

AuditSourceIDU

not specialized

AuditMessage
AuditSourceIdentifi
cationAuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

Patient(AuditMessage/
ParticipantObjectIde
ntification)

Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)

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

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

3.41.5.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)4240
Where:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

164

Copyright © 2017 IHE International, Inc.

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

Destination

AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

ParticipantObjectID

M

The submissionSet unique ID

ParticipantObjectNameU

not specialized

4245
Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

165

Copyright © 2017 IHE International, Inc.

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

3.42 Register Document Set-b [ITI-42]
4250

This section corresponds to Transaction [ITI-42] of the IHE IT Infrastructure Technical
Framework. Register Document Set-b is used to register a set of document-associated metadata.
3.42.1 Scope
The Register Document Set-b transaction passes a Document Submission Request (see ITI TF-3:
4.2.1.5) from a Content Sender to a Content Receiver.
3.42.2 Actor Roles

4255

The roles in this transaction are defined in the following table and may be played by the actors
shown here:
Table 3.42.2-1: Actor Roles

4260

Role:

Content Sender: A system that submits a document metadata to a Content
Receiver.

Actor(s):The following actors may play the role of Content Sender:
Document Repository, Integrated Document Source/Repository

Role:

Content Receiver: A system that receives document metadata.

Actor(s):The following actors may play the role of Content Receiver:
Document RegistryTransaction text specifies behavior for each Role. The behavior of specific Actors may also be
specified when it goes beyond that of the general Role.
3.42.3 Referenced Standards
ebRIM

OASIS/ebXML Registry Information Model v3.0
This model defines the types of metadata and content that can be stored in an ebXML Registry, a basis
for and subset of Document Sharing metadata.

ebRS

OASIS/ebXML Registry Services Specifications v3.0
This defines the services and protocols for an ebXML Registry, used as the basis for the XDS Document
Registry

HL7V2

HL7 Version 2.5

See ITI TF-2x: Appendix V for other referenced standards for SOAP encoding.
See ITI TF-3: 4.2 for other referenced standards for metadata element encoding.

3.42.4 Interaction Diagram__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

166

Copyright © 2017 IHE International, Inc.

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

Content
SenderContent
ReceiverRegister Document Set – b Request

Register Document Set – b Response

4265
3.42.4.1 Register Document Set-b Request

4270

The Register Document Set-b Request message is used to register patient-specific healthcare
documents through the use of metadata. Metadata enables the receiver to process the content of
the message programmatically, without needing to understand the format or contents of the
documents. For more details about metadata in the context of Document Sharing, see ITI TF-3:4.
The Content Sender sends metadata for a set of documents to the Content Receiver.
3.42.4.1.1 Trigger Events

4275

The Register Document Set-b Request message is triggered when a Content Sender wants toregister metadata for a set of documents it holds. These documents may have been stored in theDocument Repository by a Document Source (using the Provide and Register Document Set-b
transaction [ITI-41]) or generated internally by an Integrated Document Source/Repository.
3.42.4.1.2 Message Semantics

4280

The Register Document Set-b Request message shall use SOAP 1.2 and Simple SOAP (See ITI
TF-2x: V.8.1). Implementors of this transaction shall comply with all requirements described in:
ITI TF-2x: Appendix V: Web Services for IHE Transactions.
The Register Document Set-b Request message shall contain a Submission Request, as definedin ITI TF-3: 4.1.4.

4285

All DocumentEntry objects in this Submission Request shall be Stable DocumentEntry objects
and, therefore, will not be On-Demand DocumentEntry objects. Associations included in the
Submission Request may reference On-Demand DocumentEntry objects that have beenregistered previously.
See ITI TF-3: 4.2.1.4 for a description of the ebRS/ebRIM representation of a Submission
Request. The metadata requirements for this Submission Request are defined in ITI TF-3: 4.3.1.

4290

A full example of document metadata submission can be found in ITI TF-2x: Appendix W.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

167

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________XML namespace prefixes used in text and in examples below are for informative purposes only
and are documented in ITI TF-2x: Appendix V, Table V.2.4-1.
The requirements for the request message are:
4295

4300

•

the Content-Type HTTP header shall have an action parameter with the value
urn:ihe:iti:2007:RegisterDocumentSet-b•

the <wsa:Action> SOAP element shall contain the value
urn:ihe:iti:2007:RegisterDocumentSet-b•

the <soap12:Body> shall contain one <lcm:SubmitObjectsRequest> element representing
the Submission Request (see ITI TF-3: 4.2.1.4 for details of expressing a Submission
Request).

A full XML Schema Document for the XDS types is available online on the IHE FTP site, see
ITI TF-2x: Appendix W.
Below is an example of the SOAP Body for a Register Document Set-b Request message
4305

4310

<soap12:Body><lcm:SubmitObjectsRequest><!-- Submission Request contents – See ITI TF-3: 4.2.1.4 --><rim:RegistryObjectList><!-- Registry Metadata goes here --></rim:RegistryObjectList></lcm:SubmitObjectsRequest></soap12:Body>

4315

If the Content Sender supports the Asynchronous Web Services Exchange Option, it shall beable to generate an Asynchronous Web Services request as defined in ITI TF-2x: Appendix V.5.
3.42.4.1.2.1 Integrated Document Source / Repository Message Semantics
The Integrated Document Source / Repository may choose to support options which are listed in
ITI TF-1: Table 10.2-1b and described in the sections that follow it.

4320

If the Integrated Document Source / Repository supports the Document Replacement Option, it
shall be able to generate replace semantics as defined in ITI TF-3: 4.2.2.2.3.
If the Integrated Document Source / Repository supports the Document Addendum Option, it
shall be able to generate append semantics as defined in ITI TF-3: 4.2.2.2.1.

4325

If the Integrated Document Source / Repository supports the Document Transformation Option,
it shall be able to generate transformation semantics as defined in ITI TF-3: 4.2.2.2.2.
If the Integrated Document Source / Repository supports the Folder Management Option it, shallbe able to generate folder semantics as defined in ITI TF-3: 4.2.1.3 and ITI TF-3: 4.2.2.1.5.
If the Integrated Document Source / Repository supports the Basic Patient Privacy Enforcement
Option, it shall comply with the requirements as described in ITI TF-1: 10.2.9.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

168

Copyright © 2017 IHE International, Inc.

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

3.42.4.1.3 Expected Actions
Upon receipt of a Register Document Set-b Request message, the Document Registry shall:

4335

•

Perform metadata validations•

Store all IHE-defined metadata attributes received so that it is available to return in
responses to future queries.

•

Return a response message giving the status of the operation.

If the Document Registry rejects the metadata, it shall:

4340

•

Return an error including at least one error message in the response. For a complete listof applicable codes, refer to ITI TF-3: Table 4.2.4.1-2.

•

Roll back any changes made.

3.42.4.1.3.1 Atomicity of Submissions
XDS Submission requests shall be atomic operations. If any part of the Submission Request
processing fails, the entire transaction shall fail and no changes result.
No result of a Submission Request shall be made available until the atomic operation has
successfully completed.

4345

3.42.4.1.3.2 Extra Metadata
The Document Registry may save extra metadata attributes.

4350

4355

•

If the Document Registry saves the extra metadata attributes, it shall include that
metadata in later query responses.

•

If there are extra metadata attributes in the Submission Request and the Document
Registry does not save them, the Document Registry shall include the
XDSExtraMetadataNotSaved warning in its response, as described in ITI TF-3: 4.2.3.1.6•

Document Registry Actors that do not support the Reference ID Option may treat
referenceIdList as a non-IHE-defined metadata attribute.

The Document Registry shall verify that extra metadata attributes conform to the requirements in
ITI TF-3: 4.2.3.1.6.
3.42.4.1.3.3 Enforcement of Attributes
The Document Registry shall validate the Submission Request objects and attributes as specified
in ITI TF-3: 4.2 and 4.3.1. In addition, the following constraints apply.
3.42.4.1.3.3.1 DocumentEntry.uniqueId

4360

The Document Registry shall reject the message and return an error if the uniqueId attributematches the uniqueId attribute of a DocumentEntry within the Document Registry and the size
attributes or hash attributes of the two DocumentEntry objects differ.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

169

Copyright © 2017 IHE International, Inc.

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

4365

If the uniqueId, size, and hash attributes of a received DocumentEntry match those of a
DocumentEntry already within the Document Registry, processing of the submission shallcontinue without an error. Thus, multiple registered DocumentEntry objects can have the sameuniqueId attribute value (as long as all the size and hash attributes are the same).
Note: The Document Entries may reference the same instance of the document or may reference different (identical) copiesof the document (for example, stored on different Document Repositories).

3.42.4.1.3.3.2 patientId Attributes
4370

4375

Values of DocumentEntry.patientId, Folder.patientId, and SubmissionSet.patientId shall beverified against the patient identifiers received in the Patient Identity Feed [ITI-8] indicating thatthey are registered with the Patient ID Domain of the Affinity Domain. This validation
requirement does not apply to DocumentEntry.sourcePatentId.
All objects in the Submission Request (DocumentEntry, Folder and SubmissionSet) shall havethe same patientId.
The value of the patientId attribute of a DocumentEntry object shall match the value of thepatientId attribute of any Folder that it is a member of. This implies that all DocumentEntry
objects in a Folder have the same patientId.

4380

When the Submission Request includes a Document Relationship Association, both
DocumentEntry objects referenced by the Association shall have the same patientId.
3.42.4.1.3.3.3 Coded Attributes

4385

The XDS Affinity Domain may allow only a finite set of values for a given coded attributeconforming to ITI TF-3: 4.2.3.1.2 or may not restrict the values at all. If the XDS Affinity
Domain allows only a finite set, the Document Registry shall constrain the value to thoseallowed by the XDS Affinity Domain.
The Document Registry shall not constrain the displayName.
Note: In this section, "value" refers to the combination of a codeSystem and code.

3.42.4.1.3.3.4 DocumentEntry.mimeType
4390

The value of the DocumentEntry.mimeType shall be constrained to those allowed by the XDS
Affinity Domain.
3.42.4.1.3.3.5 DocumentEntry.availabilityStatus
The Document Registry shall set the availabilityStatus of all newly added DocumentEntry
objects to Approved.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

170

Copyright © 2017 IHE International, Inc.

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

4395

3.42.4.1.3.3.6 DocumentEntry.serviceStartTime andDocumentEntry.serviceStopTime
If the serviceStartTime and serviceStopTime attributes are both populated for a Document Entryin the Submission Request, the Document Registry shall verify that the serviceStartTime isbefore or equal to the serviceStopTime.
3.42.4.1.3.3.7 SubmissionSet.uniqueId

4400

The Document Registry shall verify that the SubmissionSet.uniqueId is not used as the uniqueId
for any existing object in the registry (DocumentEntry, SubmissionSet, or Folder).
3.42.4.1.3.4 Folder Membership

4405

When the Submission Request includes an FD-DE HasMember Association, which identifies a
Document Entry as a member of a Folder, the Document Registry shall verify that both theDocument Entry and Folder have a status of Approved.
3.42.4.1.3.5 Document Relationships
When the Submission Request includes an Association between two Document Entry objects,
the Document Registry shall verify that:

4410

•

The sourceObject references a Document Entry in the submission; otherwise it shallreturn the error UnresolvedReferenceException.

•

The targetObject references a Document Entry in the Registry; otherwise it shall returnthe error UnresolvedReferenceException.

•

The targetObject Document Entry has an availabilityStatus of Approved; otherwise, it
shall return the error XDSRegistryDeprecatedDocumentError. This ensures that only
the most recent version of a document can be replaced, etc.

•

Both Document Entry objects have the same patient identifier(XDSDocumentEntry.patientId attribute); otherwise it shall return the error
XDSPatientIdDoesNotMatch. This comparison shall take into consideration patient
identity merges as described in ITI TF-2a: 3.8.4.2.4.

4415

4420

Note: For "RPLC" and "XFRM_RPLC" relationships, earlier versions of the Technical Framework referenced the error
XDSReplaceFailed for most of the above conditions. That error has been deprecated.

When the Association type is "RPLC" or "XFRM_RPLC", the Document Registry shall also:

4425

•

Change the status of the Document Entry that is being replaced to Deprecated.

•

Change the status of all Document Entries that are transformations (XFRM) or addenda(APND) of the Document Entry being replaced to Deprecated.

When the Association type is "IsSnapshotOf", the Document Registry shall also:•

Verify sourceObject references a Stable DocumentEntry•

Verify targetObject references an On-Demand DocumentEntry__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

171

Copyright © 2017 IHE International, Inc.

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

4430

As per Section 3.42.4.1.4.1, no changes to the status of any object shall occur if the Submission
Request is not accepted and committed.
3.42.4.1.3.6 Updates to Folder.lastUpdateTime4435

If the submission results in any Document Entry being placed into any Folder, the Document
Registry shall set the lastUpdateTime attribute of those Folders to the current time. This includes
Folders included in the Submission Request as well as Folders already existing in the Document
Registry that are referenced by the Submission Request.
As per Section 3.42.4.1.4.1, no changes to the lastUpdateTime of any Folder shall occur if theSubmission Request is not accepted and committed.
3.42.4.1.3.7 UUIDs and Symbolic Ids
Objects in the Submission Request have several UUID fields conforming to ITI TF-3: 4.2.3.1.5.

4440

4445

If a field is formatted as a symbolic Id in the Submission Request, the Document Registry shall
replace it with newly generated, properly formatted UUIDs upon acceptance of the submission.
If the same symbolic Id appears more than once in the Submission Request, it shall be replacedwith the same generated UUID.
If a field is formatted as a valid UUID in the Submission Request, the Document Registry shallnot change the value.
Once a UUID-format Id value is assigned to a Registry Object, that value is permanent and shallnot be changed.
3.42.4.2 Register Document Set-b Response
3.42.4.2.1 Trigger Events

4450

The Content Receiver finishes processing a Register Document Set-b Request Message and shall
respond with Register Document Set-b Response
3.42.4.2.2 Message Semantics

4455

The Register Document Set-b Response message shall use SOAP 1.2 and Simple SOAP (See ITI
TF-2x: V.8.1). Implementors of this transaction shall comply with all requirements described in:
ITI TF-2x: Appendix V: Web Services for IHE Transactions.

4460

The Register Document Set-b Response message shall carry the status of the requested operation.
The response message may carry warning messages. If the requested operation fails, the response
message shall carry at least one error message. The conditions of failure and possible warningand error messages are given in the ebRS standard and detailed in ITI TF-3: 4.2.4 Error
Reporting. This transaction does not support a partial success response.
XML namespace prefixes used in text and in examples below are for informational purposes
only and are documented in ITI TF-2x: Appendix V, Table V.2.4-1.
The requirements for the response message are:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

172

Copyright © 2017 IHE International, Inc.

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

4465

•

the Content-Type http header shall have an action parameter with the value
urn:ihe:iti:2007:RegisterDocumentSet-bResponse•the <wsa:Action> soap header shall contain the value
urn:ihe:iti:2007:RegisterDocumentSet-bResponse•the <soap12:Body> soap element shall contain one <rs:RegistryResponse> element

See ITI TF-3: 4.2.4 for examples of response messages.
4470

If the Document Registry supports the Asynchronous Web Services Exchange Option and it
receives an Asynchronous Web Services request, it shall respond as defined in ITI TF-2x:
Appendix V.5.
3.42.4.2.3 Expected Actions

4475

The Content Sender now knows that the transaction succeeded/failed and can continue. The
metadata added to the Document Registry as a result of this transaction is now available fordiscovery.
3.42.4.2.3.1 Document Repository Expected Actions

4480

If the Register Document Set-b [ITI-42] response includes any errors or warnings, the Document
Repository shall include all such errors and warnings in the Provide and Register Document Setb [ITI-41] response.
3.42.5 Security Considerations
Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3.42.5.1 Audit Record Considerations

4485

The Register Document Set-b transaction is either a PHI-Import event or a PHI-Export event,depending on actor, as defined in ITI TF-2a: Table 3.20.4.1.1.1-1, with the following exceptions.
3.42.5.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)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

173

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Patient (0..1)
SubmissionSet (1)Where:
SourceAuditMessage/
ActiveParticipant

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

4490
Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentificati
on

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

174

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Patient (ifknown)(AuditMessage/
ParticipantObjectIde
ntification)

Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)

4495

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

3.42.5.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 (0..1)
SubmissionSet (1)Where:
SourceAuditMessage/
ActiveParticipant

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

UserID

M

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

175

Copyright © 2017 IHE International, Inc.

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

UserID

M

SOAP endpoint URI

AuditMessage/
ActiveParticipant

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient (ifknown)(AuditMessage/
ParticipantObjectIde
ntification)

4500
Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

176

Copyright © 2017 IHE International, Inc.

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

3.43 Retrieve Document Set [ITI-43]
4505

This section corresponds to transaction ITI-43 of the IHE Technical Framework. The Document
Consumer, Document Repository, On-Demand Document Source, and Initiating Gateway Actors
use transaction ITI-43.
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)
Cross-Community Access (XCA)

4510

Actors that support the Asynchronous Web Services Exchange Option shall support
Asynchronous Web Services Exchange on all XDS.b 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.43.1 Scope

4515

This transaction is used by the Document Consumer to retrieve a set of documents from theDocument Repository, On-Demand Document Source, or Initiating Gateway. The Document
Consumer has already obtained the XDSDocumentEntry uniqueId and the Document Repository
repositoryUniqueId from the Document Registry/Initiating Gateway by means of the Registry
Stored Query transaction.
3.43.2 Use Case Roles

4520
Document
ConsumerDocument Repository,Integrated Document
Source/Repository, or
On-Demand Document Source

Initiating Gateway

Retrieve
Document Set

Actor: Document Consumer
Role: Obtains document.
4525

Actor: Document Repository or Integrated Document Source/Repository
Role: Provides documents.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

177

Copyright © 2017 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.

4530

Actor: On-Demand Document Source
Role: Creates documents in response to a request for retrieval of an on-demand
document entry.
Note: Within this transaction, the Document Repository and Integrated Document Source/Repository Actors can be usedinterchangeably.

4535

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

ITI TF-3:4

Metadata in Document Sharing profiles

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/

4540
3.43.4 Interaction Diagram

Document
ConsumerDocument Repository/
Initiating Gateway/OnDemand Document Source
Retrieve Document Set Request

Retrieve Document Set Response4545__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

178

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.43.4.1 Retrieve Document Set Request
3.43.4.1.1Trigger Events

4550

4555

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 no
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
The Retrieve Document Set Request shall carry the following information:

4560

4565

•

A required repositoryUniqueId that identifies the repository from which the document is
to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId.

•

A required documentUniqueId that identifies the document within the repository. Thisvalue 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
4570

4575

4580

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

179

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.43.4.1.3.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:

4585

4590

1. The Document Consumer shall abide by the XDS Affinity Domain Policies represented
by the confidentialityCode in the metadata associated with the document. The Document
Consumer likely will have user access controls or business rule capabilities to determine
the details of how confidentiality codes apply to query results. The details of this areproduct specific and not specified by IHE. These rules shall reduce the query results toonly those that are appropriate to the current situation for that actor and user.
2. The Document Consumer shall be able to be configured with Patient Privacy Policies,
Patient Privacy Policy Identifiers (OIDs) and associated information necessary tounderstand and enforce the XDS Affinity Domain Policy. The details of this are productspecific and not specified by IHE.
3.43.4.2 Retrieve Document Set Response
3.43.4.2.1 Trigger Events

4595

This message will be triggered by a Retrieve Document Set Request Message
3.43.4.2.2 Message Semantics
The Retrieve Document Set Response Message shall carry the following information, for each of
the returned documents:

4600

•

A homeCommunityId. This value shall be the same as the homeCommunityId value in
the Retrieve Document Set Request Message. If the homeCommunityId value is notpresent in the Retrieve Document Set Request Message, this shall not be present.

•

A required repositoryUniqueId that identifies the repository from which the document is
to be 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. Thisvalue 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

4605

4610

4615

If the documentUniqueId is associated with an On-Demand Document Entry, the Retrieve
Document Set Response Message shall contain a NewDocumentUniqueId element that identifies
the document that is returned in the Retrieve Document Set Response. This identifier shall bedifferent than the DocumentUniqueId element which identifies the On-Demand Document Entry.
The Retrieve Document Set Response Message may also include a NewRepositoryUniqueId__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

180

Copyright © 2017 IHE International, Inc.

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

4620

4625

element that identifies the Document Repository which holds the document returned in the
Retrieve Document Set Response. If this element is not included, the document returned in the
response has not been persisted for later retrieval. If the On-Demand Document Source
implements the Persistence of Retrieved Documents Option, this element shall be specified. If a
future Retrieve Document Set Message for the same DocumentUniqueId returns the same
NewDocumentUniqueId, the content of the document shall be identical to the prior returned
content. On-Demand Document Source Actors are encouraged to re-use Document uniqueId’s
whenever content has not changed in order to facilitate identification of new content by
Document Consumers.
3.43.4.2.3 Expected Actions
A Document Repository or On-Demand Document Source shall return the document(s) indicatedin the request.

4630

4635

4640

4645

4650

The Document Repository shall return the document or an error code in case the document could
not be return. The conditions of failure and possible error messages are given in the ebRS
standard and detailed in ITI TF-3: 4.2.4 Error Reporting.
An On-Demand Document Source which supports the Persistence of Retrieved Documents
Option shall save the document content returned in the retrieve response and issue a Register
Document Set-b [ITI-42] transaction to register a Stable Document Entry which describes the
saved document. The On-Demand Document Source shall complete the registration of the Stable
Document Entry prior to responding to the Retrieve Document Set request. The registration of
the new Stable Document Entry shall include:•

A Submission Set•

A DocumentEntry representing the Stable DocumentEntry.

•

A HasMember association linking DocumentEntry to SubmissionSet.

•

An IsSnapshotOf Association which identifies the sourceObject as the new Stable
Document Entry and the targetObject as the On-Demand Document Entry which contains
the uniqueID used in the Retrieve Document Set request. See ITI TF-3: 4.2.2.2 for
information about the IsSnapshotOf Association.

If the On-Demand Document Source has previously registered a snapshot of the On-Demand
DocumentEntry, the registration of the new Stable DocumentEntry may also include a RPLC
association, identifying the new Stable DocumentEntry as a replacement of the previouslyregistered Stable DocumentEntry.
If this is not the first request for this on-demand document and a prior document was replaced, aReplace Association which identifies the prior document.
3.43.4.2.3.1 Compatibility of Options
If the Document Consumer does not support the On-Demand Documents Option it will neversend a Retrieve Document Set request for an On-Demand Document entry. In this case, none of
the new attributes will be included in the response.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

181

Copyright © 2017 IHE International, Inc.

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

If the Document Consumer does support the On-Demand Documents Option, it will only direct
requests for On-Demand Document Entries to responders which have specified their uniquerepositoryUniqueId in the On-Demand Document Entry from the registry. Thus, unless there isan error in the metadata, there are no compatibility concerns with this transaction.
3.43.5 Protocol Requirements

4660

Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
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.8 for details.
The Document Repository shall:

4665

•

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.

4670

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

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:
4675•

The following types shall be imported (xsd:import) in the /definitions/types section:•

4680

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

182

Copyright © 2017 IHE International, Inc.

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

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/wsoap12:opera
tion/@soapActionRequired

false

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 Section 3.43.5.1 Sample SOAP Messages.
4690

For informative WSDL for the Document Repository see in ITI TF-2x: Appendix W.
The <ihe:RetrieveDocumentSetRequest/> element is defined as:
•

4695

4700

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:4705•

A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element•

An optional sequence of <ihe:DocumentResponse/> elements containing•

4710

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

183

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________•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 using thexsi:base64Binary data type. (Note: This is the logical representation of the documentin the XML. The wire format may be different; see ITI TF-2x: Appendix V.8.)•

A required <ihe:mimeType/> element that indicates the MIME type of the retrieved
document•

An optional <ihe:NewDocumentUniqueId/> element that identifies the document
returned in the request when retrieval is of an On-Demand Document. This isrequired when retrieval is of an On-Demand Document.

•

An optional <ihe:NewRepositoryUniqueId/> element that identifies the Document
Repository that will support retrieval of the document created as a result of retrievalof the On-Demand Document. This is required when the On-Demand Document
Source supports the Persistence of Retrieved Documents Option.

4715

4720

4725

4730

4735

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

4740

See ITI TF-3: 4.2.4 Error Reporting for the interpretation of these values.
For each document requested in a /RetrieveDocumentSetRequest/DocumentRequest element:•

4745

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

184

Copyright © 2017 IHE International, Inc.

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

•

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:

4755

4760

4765

@location contains the DocumentUniqueId of the document requested•@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.
4770

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

4775

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

4780

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>";__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

185

Copyright © 2017 IHE International, Inc.

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

4790

4795

4800

4805

4810

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

4815
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
4820

4825

4830

4835

<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><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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

186

Copyright © 2017 IHE International, Inc.

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

4845

4850

<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
In the following example, the HTTP header Transfer-Encoding: chunked and thecorresponding chunk annotations were removed for readability.

4855
4860
4865
4870
4875
4880
4885
4890
4895

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
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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

187

Copyright © 2017 IHE International, Inc.

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

4900
4905

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

Note:

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:
4915
4920
4925
4930
4935
4940
4945
4950
4955

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>
Base64 encoded contents of document go here</xdsb:Document></xdsb:DocumentResponse></xdsb:RetrieveDocumentSetResponse></soapenv:Body>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

188

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</soapenv:Envelope>--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310--

3.43.5.1.2.2 Asynchronous Web Services Exchange
4960
4965
4970
4975
4980
4985
4990

4995

<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.5.1.3 Sample Retrieve Document Set Response from On-Demand Document
Entry
The following example shows the response to retrieval of a dynamic document entry where theresponder supports later retrieval of the document created.

5000

5005

5010

<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: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"__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

189

Copyright © 2017 IHE International, Inc.

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

5015

5020

5025

5030

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><NewDocumentUniqueId>1.3.6.1.4...2897</NewDocumentUniqueId><NewRepositoryUniqueId>1.3.6.1.4...1000</NewRepositoryUniqueId><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
5035

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 either a PHI-Import event or a PHI-Export event,depending on the actor, as defined in ITI TF-2a: Table 3.20.4.1.1.1-1, with the following
exceptions.

5040

5045

The Document Repository Actor, On-Demand Document Source, and Initiating Gateway shallgenerate an “Export” event. This may be an event for each Retrieve Document transaction, or
multiple transactions for the same patient may be heuristically combined. The heuristics for thiscombination are not specified by IHE. It is intended to reduce the volume of audit records.
Combination is permitted when the active participants and patient are the same, and the timedifference is considered insignificant.
The Document Consumer 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.

5050

If some documents were retrieved successfully and others were not, the Actors involved shallrecord a “success” audit event for those documents retrieved successfully and a “failure” audit
event for those documents not retrieved successfully.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

190

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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”)

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.

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

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)

Where:
SourceAuditMessage/
ActiveParticipant

5055
Destination
AuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

191

Copyright © 2017 IHE International, Inc.

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

Audit Source

AuditMessage/
AuditSourceIdentificati
on

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

ParticipantObjectQueryU

not specialized

M

The ParticipantObjectDetail element may occur more than once.
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

5060
Patient(if-known)(AuditMessage/
ParticipantObjectIde
ntification)

Document(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectDetail3.43.6.1.2 Document Repository, On-Demand Document Source, and Initiating
Gateway 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”)

Source (Document Repository) (1)Destination (Document Consumer) (1)Audit Source (Document Repository) (1)Document (1..n) (see combining rules above)

Where:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

192

Copyright © 2017 IHE International, Inc.

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

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.

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

5065
Destination

AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentificati
onDocument
URI(AuditMessage/
ParticipantObjectIde
ntification)

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

ParticipantObjectQueryU

not specialized

M

The ParticipantObjectDetail element may occur more than once.
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

ParticipantObjectDetail__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

193

Copyright © 2017 IHE International, Inc.

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

5070

3.44 Patient Identity Feed HL7 V3 [ITI-44]
This 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.
3.44.1 Scope

5075

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
5080

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

5085

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)

5090

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 in document
metadata by tracking identity change operations (e.g., merge).
Corresponding HL7 v3 Application Roles:

5095

Patient Registry Tracker (PRPA_AR201302UV02)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

194

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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
5100

Figure 3.44-1: Patient Identity Sequence

3.44.4.1 Patient Identity Management – Add or Revise Patient Record
3.44.4.1.1 Trigger Events
5105

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:

5110

Patient Registry Record Revised (PRPA_TE201302UV02)
This trigger event signals that patient information was revised in a Patient Identity Source.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

195

Copyright © 2017 IHE International, Inc.

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

5115

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
may serve more than one Patient Identifier Domain.
3.44.4.1.2 Message Semantics

5120

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.

5125

The message information model in Section 3.44.4.1.2.2.describes the relevant data elements forthis transaction. Specific requirements for the particular actors are found in Section 3.44.4.1.3
Expected Actions.
3.44.4.1.2.1 Major Components of the Patient Registry Record Added/Revised
Messages

5130

Patient

5135

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.
Provider Organization

5140

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

5145

Language Communication
Information about what language(s) should be used to communicate with the focal person can besent in the LanguageCommunication class.
PersonalRelationship__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

196

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This is used for sending information pertaining to the mother’s maiden name.
5150

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.
Other Identifiers

5155

5160

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

5170

5175

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.
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)
5180

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•

guardian__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

197

Copyright © 2017 IHE International, Inc.

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

contactParty•

asMember•careGiver•

asStudent

The following participations are omitted:
5190•

subjectOf (administrativeObservation)•

coveredPartyOf (coverage)

Figure 3.44.4.1.2-1: RMIM Diagram

5195
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. 14.0 Final Text – 2017-07-21

198

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.44.4.1.2-1: Model Attributes
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used to reportthat a new patient record was added, or a patient 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)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" roleid [1..*] (M)Patient (SET<II>)

Identifiers designated by this patient identity source for the focal
personstatusCode [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..*]Patient (SET<CE>) {CWE:Confidentiality}

Value(s) that control the disclosure of information about this living
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)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person

telecom [0..*]
Person (BAG<TEL>)

Telecommunication address(es) for communicating with this person

administrativeGenderCode [0..1]
Person (CE) {CWE:AdministrativeGender}

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.

birthTime [0..1]
Person (TS)The date and time this person was born

deceasedInd [0..1]
Person (BL)An indication that this person is deaddeceasedTime [0..1]
Person (TS)The date and time this person diedmultipleBirthInd [0..1]
Person (BL)An indication that this person was part of a multiple birthmultipleBirthOrderNumber [0..1]
Person (INT)The order in which this person was born if part of a multiple birth

addr [0..*]
Person (BAG<AD>)

Address(es) for corresponding with this person

maritalStatusCode [0..1]

A value representing the domestic partnership status of this person__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

199

Copyright © 2017 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 to reportthat a new patient record was added, or a patient record
was updated.
Derived from Figure 3.44.4.1.2-1 (PRPA_RM201301IHE)

Person (CE) {CWE:MaritalStatus}
religiousAffiliationCode [0..1]
Person (CE) {CWE:ReligiousAffiliation}

A value representing the primary religious preference of this person

raceCode [0..*]
Person (SET<CE>) {CWE:Race}

A set of values representing the races of this person

ethnicGroupCode [0..*]
Person (SET<CE>) {CWE:Ethnicity}

A set of values representing the ethnic groups of this person

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)Role (CS) {CNE:ROL}

Structural attribute. This can be any specialization of "role" except
for Citizen, or Employee.

id [1..*] (M)Role (SET<II>)

One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)PersonalRelationship

A personal relationship between the focal living subject and anotherliving subject

classCode [1..1] (M)Role (CS) {CNE:PRS, fixed value= "PRS"}

Structural attribute; this is a "personal relationship" role

id [0..*]
Role (SET<II>)

Identifier(s) for this personal relationshipcode [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

statusCode [0..1]
Role (CE){CWE:RoleStatus}

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

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)Role (CS) {CNE:CIT, fixed value= "CIT"}

Structural attribute; this is a "citizen" role

id [0..*]
Role (SET<II>)

Identifier(s) for the focal person as a citizen of a nation

effectiveTime [0..1]
Employee (IVL<TS>)

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

NationA politically organized body of people bonded by territory andknown as a nation.

classCode [1..1] (M)Organization (CS) {CNE:NAT, fixed value= "NAT"}

Structural attribute; this is a 'nation' type of entity

determinerCode [1..1] (M)Structural attribute; this is a specific entity__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

200

Copyright © 2017 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 to reportthat a new patient record was added, or a patient record
was updated.
Derived from Figure 3.44.4.1.2-1 (PRPA_RM201301IHE)

Organization (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
code [1..1] (M)Organization (CD) {CWE:NationEntityType}A value that identifies a nation statename [0..1]
Organization (ON)A non-unique textual identifier or moniker for this nation

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)Employee (CS) {CNE:EMP}

Structural attribute; this is an "employee" role

statusCode [0..1]
Employee (CS) {CNE:RoleStatus}

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

statusCode [0..1]
Employee (CS) {CNE:RoleStatus}

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

effectiveTime [0..1]
Employee (IVL<TS>)

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

occupationCode [0..1]
Employee (CE) {CWE:EmployeeOccupationCode}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.

BirthPlace

The birthplace of the focal living subject.

classCode [1..1] (M)Birthplace (CS) {CNE:BIRTHPL}

Structural attribute; this is a "birthplace" role.

id [0..*]
Birthplace (SET<II>)

A living subject's birth place represented by a unique identifier.

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)Birthplace (CS) {CNE:BIRTHPL}

Structural attribute; this is a "birthplace" role.

LanguageCommunication

A language communication capability of the focal person

languageCode [1..1] (M)LanguageCommunication (CE){CWE:HumanLanguage}

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

preferenceInd [0..1]
LanguageCommunication (BL)An indicator specifying whether or not this language is preferred by
the focal person for the associated mode__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

201

Copyright © 2017 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
5200

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 value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201301UV02 or
PRPA_TE201302UV02 respectively
RegistrationEvent.statusCode SHALL be set to“active”
There SHALL be no InReplacementOf act
relationship for these interactions.

5205

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

5210

3.44.4.1.2.4 Web Services Types and Messages
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:

5215“add” message-> "PRPA_IN201301UV02_Message"“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:
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_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 -->__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

202

Copyright © 2017 IHE International, Inc.

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

5235

5240

5245

<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:

5250

5255

5260

…
<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 3.44.4.1.3 and3.44.4.1.4.
3.44.4.1.3 Expected Actions – PIX Manager

5265

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.

5270

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.

5275

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 Section 3.46 for the details of that transaction).
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

203

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.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":“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"

5280

5285

5290

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.1.3.1.1 Port Type

5295

5300

5305

<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:
5310

5315

5320

…

<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 soapActionRequired="false"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

204

Copyright © 2017 IHE International, Inc.

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

5325

5330
…

<operation name="PIXManager_PRPA_IN201302UV02"><wsoap12:operation soapActionRequired="false"/><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.
5335

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.1.4 Expected Actions – Document Registry

5340

5345

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

5350

5355

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

3.44.4.1.4.1.1 Port Type<portType name="DocumentRegistry_PortType">__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

205

Copyright © 2017 IHE International, Inc.

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

5365

5370

5375

<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><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.4.1.2 Bindings
SOAP 1.2 binding:
…

5380

5385

5390

5395

5400

<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 soapActionRequired="false"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="DocumentRegistry_PRPA_IN201302UV02"><wsoap12:operation soapActionRequired="false"/><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.
5405

3.44.4.1.4.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

206

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.2 Patient Identity Management – Patient Identity Merge
3.44.4.2.1 Trigger Events
5410

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)
This trigger event signals that duplicate records were resolved in a patient registry.

5415

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

5420

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 3.44.4.2.2.1 to 3.44.4.2.2.4.

5425

5430

5435

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 Section 3.44.4.2.2.2 describes the relevant data elements forthis transaction. Specific requirements for the particular actors are found in Section 3.44.4.2.3
Expected Actions.
3.44.4.2.2.1 Major Components of the Patient Registry Duplicates Resolved
Patient

5440

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

207

Copyright © 2017 IHE International, Inc.

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

5445

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
Person5450

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

5455

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:

5460

5465

•

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

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.

5470__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

208

Copyright © 2017 IHE International, Inc.

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

Figure 3.44.4.2.2-1: Message Information Model for Duplicates Resolved Message

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 to reportthat 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)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" roleid [1..*] (M)Patient (SET<II>)

Identifiers designated by various patient identity sources for the
focal person

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)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

209

Copyright © 2017 IHE International, Inc.

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

3.44.4.2.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.
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 value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201304UV02
RegistrationEvent.statusCode SHALL be set to“active”
There SHALL be an InReplacementOf act
relationshipThe 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.

5480
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).
5485

3.44.4.2.2.4 Web Services Types and Messages
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:

5490"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
Acknowledgement-> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:

5495

5500

…
<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>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

210

Copyright © 2017 IHE International, Inc.

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

5505

5510

<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:
5515

5520

…
<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 Section 3.44.4.2.3 and3.44.4.2.4.
5525

3.44.4.2.3 Expected Actions – PIX Manager
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.

5530

5535

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

5540

5545

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"__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

211

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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
5550

5555

<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
5560

5565

5570

5575

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 soapActionRequired="false"/><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
5580

Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
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.

5585

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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

212

Copyright © 2017 IHE International, Inc.

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

5590

5595

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.
A Resolve Duplicates message contains two attributes of interest:

5600

•

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

5610

5615

5620

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:
1. Records the merge. Only the subsumed and surviving patient identifiers need beremembered. A patient identifier merge affects the processing of future Registry Stored
Query [ITI-18] and Register Document Set-b [ITI-42] transactions. See ITI TF-2a:3.18.4.1.2.3.9 for details of how this message type affects results of a query transactionand Section 3.42.4.1.3.3.2 to see how it affects the Register Document Set-b [ITI-42]
transaction.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

213

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.
5625

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 the entire
recorded merge chain and return appropriate metadata.

5630

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 [ITI-18]
transaction and the Register Document Set-b [ITI-42].transaction.

3.44.4.2.4.1 Web Services Port Type and Binding Definitions
5635

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “DocumentRegistry”.
The following WSDL naming conventions SHALL apply:

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"

5640

5645

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

5650

5655

<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:5660…

<binding name="DocumentRegistry_Binding_Soap12"
type="DocumentRegistry_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

214

Copyright © 2017 IHE International, Inc.

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

5670

<operation name="DocumentRegistry_PRPA_IN201304UV02"><wsoap12:operation soapActionRequired="false"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

5675
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.
5680

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 Audit Trail and Node Authentication (ATNA) Profile. This use of the
ATNA Profile in an XDS Affinity Domain does not require a centralized XDS Affinity Domain
Audit Record Repository.

5685

5690

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

5695

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.

5700

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.4.1.1.1-1. The following
tables show items that are required to be part of the audit record for this transaction.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

215

Copyright © 2017 IHE International, Inc.

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

5705

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:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

5710__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

216

Copyright © 2017 IHE International, Inc.

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

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

the machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

Audit Source

AuditMessage/
AuditSourceIdentificati
on5715
Patient(AuditMessage/
ParticipantObjectIde
ntification)

3.44.5.1.2 Patient Identifier Cross-reference Manager 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)Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)Patient (1)Where:
SourceAuditMessage/Activ
eParticipantt

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

217

Copyright © 2017 IHE International, Inc.

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

UserID

M

SOAP endpoint URI

AuditMessage/
ActiveParticipant

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

Audit Source

AuditMessage/
AuditSourceIdentificati
on

5720
Patient(AuditMessage/
ParticipantObjectIde
ntification)

3.44.5.1.3 Document Registry audit message

5725

Document Registry audit message are the same as Patient Identifier Cross-reference Manager
audit message as presented in Section 3.44.5.1.2.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

218

Copyright © 2017 IHE International, Inc.

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

3.45 PIXV3 Query [ITI-45]
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.
5730

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

5735

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)

5740

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)

5745

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. 14.0 Final Text – 2017-07-21

219

Copyright © 2017 IHE International, Inc.

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

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

Figure 3.45.4-1: Get Corresponding Identifiers Sequence

3.45.4.1 Get Corresponding Identifiers
3.45.4.1.1 Trigger Events
5755

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 for corresponding
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.

5760

3.45.4.1.2 Message Semantics

5765

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.

5770

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. 14.0 Final Text – 2017-07-21

220

Copyright © 2017 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

5775

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 ITI TF-2x: Appendix E for the use of the II data typefor patient identifiers.
DataSource Parameter

5780

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
Message5785

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:

5790

5795

•

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•

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

221

Copyright © 2017 IHE International, Inc.

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

5800

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.
Table 3.45.4.1.2-2: Model Attributes
PRPA_HD201307IHE
Patient Registry Query by IdentifierThis HMD extract defines the message used to query apatient 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, fixedvalue="I"}

The PIX manager is required to send an immediate response.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

222

Copyright © 2017 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 to query apatient registry for a list of identifiers.
Derived from Figure 3.45.4.1.2-1 (PRPA_RM201307IHE)

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

5805

5810

5815

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

5820

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.1.2-4: 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_IN201309UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN
The trigger event code in ControlActProcess.code__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

223

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Transmission Wrapper
The value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

5825

Trigger Event Control Act Wrapper
SHALL be set to PRPA_TE201309UV02
The value of authorOrPerformer.typeCode SHALL
be set to AUT

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

5830

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.
The following WSDL naming conventions SHALL apply:

Query by Identifier -> "PRPA_IN201309UV02_Message"
Query Response-> "PRPA_IN201310UV02_Message"

5835

5840

5845

5850

5855

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_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:

5860…
<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. 14.0 Final Text – 2017-07-21

224

Copyright © 2017 IHE International, Inc.

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

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 Section 3.45.4.1.3.
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.

5870

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

5875

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"

5880

5885

The following WSDL snippets specify the PIXV3 Query Port Type and Binding definitions,according to the requirements specified in ITI TF-2x: Appendix V.
3.45.4.1.3.1.1 Port Type

5890

5895

<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
SOAP 1.2 binding:
…

5900

5905

<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 soapActionRequired="false"/><input><wsoap12:body use="literal"/>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

225

Copyright © 2017 IHE International, Inc.

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

5910
…

5915

</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.45.4.1.3.2 Message Examples
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

5920

The Patient Identifier Cross-reference Manager’s response to the Get Corresponding Identifiers
message will trigger the following message:
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

5925

5930

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

The Person class contains the name of the patient for additional verification purposes.
Provider Organization

5940

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. 14.0 Final Text – 2017-07-21

226

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________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
5945

5950

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

5955

5960

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 otheridentifiers•

All optional attributes in the Patient and Person class are removed

5965__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

227

Copyright © 2017 IHE International, Inc.

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

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

Table 3.45.4.2.2-3: Model Attributes
PRPA_HD201304IHE
PatientIdentifiersThis HMD extract defines the message used to respondto 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)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" roleid [1..*] (M)Patient (SET<II>)

Linked patient identifiers from one or more Patient Identity
Domains

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)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

228

Copyright © 2017 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 to respondto the Patient Registry Query By Identifier
Derived from Figure 3.45.4.2.2-1 (PRPA_RM201304IHE)

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person

OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Role (CS) {CNE:ROL}

Structural attribute. This can be any specialization of "role"id [1..*] (M)Role (SET<II>)

One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by aDMV)

3.45.4.2.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.
5975

Table 3.45.4.4.2-5: Wrappers and Constraints
Transmission Wrapper

5980

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 processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to NE
There SHALL be only one receiver Device

The value of ControlActProcess.moodCode SHALL
be set to EVN
The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201310UV02
There SHALL be zero or one RegistrationEvents
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-relationshippresent in this message
There SHALL be a QueryByParameter copy of theoriginal query.

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

229

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.45.4.2.2.4 Web Services Types and Messages
Since this is a response to a query, please see Section 3.45.4.1.2.4 for the web services
components of this message.
3.45.4.2.3 Expected Actions - Patient Identifier Cross-reference Manager
5985

5990

5995

6000

6005

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

6010

6015

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).
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, is__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

230

Copyright © 2017 IHE International, Inc.

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

6025

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 that is returned in theQueryByParameter parameter list (control act wrapper).
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 no
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).
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

6030

6035

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

6040

NF (no data found, no errors) is returned 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).

6045

Case 4: The Patient Identifier Cross-reference Manager does not recognize the Patient ID sent in
the PatientIdentifier.value.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
No RegistrationEvent is returned.

6050

The queried-for patient identifier is returned in the QueryByParameter parameter list (control act
wrapper).
An AcknowledgmentDetail class is returned in which the attributes typeCode, code, and location
are valued as follows.
Attribute
typeCode

VALUE
E__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

231

Copyright © 2017 IHE International, Inc.

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

6055

VALUE

code

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.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
No RegistrationEvent is returned.

6060

The queried-for patient identification domains are returned in the QueryByParameter parameter
list (control act wrapper).
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

6065

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

6070

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

6075

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

6080

The WSDL snippets for this message are shown in Section 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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

232

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.45.4.2.4 Expected Actions - Patient Identifier Cross-reference Consumer
6085

6090

6095

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).
In the case where the returned list of identifiers contains multiple identifiers for a single domain,
the Patient Identifier Cross-reference Consumer shall either use ALL of the multiple identifiers
from the given domain or it shall ignore ALL of the multiple identifiers from the given domain.
This allows Patient Identifier Cross-reference 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.

6100

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.4.1.1.1-1. The
following tables show items that are required to be part of the audit record for this transaction.
3.45.5.1.1 Patient Identifier Cross-reference 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-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:
SourceAuditMessage/
ActiveParticipant

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

233

Copyright © 2017 IHE International, Inc.

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

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

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.

6105
Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination

AuditMessage/
ActiveParticipant

Audit Source

AuditSourceIDU

not specialized

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Patient

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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)

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

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded(AuditMessage/
ParticipantObjectIdentif
ication)Query
Parameters(AuditMessage/
ParticipantObjectIdentif
ication)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

234

Copyright © 2017 IHE International, Inc.

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

6110

U

not 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

Audit Source
AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format (see ITI TF-2x: Appendix E).

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

235

Copyright © 2017 IHE International, Inc.

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

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

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

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

6115
Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

236

Copyright © 2017 IHE International, Inc.

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

3.46 PIXV3 Update Notification [ITI-46]
6120

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.
3.46.1 Scope
The scope is identical to the scope of transaction ITI-10, described in ITI TF-2a: 3.10.1.
3.46.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIXV3 Update
Notification

6125

Actor: Patient Identifier Cross-reference Manager

6130

Role: It serves a well-defined set of Patient Identification Domains. The Patient Identifier Crossreference Manager manages the cross-referencing of patient identifiers across Patient
Identification Domains by providing a list of patient ID “aliases” via notification to a configured
list of interested Patient Identifier Cross-reference Consumers.
Corresponding HL7 v3 Application Roles:
Patient Registry Informer (PRPA_AR201301UV02)
Actor: Patient Identifier Cross-reference Consumer6135

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.
Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)
3.46.3 Referenced Standards

6140

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. 14.0 Final Text – 2017-07-21

237

Copyright © 2017 IHE International, Inc.

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

Patient Identifier
Cross-Reference
Consumer

Patient Identifier
Cross-ReferenceManager

Patient Registry Record Revised
PRPA_IN201302UV02

6145

Figure 3.46-1: Update Patient Information Sequence

3.46.4.1 Update Patient Information
3.46.4.1.1 Trigger Events
6150

6155

The Patient Identifier Cross-reference Manager shall notify a Patient Identifier Cross-reference
Consumer when there is a change in a set of cross-referenced patient identifiers for any of thepatient identifiers belonging to Patient Identifier Domains of interest to the consumer. The
configuration of the domains of interest to a Patient Cross-reference Consumer is maintained by
the Patient Cross-reference Manager.
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)

6160

This trigger event signals that patient information was revised in a patient registry.
3.46.4.1.2 Message Semantics
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.

6165

Each message shall be acknowledged by the HL7 V3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

238

Copyright © 2017 IHE International, Inc.

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

6170

6175

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 otherone containing the patient identifier for DOM_AD.

6180

6185

6190

6195

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

6200

3.46.4.1.2.1 Major Components of the Patient Registry Record Revised
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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

239

Copyright © 2017 IHE International, Inc.

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

The Person class contains the name of the patient for additional verification purposes.
Provider Organization

6210

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

6215

6220

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 value6225

3.46.4.1.2.2 Message Information Model of the Patient Registry Record Revise
Message
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.

6230

6235

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 Section 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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

240

Copyright © 2017 IHE International, Inc.

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

Figure 3.46.4.1.2-1: Message Information Model for the Patient Identifiers Message

6240

The attributes of this model are described in the following table.
Table 3.46.4.1.2-4: Model Attributes
PRPA_HD201302IHE
PatientRevise

This HMD extract defines the message used to send 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)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" roleid [1..*] (M)Patient (SET<II>)

Linked identifiers from one or more Identity Domains

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)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

241

Copyright © 2017 IHE International, Inc.

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

This HMD extract defines the message used to send a
Patient Update Notification
Derived from Figure 3.46.4.1.2-1 (PRPA_RM201302IHE)

OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Role (CS) {CNE:ROL}

Structural attribute. This can be any specialization of "role"id [1..*] (M)Role (SET<II>)

One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by aDMV)

3.46.4.1.2.3 Control Act and Transmission Wrappers

6245

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

6250

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 value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201302UV02
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 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.

6255

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:
6260…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema -->__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

242

Copyright © 2017 IHE International, Inc.

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

6270

6275

6280

6285

<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 3.46.4.1.3.
6290

6295

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 apatient, 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.
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.

6300

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.

6305

3.46.4.1.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXConsumer”.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

243

Copyright © 2017 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="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"

6310

6315
The following WSDL snippets specify the Patient Update Port Type and Binding definitions,according to the requirements specified in ITI TF-2x: Appendix V.
3.46.4.1.3.1.1 Port Type
6320

6325

<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
6330

6335

6340

6345

SOAP 1.2 binding:…

3 <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 soapActionRequired="false"/><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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

244

Copyright © 2017 IHE International, Inc.

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

6350

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.4.1.1.1-1. The following
tables show items that are required to be part of the audit record for this transaction.

6355

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”)

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

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:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

6360__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

245

Copyright © 2017 IHE International, Inc.

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

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

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.

Audit Source

AuditSourceIDU

not specialized

AuditMessage/
AuditSourceIdentificati
on

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Patient IDs

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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(AuditMessage/
ParticipantObjectIde
ntification)

3.46.5.1.2 Patient Identifier Cross-reference Consumer audit message:
Event

AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCodeM“U” (update)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

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)

6365

Where:
SourceAuditMessage/
ActiveParticipant__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

246

Copyright © 2017 IHE International, Inc.

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

Destination

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient IDs(AuditMessage/
ParticipantObjectIde
ntification)

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

the machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

6370

3.47 Patient Demographics Query HL7 V3 [ITI-47]

6375

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 Supplier
Actors. Additional components to be included if the Pediatric Demographics Option is supported
are also indicated in Sections 3.47.4.1.2.1 to 3.47.4.1.2.4.
3.47.1 Scope
The scope is identical to ITI TF-2a: 3.21.1.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

247

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.2 Use Case Roles
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient
Demographics
Query HL7 V3

6380

Actor: Patient Demographics Consumer
Role: Requests a list of patients matching a minimal set of demographic criteria (e.g., ID or
partial name) from the Patient Demographics Supplier. Populates its attributes with demographic
information received from the Patient Demographics Supplier.
Corresponding HL7 v3 Application Roles:

6385

Person Registry Query Placer (PRPA_AR201303UV02)
Actor: Patient Demographics SupplierRole: Returns demographic information for all patients matching the demographic criteria
provided by the Patient Demographics Consumer.
Corresponding HL7 v3 Application Roles:

6390

Person Registry Query Fulfiller (PRPA_AR201304UV02)
3.47.3 Referenced Standards
HL7 Version 3 Edition 2008, Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008)

6395

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

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

248

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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

6400

3.47.4.1 Patient Demographics Query
3.47.4.1.1 Trigger Events
A Patient Demographics Consumer’s need to select a patient based on demographic information
about patients whose information matches a set of known data will trigger the Patient
Demographics Query based on the following HL7 trigger event:

6405

Find Candidates Query (PRPA_TE201305UV02)
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

6410

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. 14.0 Final Text – 2017-07-21

249

Copyright © 2017 IHE International, Inc.

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

6415

6420

6425

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 Sections 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 Section 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

6430

6435

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

6440

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

6445

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

6450

This optional parameter specifies one or more addresses associated with the person whose
information is being queried.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

250

Copyright © 2017 IHE International, Inc.

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

6455

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 ITI TF-2x: Appendix E for the use of the II data type for patient identifiers.
OtherIDsScopingOrganization Parameter

6460

6465

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

6470

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

6475

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

6480

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

6485

This optional parameter specifies the primary telephone number or email address of the person
whose information is being queried.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

251

Copyright © 2017 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
6490

6495

6500

6505

6510

6515

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.
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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

252

Copyright © 2017 IHE International, Inc.

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

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:
Table 3.47.4.1.2-1: Model Attributes
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used to query apatient registry for records matching a set of
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. 14.0 Final Text – 2017-07-21

253

Copyright © 2017 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 to query apatient registry for records matching a set of
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 apatient. There shall be only a single PatientAddress element

PatientAddress__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

254

Copyright © 2017 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 to query apatient registry for records matching a set of
demographics information.
Derived from Figure 3.47.4.1.2-1 (PRPA_RM201306IHE)

value [1..*]
ParameterItem (AD)Multiple instances of the value element within a Patient Address
may be specified and are combined with OR logic.

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"}6525
When Pediatric 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]
ParameterItem (PN)

Design Comments: A person name. In this case it may consist of
only the given name part, the family name part, or both.

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. There shall be only a single
PatientTelecom element.

value [1..*]
ParameterItem (TEL)

Design Comments: A telecommunications address. The scheme
attribute specifies whether this is a telephone number, fax number,email address, etc. Multiple instances of the value element within a
PatientTelecom may be specified and are combined with OR logic.

3.47.4.1.2.3 Control Act and Transmission Wrappers

6530

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. 14.0 Final Text – 2017-07-21

255

Copyright © 2017 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

6535

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 processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

The value of ControlActProcess.moodCode SHALL
be set to EVN
The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201305UV02
If an authorOrPerformer participation is present, thevalue of authorOrPerformer.typeCode SHALL be set
to AUTThe 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
The Patient Registry Query by Demographics message will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.

6540

The following WSDL naming conventions SHALL apply:
query message-> "PRPA_IN201305UV02_Message"

The following WSDL snippet describes the type for this message:

6545

6550

6555

6560

…
<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:…
<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
3.47.4.2.3.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

256

Copyright © 2017 IHE International, Inc.

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

3.47.4.1.3.1 Immediate Response
The Patient Demographics Supplier shall immediately return a Find Candidates Response
message as specified below in Section 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.

6570

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.

6575

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.
3.47.4.1.3.3 Incremental Response Processing

6580

6585

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.
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 Section 3.47.4.3.
3.47.4.1.3.4 Web Services Port Type and Binding Definitions
These definitions are part of the query response message. Please see Section 3.47.4.2.3 for more
information.

6590

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
3.47.4.2.1 Trigger Events

6595

The Patient Demographics Supplier’s response to the Find Candidates Query message istriggered by the following trigger:
Find Candidates Response (PRPA_TE201306UV02)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

257

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.
6600

6605

3.47.4.2.2 Message Semantics
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 Sections
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

6610

This message shares all the major components of the Patient Activate/Revise messages, as
described in Section 3.44.4.1.2.1. The only additional component is the QueryMatchObservation
class.
Query Match Observation
The QueryMatchObservation class is used to convey information about the quality of the matchfor each record returned by the query response.

6615

6620

3.47.4.2.2.2 Message Information Model of the Patient Registry Find Candidates
Response Message
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:

6625

6630

•

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

258

Copyright © 2017 IHE International, Inc.

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

6635
•

6640

•

contactParty•

asMember•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

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. 14.0 Final Text – 2017-07-21

259

Copyright © 2017 IHE International, Inc.

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

Table 3.47.4.2.2-8: Model Attributes
PRPA_HD201310IHE
Patient Registry Find Candidates Response

This HMD extract defines the message
used to return records from a patientregistry 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)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" roleid [1..*] (M)Patient (SET<II>)

Patient identifiers. Patient Identifiers fromdifferent Identity Domains may be contained
either here, or in the OtherIDs.id attributes, but
not in both places. At least one Patient Identifier
shall be present in this attributestatusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in apatient registry (based on the RIM role classstate-machine). This record is active.

confidentialityCode [0..*]Patient (SET<CE>) {CWE:Confidentiality}

Value(s) that control the disclosure of
information about this living subject as a patient

veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status
granted by the scoper organization, often
resulting in preferred treatment and special
considerations. Examples include board
member, diplomat.

PersonA subtype of LivingSubject representing ahuman being
Either Person.name or Patient.id must be nonnull

classCode [1..1] (M)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person

telecom [0..*]
Person (BAG<TEL>)

Telecommunication address(es) for
communicating with this person

administrativeGenderCode [0..1]
Person (CE) {CWE:AdministrativeGender}

A value representing the gender (sex) of thisperson. Note: this attribute does not include
terms related to clinical gender which is acomplex physiological, genetic and sociologicalconcept that requires multiple observations inorder to be comprehensively described.

birthTime [0..1]
Person (TS)The date and time this person was born

deceasedInd [0..1]
Person (BL)An indication that this person is dead__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

260

Copyright © 2017 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 to return records from a patientregistry in response to a Find
Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

deceasedTime [0..1]
Person (TS)The date and time this person diedmultipleBirthInd [0..1]
Person (BL)An indication that this person was part of amultiple birthmultipleBirthOrderNumber [0..1]
Person (INT)The order in which this person was born if partof a multiple birth

addr [0..*]
Person (BAG<AD>)

Address(es) for corresponding with this person

maritalStatusCode [0..1]
Person (CE) {CWE:MaritalStatus}

A value representing the domestic partnershipstatus of this person

religiousAffiliationCode [0..1]
Person (CE) {CWE:ReligiousAffiliation}

A value representing the primary religious
preference of this person

raceCode [0..*]
Person (SET<CE>) {CWE:Race}

A set of values representing the races of thispersonethnicGroupCode [0..*]
Person (SET<CE>) {CWE:Ethnicity}

A set of values representing the ethnic groups ofthis person

OtherIDs

Used to capture additional identifiers for the
person such as a Drivers’ license or Social
Security Number.

classCode [1..1] (M)Role (CS) {CNE:ROL}

Structural attribute. This can be any
specialization of "role" except for Citizen, or
Employee.,id [1..*] (M)Role (SET<II>)

One or more identifiers issued to the focal
person by the associated scopingOrganization(e.g., identifiers from a different Patient Identity
Domain).

PersonalRelationship

A personal relationship between the focal living
subject and another living subject

classCode [1..1] (M)Role (CS) {CNE:PRS, fixed value= "PRS"}

Structural attribute; this is a "personal
relationship" role

id [0..*]
Role (SET<II>)

Identifier(s) for this personal relationshipcode [1..1] (M)Role (CE) {CWE:PersonalRelationshipRoleType}A required value specifying the type of personal
relationship between the relationshipHolder andthe scoping living subject drawn from the
PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

CitizenUsed to capture person information relating tocitizenship.

classCode [1..1] (M)Role (CS) {CNE:CIT, fixed value= "CIT"}

Structural attribute; this is a "citizen" role__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

261

Copyright © 2017 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 to return records from a patientregistry in response to a Find
Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

id [0..*]
Role (SET<II>)

Identifier(s) for the focal person as a citizen of anationNationA politically organized body of people bonded
by territory and known as a nation.

classCode [1..1] (M)Organization (CS) {CNE:NAT, fixed value= "NAT"}

Structural attribute; this is a 'nation' type ofentitydeterminerCode [1..1] (M)Organization (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}

Structural attribute; this is a specific entity

code [1..1] (M)Organization (CD) {CWE:NationEntityType}A value that identifies a nation statename [0..1]
Organization (ON)A non-unique textual identifier or moniker forthis nation

Employee

A relationship of the focal person with anorganization 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 nature of the work actually
performed. For example, it can be used tocapture whether the person is a Military Veteranor not..

classCode [1..1] (M)Employee (CS) {CNE:EMP}

Structural attribute; this is an "employee" role

statusCode [0..1]
Employee (CS) {CNE:RoleStatus}

A value specifying the state of this employment
relationship (based on the RIM Role class statemachine), for example, active, suspended,
terminated.

occupationCode [0..1]
Employee (CE) {CWE:EmployeeOccupationCode}A code qualifying the classification of kind-ofwork based upon a recognized industry or
jurisdictional standard. OccupationCode is used
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.

LanguageCommunication

A language communication capability of the
focal person

languageCode [1..1] (M)LanguageCommunication (CE) {CWE:HumanLanguage}

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, AmericanSign

preferenceInd [0..1]
LanguageCommunication (BL)An indicator specifying whether or not thislanguage is preferred by the focal person for the
associated mode__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

262

Copyright © 2017 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 to return records from a patientregistry in response to a Find
Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

QueryMatchObservation

Used to convey information about the quality ofthe match for each record.

classCode [1..1] (M)Observation (CS)
{CNE:http://hl7.org/v3ballot2007may/html/infrastruc

Structural attribute – this is an observation

ture/vocabulary/ActClass.htm - ActClass, default="OBS"}

moodCode [1..1] (M)Observation (CS)
{CNE:http://hl7.org/v3ballot2007may/html/infrastruc

Structural attribute – this is an event

ture/vocabulary/ActMood.htm - ActMood, default="EVN"}

code [1..1] (M)Observation (CD) {CWE:QueryMatchObservationType}A code, identifying this observation as a querymatch observation.

value [1..1] (M)QueryMatchObservation (INT)

A numeric value indicating the quality of matchfor 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).

3.47.4.2.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.
6650

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)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

263

Copyright © 2017 IHE International, Inc.

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

6655

Transmission Wrapper

Trigger Event Control Act Wrapper

The value of interactionId SHALL be set to
PRPA_IN201306UV02
The value of processingModeCode SHALL be set
to T
The acceptAckCode SHALL be set to NE
There SHALL be only one receiver Device

The value of ControlActProcess.moodCode SHALL be set
to EVNThe trigger event code in ControlActProcess.code SHALL
be set to PRPA_TE201306UV02
There SHALL be zero or more RegistrationEvents present
in this message.
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.

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.

6660

The following WSDL naming conventions SHALL apply:
response message-> "PRPA_IN201306UV02_Message"

The following WSDL snippet describes the type for these message:
6665

6670

…
<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"/></xsd:schema></types>…

The message is described by the following snippet:
6675…
<message name="PRPA_IN201306UV02_Message"><part element="hl7:PRPA_IN201306UV02" name="Body"/></message>…

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

264

Copyright © 2017 IHE International, Inc.

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

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.

6685

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.
The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier and are outside of the scope of this framework.

6690

6695

The Patient Demographics Supplier shall respond to the query request as described by thefollowing 3 cases:
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)

6700

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.

6705

6710

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 theresultTotalQuantity, resultCurrentQuantity, and resultRemainingQuantity attributes of theQueryAck class in the control act wrapper. If the Supplier does not support the Continuation
Option, in addition to returning only up to the incremental number of records requested, it shallreturn AE (application error in the Acknowledgement.typeCode (transmission wrapper) and AE(application error) is returned in QueryAck.queryResponseCode (control act wrapper).
The Consumer may then send a query continuation message as a subsequent query request for
the next increment of responses.

6715

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 the__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

265

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
criteria 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).
6720

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)
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.

6725

6730

6735

6740

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.

6745

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 identification domains are returned in the QueryByParameter parameter
list (control act wrapper).

6750

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)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

266

Copyright © 2017 IHE International, Inc.

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

VALUE

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
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PDSupplier”.
6755

6760

6765

The following WSDL naming conventions SHALL apply:

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

6775

6780

6785

6790

3.47.4.2.3.1.1 Port Type<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></portType>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

267

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.2.3.1.2 Bindings
SOAP 1.2 binding:
6795

6800

6805

6810

6815

6820

6825

…

<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 soapActionRequired="false"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Continue"><wsoap12:operation soapActionRequired="false"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Cancel"><wsoap12:operation soapActionRequired="false"/><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.
6830

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.
3.47.4.3 Patient Demographics Query HL7V3 Continuation
3.47.4.3.1 Trigger Events

6835

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:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

268

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Query General Activate Query Continuation (QUQI_TE000003UV01)

6840

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.
3.47.4.3.2 Message Semantics

6845

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.

6850

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

6855

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

6860

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

6865

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__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

269

Copyright © 2017 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
QUQI_IN000003UV01
The value of processingModeCode SHALL be set to T
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 trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE000003UV01
QueryContinuation.queryId SHALL be set to theoriginal query identifier

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)
6870

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

6875

6880

6885

-> "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:
6890

6895

…
<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
3.47.4.2.3.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

270

Copyright © 2017 IHE International, Inc.

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

6900

6905

6910

6915

6920

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 Suppliershall return an incremental response of that number of records when the number of matchingrecords it finds exceeds the number of records specified. In subsequent query continuation
messages, the Patient Demographics Consumer may specify a different number of records 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 bypopulating the startResultNumber attribute. If the Patient Demographics Supplier does notsupport 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, theSupplier 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
Section 3.47.4.2.3.1.

6925

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.
3.47.5 Security Requirements

6930

No transaction specific security considerations.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

271

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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.4.1.1.1-1. The
following tables show items that are required to be part of the audit record for this transaction.
6935

3.47.5.1.1 Patient Demographics 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-47”, “IHE Transactions”, “Patient Demographics Query”)

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

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

6940__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

272

Copyright © 2017 IHE International, Inc.

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

Destination

UserID

M

SOAP endpoint URI

AuditMessage/
ActiveParticipant

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

Audit Source

AuditMessage/
AuditSourceIdentificati
on6945
Patient(AuditMessage/
ParticipantObjectIde
ntification)

Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

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:
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-47”, “IHE Transactions”, “Patient Demographics Query”)

Source (Patient Demographics Consumer) (1)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

273

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Supplier) (1)Patient (0..n)Query Parameters (1)6950

Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

the machine name or IP address.

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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 specialized6955__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

274

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

3.48 Retrieve Value Set [ITI-48]
6960

This section corresponds to transaction ITI-48 of the IHE IT Infrastructure Technical
Framework. The Value Set Consumer and Value Set Repository Actors use transaction ITI-48.
3.48.1 Scope

6965

This transaction is used by the Value Set Consumer to retrieve an Expanded Value Set from theValue Set Repository. The Value Set Consumer has previously obtained the Expanded Value Set
OID by means outside of the scope of this transaction. ITI TF-2x: Appendix B has further
information about obtaining and managing OIDs which are used as the Value Set Unique ID.
3.48.2 Use case roles
Value Set
Consumer

Value Set Repository

Retrieve
Expanded Value
Set

6970
Figure 3.48.2-1: Use Case RolesSVS Actors:
Actor: Value Set Consumer
Role: Obtains an Expanded Value Set
6975

Actor: Value Set Repository
Role: Provides an Expanded Value Set__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

275

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.48.3 Referenced Standards
Appendix V

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

HL7 v3 Data Type XML ITS

HL7 Version 3 Standard: XML Implementation Technology Specifications – Data Types,
R1

HTTP 1.1

IETF RFC2616: Hypertext Transfer Protocol – HTTP 1.1

3.48.4 Interaction Diagram
6980
Value Set
Repository

Value Set
Consumer
Retrieve Value Set Request

Retrieve Value Set Response

Figure 3.48.4-1: Interaction Diagram

3.48.4.1 Retrieve Value Set Request
3.48.4.1.1 Trigger Events
6985

Having obtained the Value Set OID, the Value Set Consumer will send the Retrieve Value Set
Request to the Value Set Repository.
3.48.4.1.2 Message Semantics
The Retrieve Value Set Request shall carry the following information:

6990

6995

•

A required id, representing the Value Set OID that identifies the Expanded Value Set
within the Repository.

•

An optional version that identifies a specific version of the Expanded Value Set. If no
version is specified, the Value Set Consumer is requesting the most recent version of theValue Set•

An optional lang parameter indicating the requested language locale for the
displayName of the Value Set Concepts. (Note: in the SOAP binding, this parameteris represented via the xml:lang XML attribute)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

276

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Section 3.48.5 describes the Web Services protocol requirements and the format of the message
in full detail.
3.48.4.1.3 Expected Actions
7000

7005

When receiving a Retrieve Value Set Request, a Value Set Repository shall generate a Retrieve
Value Set Response containing the Expanded Value Set that corresponds to the request
parameters or an error code if the Value Set could not be retrieved. If no version is specified in
the Request, then the most recent version shall be returned.
The Value Set Repository shall support both the SOAP and HTTP bindings for this transaction.
If the Value Set Consumer sends the request using the SOAP binding, the Value Set Repository
shall respond using the SOAP binding. If the Value Set Consumer sends the request using the
HTTP binding, the Value Set Repository shall respond using the HTTP binding.
3.48.4.2 Retrieve Value Set Response
3.48.4.2.1 Trigger Events

7010

This message will be triggered by a Retrieve Value Set Request Message.
3.48.4.2.2 Message Semantics
The Retrieve Value Set Response Message shall carry the following information for the returned
Expanded Value Set:

7015

7020

7025

•

A required id, representing the Value Set OID that identifies the Value Set within the
Value Set Repository. This OID shall be the same as the Value Set OID in the received
Retrieve Value Set Request Message.

•

A required displayName that can be used for display purposes.

•

An optional version that shall be present if the Expanded Value Set has a version, that
identifies the specific version of the Value Set returned.

•

An optional cacheExpirationHint indicating that the Value Set Consumer is notexpected to change before this date and time. If the request and the response use the
HTTP binding, this information shall be also present in the HTTP Expire header of the
response. For details, please see Sec. 14.21 of IETF RFC2616.

•

One or more ConceptList, which provides the Concepts of the Expanded Value Set.
If there are multiple translations of the Value Set, each translation is returned as aseparate ConceptList, where only the displayName of each Concept, and thelanguage locale represented by xml:lang are different.

For each Value Set Concept, the following is returned. These requirements override therequirements of the HL7 schema rules for the CE data type where they conflict.
7030•

A required code (a code that uniquely identifies a class or concept within the context ofa code system)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

277

Copyright © 2017 IHE International, Inc.

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

7035

•

A required displayName (the name of the concept)•

A required codeSystem (the terminology the concept comes from)•

An optional codeSystemVersion. (the version of the terminology the concept comesfrom)

Section 3.48.5 describes the Web Services requirements and the format of the message in fulldetail.
3.48.4.2.3 Expected Actions
A Value Set Repository shall return the Expanded Value Set indicated in the request.
7040

7045

If the Value Set Consumer requested a specific language locale, the Value Set Repository shallreturn only the requested translation of the Expanded Value Set. If the Value Set Consumer did
not request a specific language locale, the Value Set Repository shall return all known
translations of the Expanded Value Set. This is the only case where more than one ConceptList
XML element shall be permitted. The ConceptList shall have the same code values for the Value
Set in question; the displayName may have a different value appropriate to the locale.
The Value Set Repository shall return the Expanded Value Set or an error code in case the Value
Set could not be expanded. The following error responses may be returned:
1. For the SOAP binding:

7050

a. A SOAP fault, whose code value is NAV, with the reason being: “Unknown valueset”.
b. A SOAP fault, whose code value is VERUNK, with the reason being: “Version
unknown”.
2. For the HTTP binding:7055

a. An HTTP status code of 404, with an HTTP Warning header containing warncode of 111, and warn-text of “NAV: Unknown value set”. See sections 10.4.5
and 14.46 of IETF RFC2616 for more information.
b. An HTTP status code of 404, with an HTTP Warning header containing warncode of 112, and warn-text of “VERUNK: Version unknown”. See sections 10.4.5
and 14.46 of IETF RFC2616 for more information.

7060

3.48.5 Protocol Requirements
The protocol for the Retrieve Value Set transaction describes two bindings. The first is based on
SOAP 1.2, and the second is an HTTP binding. The relevant XML namespace definitions can beseen in Table 3.48.5-1 WSDL Namespace Definitions.
Table 3.48.5-1: WSDL Namespace Definitions
soap12

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

wsaw

http://www.w3.org/2006/05/addressing/wsdl/__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

278

Copyright © 2017 IHE International, Inc.

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

7065

xsd

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

ihe

urn:ihe:iti:svs:2008

3.48.5.1 SOAP Binding
Value Set Consumers which support the SOAP Binding Option shall follow the rules for Web
Services transactions outlined in ITI TF-2x: Appendix V. These are the requirements for the
Retrieve Value Set transaction presented in the order in which they would appear in the WSDL
definition:

7070

The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:iti:svs:2008", schema="SVS.xsd"
The /definitions/message/part/@element attribute of the Retrie3ve Value Set
Request message shall be defined as “ihe:RetrieveValueSetRequest”

7075

The /definitions/message/part/@element attribute of the Retrieve Value Set
Response message shall be defined as “ihe:RetrieveValueSetResponse”
The /definitions/portType/operation/input/@wsaw:Action attribute for the
Retrieve Value Set Request message shall be defined as“urn:ihe:iti:2008:RetrieveValueSet”

7080

7085

The /definitions/portType/operation/output/@wsaw:Action attribute for the
Retrieve Value Set Response message shall be defined as“urn:ihe:iti:2008:RetrieveValueSetResponse”
The/definitions/binding/operation/soap12:operation/@soapActionRequi
red attribute shall be defined as “false”

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 Section 3.48.5.3 Sample SOAP Message.

Within the request message payload the <ihe:RetrieveValueSetRequest/> element isdefined as:
7090

7095

•

A required /ihe:RetrieveValueSetRequest/ihe:ValueSet element•

A required /ihe:RetrieveValueSetRequest/ihe:ValueSet@id attributethat contains the ID of the requested Value Set within the Value Set Repository. The
Value Set ID shall be formatted as an ISO OID.

•

An optional/ihe:RetrieveValueSetRequest/ihe:ValueSet@displayName attribute•

An optional /ihe:RetrieveValueSetRequest/ihe:ValueSet@version
attribute.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

279

Copyright © 2017 IHE International, Inc.

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

An optional /ihe:RetrieveValueSetRequest/ihe:ValueSet@xml:lang
attribute.

Value Set Repositories shall include within the response message payload for the SOAP Binding
Option the <ihe:RetrieveValueSetResponse/> element which contains:An optional /ihe:RetrieveValueSetResponse@cacheExpirationHint attribute,indicating that the Value Set Consumer should obtain a new copy before this date and time.
A required /ihe:RetrieveValueSetResponse/ihe:ValueSet element, containing

7105

7110

7115

•

a required /ihe:RetrieveValueSetResponse/ihe:ValueSet@id attribute•a required/ihe:RetrieveValueSetResponse/ihe:ValueSet@displayName attribute•an optional /ihe:RetrieveValueSetResponse/ihe:ValueSet@version
attribute•one or more/ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:ConceptList
element, containing:•/ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:ConceptList/
xml:lang attribute, representing the language locale of the Concept’s display names•

one or more/ihe:RetrieveValueSetResponse/ihe:ValueSet/ihe:ConceptList/
ihe:Concept elements, representing the concepts within the value set.

The <ihe:Concept/> element is defined as being of the HL7 V3 CE data type.
7120

The only occurrence of more than one ConceptList element in a response message shall be
for the purpose of returning multiple language representations of the same value set.
A full XML Schema Document for the SVS types is available on the IHE ftp site (see ITI TF-2x:
Appendix W).
3.48.5.2 HTTP Binding

7125

Value Set Consumers which support the HTTP Binding Option shall use the GET method as
defined in IETF RFC2616 for the Retrieve Value Set Request.
3.48.5.2.1 Request Parameters
There are three input parameters, to be provided as part of the URL in the GET request. The
parameter values have identical meaning to the ones described in the SOAP binding. These aredescribed in Table 3.48.5.2.1-1.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

280

Copyright © 2017 IHE International, Inc.

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

Table 3.48.5.2.1-1: The Request Parameters in the RetrieveMultipleValueSets request
Parameter

Optionality

Note

Id

Required

Unique identifier of the Value Set.

VersionOptional

The Value Set version.

lang

Optional

The language locale of the Value Set. If present, it shall be encoded as astring from the set of languages listed in IETF RFC5646 (identical to thevalues of xml:lang, described in the SOAP binding). If present, theAccept-Language field of the HTTP Header may also contain the samevalue (see Section 14.4 of IETF RFC2616).

The full URL for the HTTP binding looks as follows:

7135

https://example.com/RetrieveValueSet?id=1.2.840.10008.6.1.3
08&version=20061023&lang=en-US
Note:“en-US” will not match “en”. For applications that need a more sophisticated user sensitive language matchingcapability, omitting the lang parameter will return all languages so that the application can make a determinationof which language best fits the current user.

3.48.5.2.2 HTTP Response
7140

Value Set Repositories shall format the response to the HTTP GET operation as an HTTP
response message as defined in IETF RFC2616.
The Content-Type field of the HTTP header shall be “text/xml” (see Section 14.4 of IETF
RFC2616).

7145

The content of the HTTP response message shall be an XML encoded Expanded Value Set thatcomplies with the SVS schema. The XML format shall be identical to the body of the SOAP
response described in the SOAP binding. The Expanded Value Set shall correspond to the
Values Set identified by the Value Set Unique ID in the id parameter, the Value Set Version in
the version parameter, and the language in the lang parameter.
An informative WSDL file containing both SOAP and HTTP bindings for the Value Set
Repository can be found on the IHE ftp site (see ITI TF-2x: Appendix W).

7150

3.48.5.3 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its corresponding
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.

7155

All of the samples presented in this section are also available online on the IHE FTP site (see ITI
TF-2x: Appendix W).
3.48.5.3.1 Sample Retrieve Value Set SOAP Request__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

281

Copyright © 2017 IHE International, Inc.

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

7165

7170

7175

<?xml version="1.0" encoding="UTF-8"?><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:2008:RetrieveValueSet</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://valuesetrepository/</a:To></s:Header><s:Body><RetrieveValueSetRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ihe:iti:svs:2008"><ValueSet id="1.2.840.10008.6.1.308" xml:lang="en-EN"/></RetrieveValueSetRequest></s:Body></s:Envelope>

3.48.5.3.2 Sample Retrieve Value Set SOAP Response
7180

7185

7190

7195

7200

7205

7210

7215

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2008:RetrieveValueSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveValueSetResponse xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns="urn:ihe:iti:svs:2008" cacheExpirationHint="2008-08-15T00:00:0005:00"><ValueSet id="1.2.840.10008.6.1.308"
displayName="Common Anatomic Regions Context ID 4031"
version="20061023"><ConceptList xml:lang="en-US"><Concept code="T-D4000" displayName="Abdomen"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="R-FAB57" displayName="Abdomen and Pelvis"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-15420" displayName="Acromioclavicular joint"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-15750" displayName="Ankle joint "codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-280A0" displayName="Apex of Lung"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-D8200" displayName="Arm"codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-60610" displayName="Bile Duct"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-74000" displayName="Bladder"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-04000" displayName="Breast"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-26000" displayName="Bronchus"
codeSystem="2.16.840.1.113883.6.5"/>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

282

Copyright © 2017 IHE International, Inc.

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

7220<Concept code="T-12770" displayName="Calcaneus"
codeSystem="2.16.840.1.113883.6.5"/><Concept code="T-11501" displayName="Cervical spine"
codeSystem="2.16.840.1.113883.6.5"/></ConceptList></ValueSet></RetrieveValueSetResponse></s:Body></s:Envelope>7225

3.48.6 Security Requirements
For security considerations please consult ITI TF-1: 21.4.
Audit trails shall be configurable to record access to a selected list of Value Sets.
3.48.6.1 Audit Record Considerations

7230

The Retrieve Value Set transaction is an Import/Export event as defined in ITI TF-2a: Table
3.20.4.1.1.1-1with the following exceptions.
3.48.6.1.1 Value Set Consumer audit message:
Field Name
Event

AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create) or “U” (Update)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-48”, “IHE Transactions”, “Retrieve Value Sets”) or
EV(“ITI-60”,”IHE Transactions”,”Retrieve Multiple Value Sets”)

Source (Value Set Repository) (1)
Human Requestor (0..n)
Destination (Value Set Consumer) (1)Audit Source (Value Set Consumer) (1)ValueSetInstance (1)Where:
SourceAuditMessage/
ActiveParticipant

UserID

M

Repository HTTP or 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.

7235__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

283

Copyright © 2017 IHE International, Inc.

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

Human
Requestor(if known)
AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
onValue Set
Instance(AuditMessage/
ParticipantObjectIde
ntification)

7240

UserIDU

not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (Report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <Value Set Unique ID>

ParticipantObjectNameO

The value of <Value Set name>

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailO

The value of <Value Set Version>

3.48.6.1.2 Value Set 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-48”, “IHE Transactions”, “Retrieve Value Sets”) or
EV(“ITI-60”,”IHE Transactions”,”Retrieve Multiple Value Sets”)

Source (Value Set Repository) (1)
Human Requestor (0..n)
Destination (Value Set Consumer) (1)Audit Source (Value Set Source) (1)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

284

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ValueSetInstance (1)Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Human
Requestor (ifknown suchas through
XUA)
AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
on7245
Value Set
Instance(AuditMessage/
ParticipantObjectIde
ntification)

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

UserID

M

AlternativeUserID

U

Repository HTTP or SOAP endpoint URIUserNameUnot 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.

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (Report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <Value Set Unique ID>

ParticipantObjectNameO

The value of <Value Set name>

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

The value of <Value Set Version>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

285

Copyright © 2017 IHE International, Inc.

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

3.49 Convey Printed Referral Request [ITI-49]
This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow(XDW) Profile.
7250

3.50 Request Referral [ITI-50]
This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow(XDW) Profile.

3.51 Multi-Patient Stored Query [ITI-51]
7255

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
The Multi-Patient Stored Query supports a variety of queries for multiple patients. It is based on
the Registry Stored Query [ITI-18] transaction. The main difference is the set of queries, whichis specified in this transaction.

7260

3.51.2 Use Case Roles
Document
ConsumerDocument
Registry

Multi-patientStored Query

Actor: Document Consumer
Role: Issues a Multi-Patient Stored Query to retrieve metadata based on criteria common tomultiple patients
7265

Actor: Document Registry
Role: Responds to a Multi-Patient Stored Query by providing the metadata or object referencesof registry objects which satisfy the query parameters3.51.3 Referenced Standard

7270

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

ebRS

OASIS ebXML Registry Services Specifications v3.0

ITI TF-2a: 3.18 Registry Stored Query [ITI-18]__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

286

Copyright © 2017 IHE International, Inc.

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

Metadata used in Document Sharing profiles

3.51.4 Interaction Diagram
Document
ConsumerDocument
Registry

Multi-Patient Stored
Query Request
Multi-Patient Stored
Query Response

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:
7280•

A reference to a pre-defined query stored on the Document Registry Actor•

Parameters to the query

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).
7285

3.51.4.1.2 Message Semantics
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.

7290

Document Consumer and Document Registry Actors that support the Asynchronous Web
Services Exchange Option shall support Asynchronous Web Services requirements as defined in
ITI TF-2x: V.5.
3.51.4.1.2.1 Query Definitions
This transaction defines the following Stored Queries that may query for multiple Patient Ids.
3.51.4.1.2.1.1 FindDocumentsForMultiplePatients

7295

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:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

287

Copyright © 2017 IHE International, Inc.

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

7300

•

$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

Attribute

Opt

Mult

$XDSDocumentEntryPatientId

XDSDocumentEntry.patientId

O

M$XDSDocumentEntryClassCode1 2

XDSDocumentEntry.classCodeO

M$XDSDocumentEntryTypeCode1

XDSDocumentEntry.typeCodeO

M$XDSDocumentEntryPracticeSettingCode1

XDSDocumentEntry.practiceSetti
ngCodeO

M$XDSDocumentEntryCreationTimeFrom

Lower value of
XDSDocumentEntry.creationTimeO--$XDSDocumentEntryCreationTimeTo

Upper value of
XDSDocumentEntry.creationTimeO--$XDSDocumentEntryServiceStartTimeFrom

Lower value of
XDSDocumentEntry.serviceStartT
ime

O

--

$XDSDocumentEntryServiceStartTimeTo

Upper value of
XDSDocumentEntry.serviceStartT
ime

O

--

$XDSDocumentEntryServiceStopTimeFrom

Lower value of
XDSDocumentEntry.serviceStopT
ime

O

--

$XDSDocumentEntryServiceStopTimeTo

Upper value of
XDSDocumentEntry.serviceStopT
ime

O

--

$XDSDocumentEntryHealthcareFacilityTypeCode1 2

XDSDocumentEntry.healthcareFa
cilityTypeCodeO

M$XDSDocumentEntryEventCodeList1 2

XDSDocumentEntry.eventCodeLi
st3

O

M

$XDSDocumentEntryConfidentialityCode1

XDSDocumentEntry.confidentialit
yCode3OM$XDSDocumentEntryAuthorPerson4

XDSDocumentEntry.author

O

M$XDSDocumentEntryFormatCode1

XDSDocumentEntry.formatCodeO

M$XDSDocumentEntryStatus

XDSDocumentEntry.statusR

M$XDSDocumentEntryType5

XDSDocumentEntry.objectType

O

M

1

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.
27305

At least one of $XDSDocumentEntryClassCode, $XDSDocumentEntryEventCodeList, or$XDSDocumentEntryHealthcareFacilityTypeCode shall be specified.
3

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

288

Copyright © 2017 IHE International, Inc.

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

7310

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)5

See ITI TF-2a: 3.18.4.1.2.3.6.2

3.51.4.1.2.1.2 FindFoldersForMultiplePatients
This Multi-Patient Query is semantically identical to the FindFolders Stored Query (see ITI TF2a: 3.18.4.1.2.3.7.3) except:
7315

1. $XDSFolderPatientId is optional (may have zero values).
2. $XDSFolderPatientId may contain multiple values.
3. $XDSFolderCodeList shall be a required parameter.
Returns: XDSFolder or ObjectRef objects matching the query parameters
Parameter Name

7320

Attribute

Opt

Mult

$XDSFolderPatientId

XDSFolder.patientId

O

M$XDSFolderLastUpdateTimeFrom

XDSFolder.lastUpdateTime lower
value

O

--

$XDSFolderLastUpdateTimeTo

XDSFolder.lastUpdateTime upper
bound

O

--

$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.
3

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

Query Name

Query ID

FindDocumentsForMultiplePatients

urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f

FindFoldersForMultiplePatients

urn:uuid:50d3f5ac-39a2-11de-a1ca-b366239e58df

3.51.4.1.2.3 Web Services Transport
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.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

289

Copyright © 2017 IHE International, Inc.

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

The Document Registry 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 shall generate the Multi-Patient Stored
Query Request formatted as a SIMPLE SOAP message and accept a Multi-Patient Stored Query
Response formatted as a SIMPLE SOAP message.

7335

IHE-WSP201) The attribute /wsdl:definitions/@name shall be “DocumentRegistry”.
The following WSDL naming conventions shall apply:

7340

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”
7345

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:•

7350

namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0",
schemaLocation="query.xsd"

2. The /definitions/message/part/@element attribute of the Multi-Patient Stored Query
Request message shall be defined as “query:AdhocQueryRequest”
3. The /definitions/message/part/@element attribute of the Multi-Patient Stored Query
Response message shall be defined as “query:AdhocQueryResponse”

7355

4. The /definitions/portType/operation/input/@wsaw:Action attribute for the Multi-PatientStored Query Request message shall be defined as“urn:ihe:iti:2009:MultiPatientStoredQuery”
5. The /definitions/portType/operation/output/@wsaw:Action attribute for the Multi-PatientStored Query Response message shall be defined as“urn:ihe:iti:2009:MultiPatientStoredQueryResponse”

7360

6. The /definitions/binding/operation/soap12:operation/@soapActionRequired attributeshall be defined as “false”
The following WSDL fragment shows an example of Multi-Patient Stored Query transaction
definition:

7365
7370

<?xml version="1.0" encoding="utf-8"?><definitions ...>...
<types><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"/>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

290

Copyright © 2017 IHE International, Inc.

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

7375
7380
7385
7390
7395

...
</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.
3.51.4.1.2.4 Sample SOAP Messages
7400

7405

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.
3.51.4.1.2.4.1 Sample Multi-Patient Stored Query SOAP Request

7410
7415
7420
7425

<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 --><rim:AdhocQuery id="urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f"><rim:Slot name="$XDSDocumentEntryStatus"><rim:ValueList>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

291

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
7430<rim:Value>('urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Approved')</rim:Value></rim:ValueList></rim:Slot>

7435
-->

7440
7445

<!-- Note the lack of a specification of the $XDSDocumentEntryPatientId parameter</rim:AdhocQuery></query:AdhocQueryRequest></s:Body></s:Envelope>

3.51.4.1.2.4.2 Sample Multi-Patient Stored Query SOAP Response
7450
7455
7460
7465
7470

<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 – ITI TF-2a: 3.18.4.1.3.
3.51.5 Security Considerations
7475

All of the Security Considerations found in [ITI-18] apply with the following further profiling.
It is expected that the ATNA authentication would be used to restrict access to the Multi-Patient
Query [ITI-51] transaction. It is expected that few systems would be allowed to request the
LeafClass return result.
3.51.5.1 Security Audit Considerations

7480

The actors involved shall record one audit event for each patient identity that has been includedin the query according to the following. It is important for security auditing that the audit__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

292

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
message contain only one patient identity to better handle these messages in the Audit Record
Repository. If the query includes no patient identities, both Actors shall record a single audit
event with no Patient participant.
7485

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)

EventDateTimeU

not specialized

EventOutcomeIndicatorU

not specialized

EventTypeCode

M

EV(“ITI-51”,“IHE Transactions”,“Multi-Patient Stored Query”)

UserIDC

If Asynchronous Web Services Exchange is being used, the content
of the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserID

M

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

Source (Document Consumer) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)Audit Source (Document Consumer) (1)Patient (0..n)Query Parameters (1)Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor(if known)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

293

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address

NetworkAccessPointID

M

The machine name or IP address.

AuditSourceIDU

not specialized

7490
Audit Source

AuditMessage/
AuditSourceIdentification

Patient (ifknown)(AuditMessage/
ParticipantObjectIde
ntification)

Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeU

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

Stored Query ID (UUID)

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the AdhocQueryRequest, base64 encoded.3

M

The ParticipantObjectDetail element shall occur at least once.
The first element shall contain:
Type: “QueryEncoding” (literal string)
Value: the character encoding, such as “UTF-8”, used to
encode the ParticipantObjectQuery before base64 encoding
If the homeCommunityId is known, the second element shall contain:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal
string)Value: value of the homeCommunityId

ParticipantObjectDetail3.51.5.1.2 Document Registry audit message:
Field Name
Event

AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeU

not specialized

EventOutcomeIndicatorU

not specialized

EventTypeCode

M

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)

Source (Document Consumer) (1)Destination (Document Registry) (1)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

294

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Audit Source (Document Registry) (1)Patient (0..n)Query Parameters (1)7495

Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

UserIDC

If Asynchronous Web Services Exchange is being used, thecontent of the <wsa:ReplyTo/> element. Otherwise, notspecialized.

AlternativeUserID

M

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

UserID

M

SOAP endpoint URI.

AlternativeUserID

M

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeU

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

7500__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

295

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

Stored Query ID (UUID)

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the AdhocQueryRequest, base64 encoded.

M

The ParticipantObjectDetail element shall occur at least once.
The first element shall contain:
Type: “QueryEncoding” (literal string)
Value: the character encoding, such as “UTF-8”, used to
encode the ParticipantObjectQuery before base64 encoding
If the homeCommunityId is known, the second element shall contain:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal
string)Value: value of the homeCommunityId

ParticipantObjectDetail“2” (system object)3.52 Document Metadata Subscribe [ITI-52]
7505

This section corresponds to Transaction ITI-52 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-52 is used by the Document Metadata Subscriber and the Document
Metadata Notification Broker Actors.
3.52.1 Scope

7510

This transaction involves a request by the Document Metadata Subscriber to the Document
Metadata Notification Broker to start a subscription using a particular set of filters, or to cancel
an existing subscription.
3.52.2 Use Case Roles

Actor: Document Metadata Subscriber__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

296

Copyright © 2017 IHE International, Inc.

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

Role: Sends, on the behalf of Document Metadata Notification Recipients, subscription requests,
or subscription cancellation messages to the Document Metadata Notification Broker
Actor: Document Metadata Notification Broker
Role: Manages subscriptions of Document Metadata Notification Recipients
3.52.3 Referenced Standards

7520

7525

•

OASIS Web Services Notification Family of Standards•

WS-BaseNotification 1.3 OASIS Standard•

WS-BrokeredNotification 1.3 OASIS Standard•

WS-Topics 1.3 OASIS Standard•

ITI TF-2a: 3.18 - Registry Stored Query Transaction•

ITI TF-2x: Appendix V

3.52.4 Interaction Diagram

Figure 3.52.4-1: Document Metadata Subscribe Sequence__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

297

Copyright © 2017 IHE International, Inc.

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

3.52.4.1 Subscribe Request Message
3.52.4.1.1 Trigger
A Document Metadata Notification Recipient's need to initiate a subscription will cause theDocument Metadata Subscriber to trigger a Subscribe Request message.
3.52.4.1.2 Message Semantics

7535

7540

The Subscribe Request message shall comply with the requirements in the WS-BaseNotification
standard. Note that the value of the WS-Addressing Action element is prescribed in the standard,
and differs from the requirements of Appendix V. The wsnt:ConsumerReference element
describes the Web Service endpoint where notifications must be sent. The wsnt:Filter element
shall contain the topics and values for these topics for which a notification shall be sent.
Implementers of the pattern shall specify the topic content to be put within the wsnt:Filter
element. The wsnt:Filter element shall contain a TopicExpression element.
This transaction uses simple topics in accordance with the WS-Topics standard and as specified
in Section 3.52.5.

7545This transaction uses a filter based on the Registry Stored Query [ITI-18] transaction syntax andsemantics as specified in Section 3.52.5 Subscription Topics and Filter Expressions.
3.52.4.1.3 Expected Actions
The Notification Broker shall be capable of maintaining multiple concurrent Subscriptions.
The Notification Broker shall keep track of each unique subscription and will provide a uniquesubscription reference which shall be used by the Subscriber to send subsequent cancellations

7550

7555

7560

The Subscriber may indicate the duration of the subscription using thewsnt:InitialTerminationTime element, where a time stamp (expressed as an XML Schema
dateTime data type value) or a duration (expressed as an XML Schema duration data type value)
can be used.
If the Document Metadata Notification Broker is not able to understand a filter expression it
SHALL create faults in accordance with the following rules:•

InvalidFilterFault: the Subscribe message contained a filter that was not understood or
supported by the Document Metadata Notification Broker. For example theReferenceIdList filter parameter exists and the Document Metadata Notification Broker
cannot satisfy it.

•

TopicExpressionDialectUnknownFault: the Subscribe message contained a
TopicExpression filter having a dialect that was not understood or supported by theDocument Metadata Notification Broker.

•

InvalidTopicExpressionFault: the Subscribe message contained a TopicExpression filter
where the contents of the filter did not match the dialect specified.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

298

Copyright © 2017 IHE International, Inc.

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

TopicNotSupportedFault: the Subscribe message contained a TopicExpression filter thatreferenced a topic that was not supported by the Document Metadata Notification Broker.
This Fault SHALL be generated by a Document Metadata Notification Broker that does
not support the Folder Subscription Option if it receives a request for a subscription using
the topic ihe:FolderMetadata.

7570

•

SubscribeCreationFailedFault: The Document Metadata Notification Broker failed toprocess the Subscribe message. The Document Metadata Notification Broker SHOULD
use a more specific fault message if possible. The Document Metadata Notification
Broker MAY include a hint in the fault message indicating why it failed to process the
Subscribe message.

7575
3.52.4.1.4 Example Subscribe Request Message (subscription on a document
filter)
7580
7585
7590
7595
7600
7605
7610
7615
7620

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/NotificationProducer/SubscribeRequest</a:Action><a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID><a:To s:mustUnderstand="1">http://localhost:8080/services/initiatingGateway/query</a:To></s:Header><s:Body><wsnt:Subscribe><!-- The Recipient on whose behalf the subscription is requested - the address where
the notification is to be sent --><wsnt:ConsumerReference><a:Address>https://NotificationRecipientServer/xdsBnotification</a:Address></wsnt:ConsumerReference><wsnt:Filter><wsnt:TopicExpression Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:MinimalDocumentEntry</wsnt:TopicExpression><rim:AdhocQuery id="urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66"><rim:Slot name="$XDSDocumentEntryPatientId"><rim:ValueList><rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode"><rim:ValueList><rim:Value>('Emergency
Department^^healthcareFacilityCodingScheme')</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></wsnt:Filter><wsnt:InitialTerminationTime>2010-05-31T00:00:00.00000Z</wsnt:InitialTerminationTime></wsnt:Subscribe></s:Body>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

299

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</s:Envelope>

3.52.4.2 Subscribe Response Message
3.52.4.2.1 Trigger
7625

This message is an immediate response to a Subscribe Request, and it is sent from the Document
Metadata Notification Broker to the Document Metadata Subscriber.
3.52.4.2.2 Message Semantics

7630

7635

The Subscribe Response message shall comply with the requirements in the WSBaseNotification standard, including the use of the appropriate SOAP Fault messages. Note thatthe value of the WS-Addressing Action element is prescribed in the standard, and differs fromthe requirements of ITI TF-2x: Appendix V.
The subscription identifier is assigned by the Notification Broker as a subscription reference,
communicated in the response in the SOAP body in
wsnt:SubscribeResponse/wsnt:SubscriptionReference (a WS-Addressing endpoint). The
subscription reference shall consist of:•

an Address element, containing a webservices endpoint

In order to unsubscribe, the request shall be sent to the endpoint specified in the Addresscomponent of the SubscriptionReference.
3.52.4.2.3 Expected Actions
7640

7645

If the Document Metadata Subscriber had indicated a requested duration for the subscription, theDocument Metadata Notification Broker shall send the assigned duration for the subscription
using the wsnt:TerminationTime element.
If the Document Metadata Subscriber had not indicated a requested duration for the subscription,
the Document Metadata Notification Broker may send an assigned duration for the subscription(if any), using the wsnt:TerminationTime element.
If the Document Metadata Notification Broker sends an assigned duration for the subscription,
the Subscriber shall associate the assigned duration with the accepted subscription request.

7650

The Document Metadata Subscriber shall associate the accepted subscription request with thesubscription reference address assigned by the Document Metadata Notification Broker in order
to be able to send cancellations for existing subscriptions.
3.52.4.2.4 Example

7655<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

300

Copyright © 2017 IHE International, Inc.

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

<s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/NotificationProducer/SubscribeResponse</a:Action></s:Header><s:Body><wsnt:SubscribeResponse><!-- A WS-Addressing endpoint, where modification and cancelation requests for thissubscription must be sent --><wsnt:SubscriptionReference><a:Address>https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc8443</a:Address></wsnt:SubscriptionReference><wsnt:TerminationTime>2008-05-31T00:00:00Z</wsnt:TerminationTime></wsnt:SubscribeResponse></s:Body></s:Envelope>

3.52.4.3 Unsubscribe Request Message
3.52.4.3.1 Trigger
When a subscription is no longer needed, a Document Metadata Subscriber will trigger an
Unsubscribe Request message.
7680

3.52.4.3.2 Message Semantics
The Unsubscribe Request message shall comply with the requirements in the WSBaseNotification standard. The message conveys the request to cancel an existing subscription.
Note that the value of the WS-Addressing Action element is prescribed in the standard, anddiffers from the requirements of ITI TF-2x: Appendix V.

7685

3.52.4.3.3 Expected Actions
The Document Metadata Subscriber shall send this message to the endpoint associated with theexisting subscription.

7690

The Document Metadata Notification Broker shall cancel the corresponding subscription, andrespond with an Unsubscribe Response message. In the case when, for whatever reason, thesubscription cannot be canceled, the Document Metadata Notification Broker shall respond witha ResourceUnknownFault or an UnableToDestroySubscriptionFault SOAP Fault message asappropriate.
3.52.4.3.4 Example

7695
7700
7705

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/SubscriptionManager/UnsubscribeRequest</a:Action><a:MessageID>382dcdc9-8e86-9fde-8445-48fd83bca93a</a:MessageID><a:To>https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc-8443</a:To></s:Header>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

301

Copyright © 2017 IHE International, Inc.

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

7710<s:Body><wsnt:Unsubscribe/></s:Body></s:Envelope>

3.52.4.4 Unsubscribe Response Message
3.52.4.4.1 Trigger
7715

This message is an immediate response to an Unsubscribe Request message, and it is sent fromthe Document Metadata Notification Broker to the Document Metadata Subscriber.
3.52.4.4.2 Message Semantics

7720

The Unsubscribe Response message shall comply with the requirements in the WSBaseNotification standard. This message indicates that an Unsubscribe message was successfully
processed. Note that the value of the WS-Addressing Action element is prescribed in thestandard, and differs from the requirements of ITI TF-2x: Appendix V.
3.52.4.4.3 Expected Actions
The Document Metadata Notification Broker shall cancel the corresponding subscription.
The Document Metadata Subscriber shall mark the corresponding subscription as successfully
terminated.

7725

7730
7735
7740

3.52.4.4.4 Example<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/SubscriptionManager/UnsubscribeResponse</a:Action></s:Header><s:Body><wsnt:UnsubscribeResponse/></s:Body></s:Envelope>

3.52.5 Subscription Topics and Filter Expressions

7745

This transaction restricts the subscription topic to be one of FullDocumentEntry or
MinimalDocumentEntry (Section 3.52.5.1) and restricts the semantics of filter expressions to thesemantics of a subset (Section 3.52.5.2) of the Registry Stored Query [ITI-18] transaction.
3.52.5.1 Topics
This transaction defines simple topics as described in the WS-Topics specification. If theDocument Metadata Notification Broker supports the Folder Subscription Option it shall support__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

302

Copyright © 2017 IHE International, Inc.

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

7750

all the following topics in a Document Metadata Subscribe Request; otherwise it shall rejectsubscription Request which specify folder's topic generating a fault (see Section 3.52.4.1.3“Expected Actions”). The Document Metadata Subscriber may support a subset of these topics:
3.52.5.1.1 ihe:FullDocumentEntry

7755

This topic indicates that the events for which the subscription is made shall be Document Entry
registrations, and that the notification shall contain the full metadata describing each matching
Document Entry as described in the Notification transaction in Section 3.53.4.1.2.
3.52.5.1.2 ihe:MinimalDocumentEntry

7760

This topic indicates that the events for which the subscription is made shall be Document Entry
registrations, and that the notification shall contain the minimal set of data describing eachmatching Document Entry as described in the Document Metadata Notify transaction in Section
3.53.4.1.2.
3.52.5.1.3 ihe:SubmissionSetMetadata

7765

This topic indicates that the event for which the subscription is made shall be creating a
SubmissionSet and that the notification shall contain the full metadata describing the match with
the SubmissionSet object, as described in the Document Metadata Notify transaction in Section
3.53.4.1.2.
3.52.5.2 Building Filter Expressions

7770

7775

7780

7785

The XDS metadata, specified in ITI TF-3: 4.1, describes the objects which are used in adocument registration. The Registry Stored Query [ITI-18] transaction uses a subset of themetadata to build a list of queries available to a XDS Document Consumer to search for
documents with specific characteristics. The list of queries is in ITI TF-2a: 3.18.4.1.2.3.7. The
transaction Document Metadata Subscribe uses the syntax of the Registry Stored Query [ITI-18]
transaction for the creation of the filtering expression.
Filters can be created using the parameters of the FindDocuments,
FindDocumentsByReferenceId, FindSubmissionSet queries defined within the Registry Stored
Query transaction and use the syntax of the FindDocuments FindDocumentsByReferenceId or
FindSubmissionSets queries to express the filter.
The evaluation of filter expressions is based on the XDS metadata model. In this transaction, thestream of events for which subscriptions are possible is limited to events representing theexistence of SubmissionSet and documentEntry Objects. The Document Metadata Notification
Broker becomes aware of such events either via a Document Metadata Publish [ITI-54]
transaction, or via other mechanisms not specified by IHE. The Document Metadata Notification
Broker shall determine if there is a subscription which matches any of the Document Entry
Objects or SubmissionSet Object in an event.
A match means that if a Registry Stored Query, with the same parameters as the filter expression
in the subscription, were sent to a XDS Document Registry containing the Document Entry__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

303

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Objects or SubmissionSet Object from the event, the result of this Stored Query would containone or more of these Objects.

7790

In an XDS Affinity Domain context, the applicable events are likely to be Register Document
Set [ITI-42] transaction containing one or more Document Entry objects. In this case, theDocument Metadata Notification Broker may have to map between the model within which theevents took place, and the Document Sharing metadata model.
A good understanding of the Registry Stored Query transaction and the XDS metadata isnecessary to understand how the filter expressions work. For example, if the filter expression
below were implemented as a stored query on the registry

7795

7800
7805

7810

7815

7820
7825
7830
7835

<rim:AdhocQuery id="urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><rim:Slot name="$XDSDocumentEntryPatientId"><rim:ValueList><rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('44950^^codScheme','44955^^codScheme','44960^^codScheme','44970^^codScheme','44979^^codScheme')</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery>it will return all document entries for patient with ID st3498702 (assigned by an authority
identified by the OID 1.3.6.1.4.1.21367.2005.3.7) where the event code metadata contains atleast one of the codes listed (in this case CPT codes for various appendectomies). When used asa filter expression, the same structure will yield a match against a document entry in an XDS
registry submission, where the document entry is for patient with ID st3498702 and the eventcode is "44970". The following snippet shows an example of such a submission:<lcm:SubmitObjectsRequest><rim:RegistryObjectList><rim:ExtrinsicObject id="Document01" mimeType="text/xml" objectType="urn:uuid:7edca82f054d-47f2-a032-9b2a5b5186c1">...
<rim:Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291b1ae6a575ef4" classifiedObject="Document01" nodeRepresentation="44950"><rim:Name><rim:LocalizedString value="Appendectomy"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>CPT codes</rim:Value></rim:ValueList></rim:Slot></rim:Classification>...
<rim:ExternalIdentifier id="ei01" registryObject="Document01"
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.patientId"/></rim:Name>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

304

Copyright © 2017 IHE International, Inc.

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

...

</rim:ExternalIdentifier><rim:ExtrinsicObject></rim:RegistryObjectList></lcm:SubmitObjectsRequest>

7845

7850
7855
7860
7865
7870
7875
7880
7885
7890

7895

When a Document Metadata Notification Subscriber constructs a filter expression, it shall
include the whole stored query expression (as shown above) directly in the Subscribe Request
message as a child of the wsnt:Filter element:<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/NotificationProducer/SubscribeRequest</a:Action><a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID></s:Header><s:Body><wsnt:Subscribe><!-- The Recipient on whose behalf the subscription is requested - the address where
the notification is to be sent --><wsnt:ConsumerReference><a:Address>https://NotificationRecipientServer/xdsBnotification</a:Address></wsnt:ConsumerReference><wsnt:Filter><wsnt:TopicExpression Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:FullDocumentEntry</wsnt:TopicExpression><rim:AdhocQuery id="urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66"><rim:Slot name="$XDSDocumentEntryPatientId"><rim:ValueList><rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('44950^^codScheme','44955^^codScheme','44960^^codScheme','44970^^codScheme','44979^^codScheme')</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></wsnt:Filter><wsnt:InitialTerminationTime>2008-07-31T00:00:00.00000Z</wsnt:InitialTerminationTime></wsnt:Subscribe></s:Body></s:Envelope>

How the Document Metadata Notification Broker evaluates the filter expression, and how it
performs the matching against the existing subscriptions, is out of scope of this transaction. It is
expected that such implementation details will allow vendors to differentiate themselves in themarketplace.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

305

Copyright © 2017 IHE International, Inc.

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

7900

It is important to note that not all stored queries, and not all parameters defined for the stored
queries, are suitable for filter expressions. The Document Metadata Notification Broker shallsupport the following filters and associated parameters when used in subscription requests, andthe Document Metadata Subscriber may support a subset of these:
3.52.5.2.1 Subscriptions for DocumentEntry metadata

7905

A Document Metadata Notification Broker that accepts a Subscribe Request containing filter
expressions created using DocumentEntry metadata shall yield a match as described in Section
3.52.5.2. Parameters that can be used for creating the filter expression are described below:
1. $XDSDocumentEntryPatientId: this required parameter contains the patient ID for
which a document entry is being registered in the XDS Document Registry
2. $XDSDocumentEntryClassCode: this parameter matches against the
XDSDocumentEntry.classCode metadata elements in a given registry submission

7910

3. $XDSDocumentEntryTypeCode: this parameter matches against the
XDSDocumentEntry.typeCode metadata elements in a given registry submission
4. $XDSDocumentEntryReferenceIdList: this parameter matches against the
XDSDocumentEntry.referenceIdList metadata elements in a given registry submission

7915

Note: The ReferenceIdList attribute is optional. If the parameter is specified, the filter matches only documents where the
ID contains the value conveyed in the parameter. If the document does not contain a value in the ReferenceIdList,
there is no match.

5. $XDSDocumentEntryPracticeSettingCode: this parameter matches against the
XDSDocumentEntry.practiceSettingCode metadata elements in a given registrysubmission
7920

6. $XDSDocumentEntryHealthcareFacilityTypeCode: this parameter matches against
the XDSDocumentEntry.healthcareFacilityTypeCode metadata elements in a given
registry submission
7. $XDSDocumentEntryEventCodeList: this parameter matches against the
XDSDocumentEntry.eventCodeList metadata elements in a given registry submission

7925

8. $XDSDocumentEntryConfidentialityCode: this parameter matches against the
XDSDocumentEntry.confidentialityCode metadata elements in a given registrysubmission
9. $XDSDocumentEntryFormatCode: this parameter matches against the
XDSDocumentEntry.formatCode metadata elements in a given registry submission

7930

10. $XDSDocumentEntryAuthorPerson: this parameter matches against the
XDSDocumentEntry.author metadata elements in a given registry submission. All
properties of this parameter specified in ITI TF-2a: 3.18.4.1.2.3.7.1 are applicable in thistransaction.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

306

Copyright © 2017 IHE International, Inc.

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

7935

The AdHocQuery/@id attribute SHALL store an identifier specific for the type of filter used increating the subscription. The UUID that identifies subscriptions for DocumentEntry’s metadatais:“urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66”.
An example of subscription on a document filter is presented below:

7940
7945
7950
7955
7960
7965
7970
7975
7980

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/NotificationProducer/SubscribeRequest</a:Action><a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID><a:To s:mustUnderstand="1">http://localhost:8080/services/initiatingGateway/query</a:To></s:Header><s:Body><wsnt:Subscribe><!-- The Recipient on whose behalf the subscription is requested - the address where
the notification is to be sent --><wsnt:ConsumerReference><a:Address>https://NotificationRecipientServer/xdsBnotification</a:Address></wsnt:ConsumerReference><wsnt:Filter><wsnt:TopicExpression Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:MinimalDocumentEntry</wsnt:TopicExpression><rim:AdhocQuery id="urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66"><rim:Slot name="$XDSDocumentEntryPatientId"><rim:ValueList><rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode"><rim:ValueList><rim:Value>('Emergency
Department^^healthcareFacilityCodingScheme')</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></wsnt:Filter><wsnt:InitialTerminationTime>2010-05-31T00:00:00.00000Z</wsnt:InitialTerminationTime></wsnt:Subscribe></s:Body></s:Envelope>7985
3.52.5.2.2 Subscriptions for SubmissionSets metadata
Document Metadata Notification Broker that accepts a Subscribe Request containing a filter
expression based on the FindSubmissionSets stored query shall yield a match as described in
Section 3.52.5.2. The subscription filter expression represents a subset of the__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

307

Copyright © 2017 IHE International, Inc.

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

FindSubmissionSets query parameters, with a specific extension. A Document Metadata
Subscriber MAY be able to create a filter expression that includes XDSSubmissionSet.patientId,
XDSSubmissionSet.sourceId, XDSSubmissionSet.author and
XDSSubmissionSet.intendedRecipient. Parameters that can be used for this type of filter aredescribed below:

7995

1. $XDSSubmissionSetPatientId: this is a required parameter that contains the identifier ofthe patient target of the clinical content published by a submission and represent the valueof the XDSSubmissionSet.PatientId metadata;

8000

2. $XDSSubmissionSetSourceId: this optional parameter identifies the source of thecontent published by the submission and represent the value of the
XDSSubmissionSets.sourceId metadata;
3. $XDSSubmissionSetAuthor: this optional parameter identifies the author person of thecontent published by the submission and represents the value of the
XDSSubmissionSets.author metadata. This parameter may be multi-valued;

8005

8010

8015

4. $XDSSubmissionSetIntendedRecipient: this is an optional parameter for thesubscription. A Document Metadata Subscriber shall be able to subscribe this parameterin addition to other parameters which have direct correspondence with query parameters.
This parameter represents the value of the XDSSubmissionSet.intendedRecipient
metadata. This parameter identifies initial targets intended for a submission. Thisparameter may be multi-valued.
Note: intendedRecipient attribute is optional. If the parameter is specified, the filter matches only submissionSets where theintendedRecipient contains the value conveyed in the parameter. If the document does not contain a value in theintendedRecipient, there is no match.

The AdHocQuery/@id attribute SHALL contain an identifier specific for the type of filter usedin creating the subscription. The UUID that identifies subscriptions for SubmissionSet’s
metadata is:“urn:uuid:fbede94e-dbdc-4f6b-bc1f-d730e677cece”
An example of subscription on a SubmissionSet filter is presented below:

8020
8025
8030
8035

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw2/NotificationProducer/SubscribeRequest</a:Action><a:MessageID>382dcdc7-8e84-9fdc-8443-48fd83bca938</a:MessageID><a:To s:mustUnderstand="1">http://localhost:8080/services/initiatingGateway/query</a:To></s:Header><s:Body><wsnt:Subscribe>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

308

Copyright © 2017 IHE International, Inc.

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

8040
8045
8050
8055
8060

<!-- The Recipient on whose behalf the subscription is requested - the address where
the notification is to be sent --><wsnt:ConsumerReference><a:Address>https://NotificationRecipientServer/xdsBnotification</a:Address></wsnt:ConsumerReference><wsnt:Filter><wsnt:TopicExpression Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:SubmissionSetMetadata</wsnt:TopicExpression><rim:AdhocQuery id="urn:uuid:fbede94e-dbdc-4f6b-bc1f-d730e677cece"><rim:Slot name="$XDSSubmissionSetPatientId"><rim:ValueList><rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSSubmissionSetIntendedRecipient"><rim:ValueList><rim:Value>('Some Hospital%')</rim:Value><rim:Value>('|Welby%')</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></wsnt:Filter><wsnt:InitialTerminationTime>2010-05-31T00:00:00.00000Z</wsnt:InitialTerminationTime></wsnt:Subscribe></s:Body></s:Envelope>

3.52.5.3 Combining topics and filter expressions
8065

A topic defines static rules for creating notifications. This transaction defines four topics in
Section 3.52.5.1. Each subscription request shall contain exactly one topic expression.
A filter expression is equivalent to a specific stored query with certain parameters. Filter
conditions expressed as query parameters and used in the expressions must satisfy the samerequirements as a corresponding Registry Stored Query:

8070

•

the values for all specified query parameters must match (AND all different parameters)•

at least one of the values of multi-valued parameters must match (OR the values in a
multi-valued query parameter)

Topics, defined in Section 3.52.5.1 and filter expressions, defined in Section 3.52.5.2, can only
be used in specific combinations. These combinations are described in Table 3.52.5.3-1:
8075

Table 3.52.5.3-1: Topics and Filter Expression Combinations
Filter Expression

Topic Expression

subscription for DocumentEntry

ihe:FullDocumentEntry
ihe:MinimalDocumentEntry

subscription for SubmissionSets

ihe:SubmissionSetMetadata__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

309

Copyright © 2017 IHE International, Inc.

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

8080

8085

8090

The risk assessment for the Document Metadata Subscribe transaction is described in the risk
assessment spreadsheet for the Document Metadata Subscription Profile, which is available from
IHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are as
follows:•

Document Metadata Subscriber and Document Metadata Notification Broker shall begrouped with a Secure Node or Secure Application in the Audit Trail and Node
Authentication (ATNA) Profile.

•

The use of encrypted TLS is recommended when the transmission is not otherwise
secured (e.g., transmission over a secure network)

As it is possible through the document metadata subscribe transaction to maliciously overload
the Document Metadata Notification Recipient Actors, it is recommended that a strong
authentication be used in combination with access rights enforcement and that authentication
data should be conveyed through the Cross-Enterprise User Assertion (XUA) Profile. This
recommendation also addresses the possibility of malicious cancellations of subscriptions.
Additionally, it is recommended that organizational measures be taken to avoid:•

overload of a Document Metadata Notification Recipient through subscription whichcannot be cancelled because the subscription id has been lost e.g., through an
administrative service allowing cancellation of subscription under well-defined
circumstances•

cancellation of a subscription unnoticed by the intended document metadata notification
recipient e.g., through an informative message (out of the scope of this transaction) sent
to the intended recipient

8095

8100

This profile provides the ihe:MinimalDocumentEntry topic expression to avoid disclosing
sensitive information. Using this type of topic expression allows delegation of the access control
decisions to the Document Sharing infrastructure.
3.52.6.1 Audit Record Considerations

8105

The Document Metadata Subscribe transaction is a Query Information event as defined in Table
ITI TF-2a: 3.20.4.1.1.1-1. The actors involved shall record audit events according to thefollowing:8110__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

310

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.52.6.1.1 Document Metadata Subscriber audit message:
Field Name
Event

AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“C” (Create) for Subscribe message exchange“D” (Delete) for Unsubscribe message exchange

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)

Source (Document Metadata Subscriber) (1)
Human Requestor (0..n)
Destination (Document Metadata Notification Broker) (1)Audit Source (Document Metadata Subscriber) (1)
Subscription (0..1)
Patient (0..1)
Query Parameters (0..1) (required for Subscribe message, not used for Unsubscribe message)

Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

8115

8120
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

311

Copyright © 2017 IHE International, Inc.

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

Destination

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address

AuditSourceIDU

not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Audit Source

AuditMessage/
AuditSourceIdentificati
on

Subscription(if known)(AuditMessage/
ParticipantObjectIdentification)Patient(if known)(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata
Subscribe”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

For the Subscribe Message, the URI contained in the<wsnt:SubscriptionReference/wsa:Address/>
For the Unsubscribe message, the URI contained in the<soap12:Header/wsa:Address/>

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized8125__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

312

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

8130

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <wsnt:Subscribe/wsnt:Filter/rim:AdhocQuery/@id/>

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

The value of <wsnt:Subscribe/> element, base64 encoded.

ParticipantObjectDetailUnot specialized

3.52.6.1.2 Document Metadata Notification Broker audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“C” (Create) for Subscribe message exchange“D” (Delete) for Unsubscribe message exchange

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)

Source (Document Metadata Subscriber) (1)Destination (Document Metadata Notification Broker) (1)Audit Source (Document Metadata Notification Broker) (1)
Subscription (0..1)
Patient (0..1)
Query Parameters (0..1) (required for Subscribe message, not used for Unsubscribe message)

Where:
SourceAuditMessage/
ActiveParticipant

UserIDU

AlternativeUserIDU

not specialized
not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address8135__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

313

Copyright © 2017 IHE International, Inc.

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

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

8140
Audit Source

AuditMessage/
AuditSourceIdentificati
on

Subscription(if known)(AuditMessage/
ParticipantObjectIdentification)Patient(If known)(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata
Subscribe ”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

For the Subscribe Message, the URI contained in the<wsnt:SubscriptionReference/wsa:Address/>
For the Unsubscribe message, the URI contained in the<soap12:Header/wsa:Address/>

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M“1” (Person)“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized8145__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

314

Copyright © 2017 IHE International, Inc.

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

Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

8150

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-52”, “IHE Transactions”, “Document Metadata
Subscribe”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of<wsnt:Subscribe/wsnt:Filter/rim:AdhocQuery/@id/>

ParticipantObjectQueryM

The value of <wsnt:Subscribe/> element, base64 encoded.

ParticipantObjectDetailUnot specialized

3.53 Document Metadata Notify [ITI-53]
This section corresponds to Transaction ITI-53 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-53 is used by the Document Metadata Notification Recipient andthe Document Metadata Notification Broker Actors.
3.53.1 Scope

8155

This transaction delivers a notification from the Document Metadata Notification Broker to theDocument Metadata Notification Recipient about an event which matches an existing
subscription.
3.53.2 Use Case Roles

8160
Actor: Document Metadata Notification Broker
Role: Sends notifications to subscribed Document Metadata Notification Recipients based onreceived Publish transactions
Actor: Document Metadata Notification Recipient
8165

Role: Receives and processes notifications about events matching a set of filter expressions.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

315

Copyright © 2017 IHE International, Inc.

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

8170

•

OASIS Web Services Notification Family of Standards•

WS-BaseNotification 1.3 OASIS Standard•

WS-BrokeredNotification 1.3 OASIS Standard•

WS-Topics 1.3 OASIS Standard•

ITI TF-2b: 3.43.4.2.2•

ITI TF-2x: Appendix V

3.53.4 Interaction Diagram

8175

Figure 3.53.4-1: Document Metadata Notify Sequence

3.53.4.1 Notify Message
3.53.4.1.1 Trigger
8180

When an event occurs where the topics of the event match the filter requirements of one or moreexisting subscriptions, the Document Metadata Notification Broker will trigger a Notification
message to the corresponding Document Metadata Notification Recipient. The description ofmatching subscriptions to events can be found in Section 3.52.5.2.
3.53.4.1.2 Message Semantics

8185

The Notify message shall comply with the requirements in the WS-BaseNotification standard.
Note that the value of the WS-Addressing Action element is prescribed in the standard, anddiffers from the requirements of ITI TF-2x: Appendix V.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

316

Copyright © 2017 IHE International, Inc.

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

8190

8195

8200

8205

8210

8215

8220

The Notify message convey in the wsnt:Notify/wsnt:NotificationMessage/wsnt:Message theevent that matched with a subscription. Depending on the event which triggered the notification,
there may be one or more Document Entry Objects, Folder Objects, or SubmissionSet Objects
whose metadata matches the filter conditions of any particular subscription. This transaction
defines the following structures for conveying a Notify message:
A Full Notification, which shall be sent if the subscription request included the topic
ihe:FullDocumentEntry (see Section 3.52.5.1). In this case, the notification shallconsist of parts of the payload of a Register Document Set-b Transaction as
defined in Section 3.42.4.1. The <lcm:SubmitObjectsRequest> element is the
only child of the wsnt:Notify/wsnt:NotificationMessage/wsnt:Message element inthis message. The <rim:RegistryObjectList> element shall be the only child of
the <lcm:SubmitObjectsRequest> element. Only <rim:ExtrinsicObject> elements
representing Document Entries shall be sent within the <rim:RegistryObjectList>
element.
A Minimal Notification, which shall be sent if the subscription request included the
topic ihe:MinimalDocumentEntry. In this case, the notification shall consist ofparts of the payload of a Register Document Set-b transaction as defined in
Section 3.42.4.1. The <lcm:SubmitObjectsRequest> element is the only child of
the wsnt:Notify/wsnt:NotificationMessage/wsnt:Message element in this message.
The <rim:RegistryObjectList> element shall be the only child of the<lcm:SubmitObjectsRequest> element. Only <rim:ObjectRef> elements
representing Document Entries shall be sent within the <rim:RegistryObjectList>
element.
A submissionSet Notification, which shall be sent if the subscription request included
the topic ihe:SubmissionSetMetadata. In this case the response consists of parts ofthe payload of a Register Document Set-b Transaction as defined in Section
3.42.4.1. The <lcm:SubmitObjectsRequest> element is the only child of the
wsnt:Notify/wsnt:NotificationMessage/wsnt:Message element in this message.
The <rim:RegistryObjectList> element shall be the only child of the<lcm:SubmitObjectsRequest> element. Only one <rim:RegistryPackage>element representing the submissionSet object shall be sent within the<rim:RegistryObjectList> element and shall be characterized by classification
scheme: classificationScheme="urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd" (that represents an object of submissionSet type).
There shall be a single wsnt:Notify/wsnt:NotificationMessage/wsnt:Message element in thistransaction. If multiple objects need to be represented in a single notification, the WSBaseNotification standard allows this to be done.
3.53.4.1.3 Expected Actions

8225

The Document Metadata Notification Recipient shall accept the Notify message. The Notify
message shall be processed according to the configuration and business logic of the actor.
Possibilities include conveying the notification information to other systems and/or users.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

317

Copyright © 2017 IHE International, Inc.

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

8230

The Document Metadata Notification Broker may send the filter conditions of the subscription,
and/or the address (either a logical identifier or a service address url) of the Notification Broker
that produces the notification. Both of these alternatives increase certain security risks, their use
should be determined by local policy for security and confidentiality.
3.53.4.1.4 Examples
3.53.4.1.4.1 Full Notification Example (ihe:FullDocumentEntry)

8235
8240
8245
8250
8255
8260
8265
8270
8275
8280
8285

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd" urn:oasis:names:tc:ebxmlregrep:xsd:lcm:3.0 ../schema/ebRS/lcm.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</a:Action><a:MessageID>382dcdca-8e87-9fdf-8446-48fd83bca93b</a:MessageID><a:To>https://NotificationRecipientServer/xdsBnotification</a:To></s:Header><s:Body><wsnt:Notify><wsnt:NotificationMessage><wsnt:SubscriptionReference><a:Address>https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc8443-48fd83bca938</a:Address></wsnt:SubscriptionReference><wsnt:Topic Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:FullDocumentEntry</wsnt:Topic><wsnt:ProducerReference><a:Address>https://ProducerReference</a:Address></wsnt:ProducerReference><wsnt:Message><lcm:SubmitObjectsRequest><rim:RegistryObjectList><rim:ExtrinsicObject id="Document01" mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">...
<rim:Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a4051-b291-b1ae6a575ef4" classifiedObject="Document01" nodeRepresentation="44950"><rim:Name><rim:LocalizedString value="Appendectomy"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>CPT codes</rim:Value></rim:ValueList></rim:Slot></rim:Classification>...
<rim:ExternalIdentifier id="ei01" registryObject="Document01"
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.patientId"/></rim:Name>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

318

Copyright © 2017 IHE International, Inc.

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

8290
8295

...

</rim:ExternalIdentifier><rim:ExtrinsicObject></rim:RegistryObjectList></lcm:SubmitObjectsRequest></wsnt:Message></wsnt:NotificationMessage></wsnt:Notify></s:Body></s:Envelope>

3.53.4.1.4.2 Minimal Notification Example (ihe:MinimalDocumentEntry)
8300
8305
8310
8315
8320
8325
8330
8335

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:xds="urn:ihe:iti:xds-b:2007"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd urn:ihe:iti:xds-b:2007../../schema/IHE/XDS.b_DocumentRepository.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0../../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</a:Action><a:MessageID>382dcdca-8e87-9fdf-8446-48fd83bca93b</a:MessageID><a:To>https://NotificationRecipientServer/xdsBnotification</a:To></s:Header><s:Body><wsnt:Notify><wsnt:NotificationMessage><wsnt:SubscriptionReference><a:Address>https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc8443-48fd83bca938</a:Address></wsnt:SubscriptionReference><wsnt:Topic Dialect="http://docs.oasis-open.org/wsn/t1/TopicExpression/Simple">ihe:MinimalDocumentEntry</wsnt:Topic><wsnt:ProducerReference><a:Address>https://ProducerReference</a:Address></wsnt:ProducerReference><wsnt:Message><lcm:SubmitObjectsRequest><rim:RegistryObjectList><rim:ObjectRef id="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" /></rim:RegistryObjectList></lcm:SubmitObjectsRequest></wsnt:Message></wsnt:NotificationMessage></wsnt:Notify></s:Body></s:Envelope>

8340

3.53.4.1.4.3 SubmissionSet Notification Example (ihe:SubmissionSetMetadata)

8345<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

319

Copyright © 2017 IHE International, Inc.

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

8350
8355
8360
8365
8370
8375
8380

xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd" urn:oasis:names:tc:ebxmlregrep:xsd:lcm:3.0 ../schema/ebRS/lcm.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</a:Action><a:MessageID>382dcdca-8e87-9fdf-8446-48fd83bca93b</a:MessageID><a:To>https://NotificationRecipientServer/xdsBnotification</a:To></s:Header><s:Body><wsnt:Notify><wsnt:NotificationMessage><wsnt:SubscriptionReference><a:Address>https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc8443-48fd83bca938</a:Address></wsnt:SubscriptionReference><wsnt:Topic Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">ihe:SubmissionSetMetadata</wsnt:Topic><wsnt:ProducerReference><a:Address>https://ProducerReference</a:Address></wsnt:ProducerReference><wsnt:Message><lcm:SubmitObjectsRequest
xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0../../schema/ebRS/lcm.xsd"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rim:RegistryObjectList><rim:RegistryPackage id="SubmissionSet01"><!-- here all the SubmissionSet metadata -->8385
b4633d873bdd"/>

8390

8395

</rim:RegistryPackage><rim:Classification id="cl10" classifiedObject="SubmissionSet01"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-</rim:RegistryObjectList></lcm:SubmitObjectsRequest></wsnt:Message></wsnt:NotificationMessage></wsnt:Notify></s:Body></s:Envelope>

3.53.5 Security Considerations
The risk assessment for the Document Metadata Notify transaction is described in the risk
assessment spreadsheet for the Document Metadata Subscription Profile, which is available from
IHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are as
follows:

8400

Document Metadata Notification Broker and Document Metadata Notification Recipients shallbe grouped with a Secure Node or Secure Application in the Audit Trail and Node
Authentication (ATNA) Profile.
The use of encrypted TLS is recommended when the transmission is not otherwise secured (e.g.,transmission over a secure network)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

320

Copyright © 2017 IHE International, Inc.

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

8410

Additionally, it is recommended that the Document Metadata Notify transaction be associatedwith a SAML assertion outlining authorizations to the notification content so that the Document
Metadata Notification Recipient will be able to enforce these authorizations (for example, see the
Cross-Enterprise User Assertion (XUA) Profile ITI TF-1:13). This recommendation is highly
dependent on an XDS Affinity Domain managing roles for its users correctly as most of theauthorizations will be based on roles.
3.53.5.1 Audit Record Considerations
The Document Metadata Notify transaction is an Export event, as defined in ITI TF-2a: Table
3.20.4.1.1.1-1. The actors involved in the transaction shall create audit data in conformance with
DICOM Part 15 “Data Export”/”Data Import”, with the following exceptions.

8415

3.53.5.1.1 Document Metadata Notification 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-53”, “IHE Transactions”, “Document Metadata Notify”)

Source (Document Metadata Notification Broker) (1)Destination (Document Metadata Notification Recipient) (1)
Human Requestor (0..n)
Audit Source (Document Metadata Notification Recipient) (1)Patient (0..1)
DocumentEntry/SubmissionSet (1..n)

Where:
SourceAuditMessage/
ActiveParticipant

Destination

AuditMessage/
ActiveParticipant

UserID

M

When WS-Addressing is used: <From/>

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

NetworkAccessPointTypeCodeM“1” for machine (DNS) name, “2” for IP address__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

321

Copyright © 2017 IHE International, Inc.

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

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

NetworkAccessPointID

M

The machine name or IP address

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

8420
Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient(if-known)(AuditMessage/
ParticipantObjectIde
ntification)

DocumentEntrySubmissionSetParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specializedM

The Document Metadata Notification Recipient shall include
one of the following values, depending on the specific object
in the message:
EV("urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”,“IHE XDS Metadata”, “document entry object type”)
EV(“urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248”,“IHE XDS Metadata”, “on-demand document entry objecttype”)EV(urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”,“IHE XDS Metadata”, ”submission set classification node”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of the object's EntryUUID attribute.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectIDTypeCode__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

322

Copyright © 2017 IHE International, Inc.

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

ParticipantObjectDetailThis element is required, if known:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal
string)Value: value of the homeCommunityId

3.53.5.1.2 Document Metadata Notification Broker 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-53”, “IHE Transactions”, “Document Metadata Notify”)

Source (Document Metadata Notification Broker) (1)Destination (Document Metadata Notification Recipient) (1)Audit Source (Document Metadata Notification Broker) (1)DocumentEntry/SubmissionSet (1..n)8425

Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentification

UserID

M

When WS-Addressing is used: <From/>

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

8430__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

323

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
DocumentEntry
SubmissionSet(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

The Document Metadata Notification Broker shall include oneof the following values, depending on the specific object in themessage:EV("urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”, “IHEXDS Metadata”, “document entry object type”)
EV(“urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248”,“IHE XDS Metadata”, “on-demand document entry objecttype”)EV(urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHEXDS Metadata”, ”submission set classification node”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of the object's EntryUUID attribute.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailCThis element is required, if known:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string)
Value: value of the homeCommunityId

3.54 Document Metadata Publish [ITI-54]
8435

This section corresponds to Transaction ITI-54 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-54 is used by the Document Metadata Notification Broker andDocument Metadata Publisher Actors.
3.54.1 Scope
This transaction delivers information from the Document Metadata Publisher to the Document
Metadata Notification Broker about an event which may have a subscription. The WS Brokered
Notification Publisher Registration requirements are out of scope for this transaction.

8440

3.54.2 Use Case Roles__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

324

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor: Document Metadata Notification Broker
Role: Receives and processes information about events for which there may be a subscription.
Actor: Document Metadata Publisher
8445

Role: Publishes information to the Document Metadata Notification Broker when applicable
events occur for which a subscription may exist.
3.54.3 Referenced Standards

8450

•

OASIS Web Services Notification Family of Standards•

WS-BaseNotification 1.3 OASIS Standard•

WS-BrokeredNotification 1.3 OASIS Standard•

WS-Topics 1.3 OASIS Standard•

ITI TF-2b: 3.43.4.2.2•

ITI TF-2x: Appendix V

3.54.4 Interaction Diagram

8455

Figure 3.54.4-1: Document Metadata Publish Sequence

3.54.4.1 Notify Message
3.54.4.1.1 Trigger
8460

When an event occurs for which a subscription may exist, the Document Metadata Publisher will
trigger a Notification message to the Document Metadata Notification Broker. Events that could
trigger a notification are publication of or update to a DocumentEntry or SubmissionSet.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

325

Copyright © 2017 IHE International, Inc.

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

The Document Metadata Publisher shall use a Notify message to communicate published objects
to the Document Metadata Notification Broker Actor.
This message shall have one <NotificationMessage> element.
This element SHALL have two child elements:•<ProducerReference> that identifies the source of the data published. This element
conveys the value of the SubmissionSet.sourceId attribute. This attribute shall contain a
URI, for example “urn:oid:1.2.3.4.5”.

•<Message> that identifies published objects. This element shall have a single childelement <lcm:SubmitObjectsRequest> that has only one child element<rim:RegistryObjectList>. This element conveys a list of SubmissionSet, Folder, andDocumentEntry objects.

8470

8475

Note: SubmissionSet objects are constructed from <rim:RegistryObject> elements and must include the<rim:Classification>.

Note that there is no subscription information in the Notify message in the Publish transaction.
3.54.4.1.3 Expected Actions
The Notify message shall comply with the requirements in the WS-BaseNotification standard.
8480

The Document Metadata Notification Broker shall evaluate the Publish transaction, and if there
are matching subscriptions, it shall send the corresponding Notification transaction to theappropriate Document Metadata Notification Recipients.
3.54.4.1.4 Example

8485
8490
8495
8500
8505
8510

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:ihe="urn:ihe:iti:pub-sub:2008"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelope http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsd
http://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd urn:ihe:iti:pubsub:2008 ../schema/IHE/XDS.b_PublishSubscribe.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0../schema/ebRS/rim.xsd"><s:Header><a:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify</a:Action><a:MessageID>382dcdca-8e87-9fdf-8446-48fd83bca93b</a:MessageID><a:To>https://NotificationBroker/xdsBpublish</a:To></s:Header><s:Body><wsnt:Notify><wsnt:NotificationMessage><wsnt:ProducerReference><a:Address>urn:oid:1.2.3.4.5</a:Address></wsnt:ProducerReference><wsnt:Message><lcm:SubmitObjectsRequest><rim:RegistryObjectList><!-- The list of extrinsic objects -->__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

326

Copyright © 2017 IHE International, Inc.

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

8515
8520
8525
8530
8535

<rim:ExtrinsicObject id="Document01" mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">…
</rim:ExtrinsicObject><!-- The list of RegistryPackage objects --><rim:RegistryPackage objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:RegistryPackage" id="Submission01"><rim:Classification classificationNode="urn:uuid:a54d6aa5-d40d43f9-88c5-b4633d873bdd" classifiedObject="Submission01" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="classification01"/></rim:RegistryPackage><rim:RegistryPackage objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:RegistryPackage" id="Folder01"><rim:Classification classificationNode="urn:uuid:d9d542f3-6cc448b6-8870-ea235fbc94c2" classifiedObject="Folder01" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification" id="classification02"/></rim:RegistryPackage></rim:RegistryObjectList></lcm:SubmitObjectsRequest></wsnt:Message></wsnt:NotificationMessage></wsnt:Notify></s:Body></s:Envelope>

3.54.5 Security Considerations

8540

8545

The risk assessment for the Document Metadata Publish transaction is described in the risk
assessment spreadsheet for the Document Metadata Subscription Profile, which is available from
IHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are as
follows:•

The Document Metadata Publisher and the Document Metadata Notification Broker shallbe grouped with a Secure Node or Secure Application in the Audit Trail and Node
Authentication (ATNA) Profile.

•

The use of encrypted TLS is recommended when the transmission is not otherwise
secured (e.g., transmission over a secure network)

3.54.5.1 Audit Record Considerations
The Document Metadata Publish Transaction is an Export event, as defined in ITI TF-2a: Table
3.20.4.1.1.1-1. The actors involved in the transaction shall create audit data in conformance with
DICOM Part 15 “Data Export”/”Data Import”, with the following exceptions.
8550__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

327

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.54.5.1.1 Document Metadata Publisher 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-54”, “IHE Transactions”, “Document Metadata Publish”)

Source (Document Metadata Publisher) (1)
Human Requestor (0..n)
Destination (Document Metadata Notification Broker) (1)Audit Source (Document Metadata Publisher) (1)Patient (0..1)
DocumentEntry/SubmissionSet (1..n)8555

Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination

AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
on

UserIDU

not specialized

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

UserID

C

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

328

Copyright © 2017 IHE International, Inc.

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

Patient(if-known)(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

8560
DocumentEntry
SubmissionSet(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

The Document Metadata Publisher actor shall include one of
the following values, depending on the specific object in themessage:EV("urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”, “IHEXDS Metadata”, “document entry object type”)
EV(“urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248”,“IHE XDS Metadata”, “on-demand document entry objecttype”)EV(urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHEXDS Metadata”, ”submission set classification node”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of the object's EntryUUID attribute.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailCThis element is required, if known:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string)
Value: value of the homeCommunityId

3.54.5.1.2 Document Metadata Notification Broker 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-54”, “IHE Transactions”, “Document Metadata Publish”)

Source (Document Metadata Publisher) (1)Destination (Document Metadata Notification Broker) (1)Audit Source (Document Metadata Notification Broker) (1)DocumentEntry/SubmissionSet (1..n)

Where:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

329

Copyright © 2017 IHE International, Inc.

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

Destination

AuditMessage/
ActiveParticipant

UserIDU

not specialized

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address

UserID

C

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

The machine name or IP address

8565
Audit Source

AuditSourceIDU

not specialized

AuditMessage/
AuditSourceIdentificati
on

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

DocumentEntry
SubmissionSet

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specializedM

The Document Metadata Notification Broker shall include
one of the following values, depending on the specific object
in the message:
EV("urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”,“IHE XDS Metadata”, “document entry object type”)
EV(“urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248”,“IHE XDS Metadata”, “on-demand document entry objecttype”)EV(urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”,“IHE XDS Metadata”, ”submission set classification node”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of the object's EntryUUID attribute.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specializedC

This element is required, if known:
Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal
string)Value: value of the homeCommunityId(AuditMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectIDTypeCode

ParticipantObjectDetail__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

330

Copyright © 2017 IHE International, Inc.

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

3.55 Cross Gateway Patient Discovery [ITI-55]
8570

This section corresponds to transaction ITI-55 of the IHE ITI Technical Framework. Transaction
ITI-55 is used by the Initiating Gateway and Responding Gateway Actors.
3.55.1 Scope
The Cross Gateway Patient Discovery transaction supports the ability for Initiating Gateways
and Responding Gateways to discover mutually known patients. This transaction assumes anenvironment where patient data is well described and high quality demographic data is available.

8575

8580

Because the transaction supports the mutual discovery of patients it can be seen as having dual
purposes.
•

To support a query by the Initiating Gateway requesting a demographically matching
patient from within the Responding Gateway’s community.

•

To support a feed to Responding Gateway announcing that the patient is known by theInitiating Gateway’s community.

This dual nature of the transaction is chosen for scalability purposes, as demographic matchingalgorithms are expensive on a large scale and once a match is identified it is important that boththe initiating and responding sides of the transaction can use the results of that successful match.
8585

8590

The Cross Gateway Patient Discovery transaction has several modes, useful in different
environments:•

Demographic Query only mode – in this mode only the demographics of the patient areincluded in the request. The initiating community does not have, or does not choose to
specify, a patient identifier for use by the Responding Gateway.

•

Demographic Query and Feed – in this mode both the demographic and initiating
community identifier are included in the request.

•

Shared/national Patient Identifier Query and Feed – in this mode only a shared/national
identifier is specified. Demographics are not necessary because matching can be done on
the identifier alone.

This transaction can be used synchronously and asynchronously.
8595

The Cross Gateway Patient Discovery request asks for information about patients whose
demographic data match data provided in the query message. The request is received by the
Responding Gateway Actor. The Responding Gateway indicates in its response whether thecommunity has knowledge of a patient matching the set of demographic data and, if a match isfound, returns the demographics known by the responding community. If more than one match is__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

331

Copyright © 2017 IHE International, Inc.

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

8605

found the Responding Gateway has the option of providing a list 5 of matching patients orreturning nothing. When nothing is returned the Responding Gateway may include in the
response a set of additional demographic attributes which, if supplied, would aid in
disambiguating the multiple matches.
In the case of a match, the Responding Gateway may further update its own cache to indicatethat the initiating community knows this patient and should be queried if data for this patient isdesired.
The criteria used for demographic matching is defined by policy and not specified here, but fully
enabled by the transaction.
3.55.2 Use Case Roles
Initiating
Gateway

Responding
Gateway

Cross Gateway
Patient Discovery

8610
Actor: Initiating Gateway
Role: Requests the Responding Gateway to indicate whether the community has knowledge of apatient matching a set of demographic criteria.
Corresponding HL7 v3 Application Roles:

8615

Person Registry Query Placer (PRPA_AR201303UV02)
Actor: Responding Gateway

8620

Role: If a demographics match is found, returns demographics known by the responding
community. If more than one match is found the Responding Gateway has the option ofproviding a small list of matching patients or returning no match. In the case of no match, theResponding Gateway may provide a list of additional demographic attributes needed todisambiguate multiple matches.

Returning a list of matches may potentially expose information that is unrelated to the patient requested.
Implementers are encouraged to consider ways to keep the number of elements in a list to a minimum. Deployment
organizations may choose to declare a limit to the number of elements allowed to be returned.

5__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

332

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Corresponding HL7 v3 Application Roles:
Person Registry Query Fulfiller (PRPA_AR201304UV02)
8625

3.55.3 Referenced Standard
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

8630

3.55.4 Interaction Diagram
Initiating
Gateway

Responding
Gateway

Cross Gateway Patient
Discovery Request
Cross Gateway Patient
Discovery Response

3.55.4.1 Cross Gateway Patient Discovery Request
The Cross Gateway Patient Discovery Request is implemented using the HL7 Patient Registry
Query by Demographics (PRPA_MT201306UV02) message.
8635

3.55.4.1.1 Trigger Events
The initiating community needs to determine whether a patient is known by another community.
Specific possible trigger events include, but are not limited to:

8640

•

The initiating community registers a new patient who has permitted sharing of healthcare
data with external communities.

•

A healthcare provider within the community requests that records regarding a particularpatient be accessed from a particular external community or all external communities
known.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

333

Copyright © 2017 IHE International, Inc.

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

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 Sections 3.55.4.1.2.1 to 3.55.4.1.2.3.
For each element which is required, the element shall be specified by the Initiating Gateway inthe request and shall be used by the Responding Gateway as part of its demographic matchingalgorithm.

8650

8655

8660

8665

For each element which is optional the element does not need to be specified by the Initiating
Gateway in the request but, if specified, shall be used by the Responding Gateway as part of its
demographic matching algorithm.
The Responding Gateway shall support Asynchronous Web Services Exchange as described in
ITI TF-2x: V.5, Synchronous and Asynchronous Web Services Exchange. If the Initiating
Gateway declares the Asynchronous Web Services Exchange Option it shall also support
Asynchronous Web Services Exchange as described in ITI TF-2x: V.5. Use of Asynchronous
Web Services Exchange is necessary when transactions scale to large numbers of communities
because it allows for more efficient handling of latency and scale.
The Initiating Gateway may specify a duration value in the SOAP Header element of the request.
This value suggests to the Responding Gateway a length of time that the Initiating Gateway
recommends caching any correlation resulting from the interaction. The duration value isspecified in the SOAP Header using the CorrelationTimeToLive element and contains a value
conformant with the xs:duration type defined in http://www.w3.org/TR/xmlschema-2/#duration.
If no CorrelationTimeToLive element is specified in the SOAP Header the Responding Gateway
shall interpret this as a recommendation against caching, unless a mutually agreed policy statesotherwise.
An example of specifying the CorrelationTimeToLive element follows, which recommends
caching of 7 days.
<xcpd:CorrelationTimeToLive>P0Y0M7D</xcpd:CorrelationTimeToLive>8670

3.55.4.1.2.1 Major Components of the Patient Registry Query by Demographics
LivingSubjectName Parameter

8675

This required parameter specifies the name of the person whose information is being queried. If
multiple instances of LivingSubjectName are provided, the receiver shall consider them as
possible alternatives, logically connected with an "or". Within each LivingSubjectName element,a single person name (PN) data item shall be specified in the LivingSubjectName.value attribute.
An Initiating Gateway may specify all, or only a subset of the name parts within the PN data type(e.g., family name). The use attribute of the value element shall not be set to "SRCH".
LivingSubjectAdministrativeGender Parameter

8680

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

334

Copyright © 2017 IHE International, Inc.

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

8685

This required 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.

8690

8695

LivingSubjectId Parameter
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 this parameter is
specified, LivingSubjectName and LivingSubjectBirthTime are optional. This feature allows thisquery to be used when a national/shared patient identifier is known. The identifier specified in
the LivingSubjectId.value attribute is expressed using the II data type. Please see ITI TF-2x:
Appendix E for the use of the II data type for patient identifiers.
The Initiating Gateway has the option of designating one of the identifiers in LivingSubjectId as
the patient identifier that the Responding Gateway may use in an XCA Cross Gateway Query to
the community represented by the Initiating Gateway (see Section 3.55.4.1.2.4) .

8700

LivingSubjectBirthPlaceAddress Parameter
This optional parameter specifies the birth address of the patient.
LivingSubjectBirthPlaceName Parameter
This optional parameter specifies the name of the entity (like hospital name) where the patient
was born.

8705

MothersMaidenName Parameter
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. The use attribute of the value element shall not be set to "SRCH"

8710

PatientTelecom
This optional parameter specifies a telecommunication address or addresses for communication
with the patient.
PrincipalCareProviderId8715

This optional parameter specifies the care provider identifier of a person who has been assigned
as the principal care provider of this patient. The requestor may specify multiple
PrincipalCareProviderId elements which the responder shall consider as possible alternatives,
logically connected with an "or". Within each PrincipalCareProviderId element, a single
identifier shall be specified in the PrincipalCareProviderId.value attribute.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

335

Copyright © 2017 IHE International, Inc.

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

8720

3.55.4.1.2.2 Message Information Model of the Patient Registry Query by
Demographics Message
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.

8725

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:•

The optional attributes ParameterList.id, MatchCriterionList.id, QueryByParameter
responseElementGroupId, QueryByParameter.modifyCode, andQueryByParameter.executionAndDeliveryTime were omitted from the model.

•

QueryByParameter.responsePriorityCode is required and is either I (Immediate) or D
(Deferred). See Section 3.55.6.2 for use of Deferred.

•

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 between 0 and 100.

•

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:

8730

8735

8740

8745

•

PatientStatusCode•

LivingSubjectDeceaseTime•

OtherIDsScopingOrganization•

initialQuantity•

initialQuantityCode

The attributes of this model are described in the following table:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

336

Copyright © 2017 IHE International, Inc.

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

Figure 3.55.4.1.2-1: Patient Registry Query by Demographics Message
Table 3.55.4.1.2-1:
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used to query acommunity for patients matching a set of demographics
information.
Derived from Figure 3.55.4.1.2-1(PRPA_RM201306IHEXCPD)

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, fixedvalue="new"}

The status of the query, shall be "new"responseModalityCode [1..1]
QueryByParameter (CS) {CNE:ResponseModality, fixedvalue="R"}

The mode of the response – always real-time.

responsePriorityCode [1..1]
QueryByParameter (CS) {CNE:QueryPriority}

Either “I” or “D” shall be specified. “I” (Immediate)
indicates that the Responding Gateway is required to send an
immediate response. “D” (Deferred) indicates the
Responding Gateway is required to send a deferred response,
see Section 3.55.6.2.

initialQuantity [0..1]
QueryByParameter (INT)

Not supported, any value will be ignored by responder.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

337

Copyright © 2017 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 to query acommunity for patients matching a set of demographics
information.
Derived from Figure 3.55.4.1.2-1(PRPA_RM201306IHEXCPD)

initialQuantityCode [0..1]
QueryByParameter (CE) {CWE:QueryRequestLimit,
default="RD"}Not supported, any value will be ignored by responder.

MatchAlgorithm

This parameter conveys instructions to the Responding
Gateway specifying the preferred matching algorithm to use
and may be ignored

value [1..1]
ParameterItem (ST)The name of the algorithm

semanticsText [1..1]
ParameterItem (ST){default= "MatchAlgorithm"}
MinimumDegreeMatch

This parameter conveys instructions to the Responding
Gateway specifying minimum degree of match to use in
filtering results and may be ignored

value [1..1]
ParameterItem (INT)The numeric value of the degree of match. Shall be value
between 0 and 100 .

semanticsText [1..1]
ParameterItem (ST){default= "MinimumDegreeMatch"}
This query parameter is a code representing theadministrative 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 ofdates (e.g., December 1, 1959 through March 31, 1960).

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.birthTime"}
LivingSubjectId
value [1..*] (M)ParameterItem (II)A patient identifier, used to assist in finding a match for thequery and, when so designated by the Initiating Gateway,
used by the Responding Gateway in a XCA Cross Gateway
Query directed to the Community designated by thehomeCommunityId value specified in the Control Act
Wrapper – see Section 3.55.4.1.2.4.

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.id"}
This query parameter is the name of a person. If multiple
instances of LivingSubjectName are provided, the receivermust consider them as possible alternatives, logicallyconnected with an "or".

LivingSubjectName__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

338

Copyright © 2017 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 to query acommunity for patients matching a set of demographics
information.
Derived from Figure 3.55.4.1.2-1(PRPA_RM201306IHEXCPD)

value [1..1]
ParameterItem (PN)

Only one instance of the value element is allowed. Onlysome of the name parts may be populated. If, for example,
only the family and given name parts of a person's name aresent, then the query would match all persons with that familyname and given name regardless of their initials. The use
attribute of the value element shall not be set to "SRCH".

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.name"}
PatientAddressThis query parameter is a postal address for corresponding
with a patient. There shall be only a single PatientAddresselement.

value [1..*]
ParameterItem (AD)Multiple instances of the value element within a Patient
Address may be specified and are combined with OR logic.

semanticsText [1..1]
ParameterItem (ST){default= "Patient.addr"}
This query parameter is a patient's birthplace represented as
an address

LivingSubjectBirthPlaceAddress
value [1..*]
ParameterItem (SET<AD>)semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.BirthPlace.Addr"}

This query parameter is a patient's birthplace represented as aplace name

LivingSubjectBirthPlaceName
value [1..*]
ParameterItem (SET<EN>)
semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.BirthPlace.Place.Name"}
PrincipalCareProviderId

This query parameter is the care provider identifier of aperson who has been assigned as the principal care providerof this patient. The requestor may specify multiple
PrincipalCareProviderId elements which responder shallconsider as possible alternatives, logically connected with an"or".

value [1..1]
ParameterItem (II)There shall have only one id in the “value” attribute.

semanticsText [1..1]
ParameterItem (ST){default= "AssignedProvider.id"}__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

339

Copyright © 2017 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 to query acommunity for patients matching a set of demographics
information.
Derived from Figure 3.55.4.1.2-1(PRPA_RM201306IHEXCPD)

MothersMaidenName

This query parameter is the maiden name of a focal person's
mother. It is included as a parameter because it is a common
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 name part of "family" with an
EntityNamePartQualifier of "birth" for the person who is theplayer in a PersonalRelationship of type of "mother" to the
focal person.

value [1..1]
ParameterItem (PN)

A person name. In this case it may consist of only the given
name part, the family name part, or both.

semanticsText [1..1]
ParameterItem (ST){default="Person.MothersMaidenName"}
PatientTelecom

This query parameter is a telecommunications address forcommunicating with a living subject in the context of thetarget patient registry. It could be a telephone number, fax
number or even an email address. There shall be only asingle PatientTelecom element.

value [1..*]
ParameterItem (TEL)

A telecommunications address. The scheme attribute
specifies whether this is a telephone number, fax number,email address, etc. Multiple instances of the value element
within a PatientTelecom may be specified and are combinedwith OR logic.

semanticsText [1..1]
ParameterItem (ST){default= "Patient.telecom"}

3.55.4.1.2.3 Control Act and Transmission Wrappers

8755

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.55.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.55.4.1.2-2: 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 processingModeCode shall be set to T
The acceptAckCode shall be set to AL
There shall be only one receiver Device

The value of ControlActProcess.moodCode shall be set to
EVN
The trigger event code in ControlActProcess.code shall be
set to PRPA_TE201305UV02
If an authorOrPerformer participation is present, the valueof authorOrPerformer.typeCode SHALL be set to AUT__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

340

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
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:
8760

Edition2008/processable/multicacheschemas/PRPA_IN201305UV02.xsd)
3.55.4.1.2.4 Values used by Responding Gateway for a reverse Cross Gateway
Query

8765

8770

The Initiating Gateway shall specify two values in the request which allow the responding
community to generate a reverse Cross Gateway Query in search of data about the patient
identified in the Cross Gateway Patient Discovery request. The two values are
homeCommunityId and community patient id assigning authority.
homeCommunityId – this value is a globally unique identifier for a community – further
defined in Section 3.38.4.1.2.1. The Initiating Gateway shall specify this value in the Cross
Gateway Patient Discovery request unless the Initiating Gateway is not grouped with a
Responding Gateway.
The Responding Gateway uses the homeCommunityId to obtain the Web Services endpoint ofservices that provide access to data in the Initiating Gateway’s community.

8775

The homeCommunityId is specified as the id element within the Organization associated withthe device of the sender. The id element designating the homeCommunityId shall have only theroot element the contents of which is the homeCommunityId.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

341

Copyright © 2017 IHE International, Inc.

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

Figure 3.55.4.1.2.4-1: Send Message Payload

8780

An example of specifying the homeCommunityId element follows, where
homeCommunityId=1.2.3.
<sender typeCode="SND"><device classCode="DEV" determinerCode="INSTANCE">

8785<id root="1.2.840.114350.1.13.999.567"/><asAgent classCode="AGNT"><representedOrganization classCode="ORG" determinerCode="INSTANCE"><!-- homeCommunityId=urn:oid:1.2.3 -->8790<id root="1.2.3"/></representedOrganization></asAgent></device></sender>8795

Community patient id assigning authority – this value designates the assigning authority forthe patient identifier to be used within a reverse Cross Gateway Query. This value is not theassigning authority for all patient identifiers used by that community, but only the patient
identifier used for the patient identified in the query. The Initiating Gateway shall be capable ofspecifying this value in the Cross Gateway Patient Discovery request.
The Responding Gateway may use the specified assigning authority to identify which of the
LivingSubjectID values to use in a reverse Cross Gateway Query.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

342

Copyright © 2017 IHE International, Inc.

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

The community patient id assigning authority is specified as the id element within theassignedDevice associated with the authorOrPerformer element. The id element designating thecommunity patient id assigning authority shall have only the root element, the contents of which
designate the assigning authority of the LivingSubjectId to be used in the reverse Cross Gateway
Query.

8805

An example of specifying the community patient id assigning authority element follows, where
the assigning authority specified is 1.2.840.114350.1.13.99997.2.3412 (see highlighted text)
which identifies the first LivingSubjectID ( root="1.2.840.114350.1.13.99997.2.3412"
extension="1234") as the patient identifier to be used in a reverse Cross Gateway Query. In
essence, the highlighted text must match to designate the patient identifier.

8810<controlActProcess classCode="CACT" moodCode="EVN"><code code="PRPA_TE201305UV02" codeSystem="2.16.840.1.113883.1.6"/><!-- Identifies the first LivingSubjectID in the parameterList as the patient

8815

Identifier to be used by responder in a reverse Cross Gateway Query --><authorOrPerformer typeCode="AUT"><assignedDevice><id root="1.2.840.114350.1.13.99997.2.3412"/></assignedDevice>

8820</authorOrPerformer><queryByParameter><queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/>

8825<statusCode code="new"/><parameterList><livingSubjectBirthTime><value value="19630804"/><semanticsText>LivingSubject..birthTime</semanticsText></livingSubjectBirthTime>

8830<livingSubjectName><value><given>Jimmy</given><family>Jones</family>

8835</value><semanticsText>LivingSubject.name</semanticsText></livingSubjectName><LivingSubjectId><value root="1.2.840.114350.1.13.99997.2.3412" extension="1234"/><semanticsText>LivingSubject.id</semanticsText>

8840</LivingSubjectId><LivingSubjectId><value root="2.16.840.1.113883.4.1" extension="58910"/><semanticsText>LivingSubject.id</semanticsText></LivingSubjectId>

8845</parameterList></queryByParameter></controlActProcess>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

343

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Comparison of homeCommunityId and assigning authority

8850

8855

8860

The value of homeCommunityId is an OID which may, or may not, also be an assigningauthority. An assigning authority is designated by an OID and issues identifiers, in this casepatient identifiers. A community’s patient identifier assigning authority issues patient identifiers
for patients managed by the community. It is possible for there to be more than one patient
identifier assigning authority in a community. The Initiating Gateway must specify the rightpatient identifier assigning authority for the patient being described. There is only one
homeCommunityId per community. This OID may also be used by the community as the patient
identifier assigning authority, but this is not required and should not be expected. While both
values are OID’s they have no necessary relationship. In general it is expected that the
homeCommunityId will be assigned by an organization which governs the interaction amongcommunities. In many countries this will be facilitated by the government who will manage thecommunity level agreements necessary for sharing and also assign homeCommunityIds. An
assigning authority has no expected level of management, and there may be multiple patient
identifier assigning authorities within a community.
3.55.4.1.3 Expected Actions

8865

8870

If responsePriorityCode is “I” the Responding Gateway shall return a Find Candidates Response
message as specified in Section 3.55.4.2. The response message uses the Application
Acknowledgement transmission wrapper, as specified in ITI TF-2x: O.1.3, and no otheracknowledgments are part of this the transaction.
If responsePriorityCode is “D” and the Responding Gateway does not support the Deferred
Response Option, it shall return an application error in the HL7 V3 Accept Acknowledgementwith acknowledgeDetail to indicate Unsupported Processing Mode.
<MCCI_IN000002UV01 …
( . . . )8875

<acknowledgement><typeCode code="AE"/><targetMessage><id root="22a0f9e0-4454-11dc-a6be-3603d6866807"/></targetMessage><acknowledgementDetail typeCode="E">8880<code code="NS250" displayName="Unsupported processing mode"/><text>Deferred Response not supported.</text></acknowledgementDetail></acknowledgement></MCCI_IN000002UV01>

8885

If the Responding Gateway supports the Deferred Response Option, it shall respond as describedin Section 3.55.6.2.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

344

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
If the Responding Gateway is unable to process the request due to an internal error, such as the
local Master Patient Index system is offline, the Responding Gateway shall return an application
error as described in Section 3.55.4.2.3 Case 5.
8890

The community associated with the Responding Gateway may make use of thehomeCommunityId and community patient identifier assigning authority by initiating a Cross
Gateway Query. See Section 3.55.4.1.2.4 for more information. This provisioning of the
Responding Gateway community may be cached indefinitely, but efforts are needed to ensurethat changes are properly reflected. For more detail about this issue refer to Section 3.55.4.2.3.1.

8895

3.55.4.1.3.1 Query Parameter Processing
The Responding Gateway shall be capable of accepting, searching on, and responding withattributes in the Query Person by Demographics message.

8900

Handling of phonetic issues, alternate spellings, upper and lower case, accented characters, etc.,
if deemed appropriate, is to be supported by the Responding Gateway rather than by theInitiating Gateway. The Responding Gateway shall return any matches to the query parametersthat reflect a high degree of match, after consideration of all policy constraints; IHE does notfurther specify matching requirements, except as already discussed in the LivingSubjectName
parameter description.
3.55.4.2 Cross Gateway Patient Discovery Response

8905

The Cross Gateway Patient Discovery Response is implemented using the HL7 Patient Registry
Find Candidates Response PRPA_MT201310UV02) message.
3.55.4.2.1 Trigger Events

8910

The Patient Registry Find Candidates Response message (PRPA_MT201310UV02) is sent by
the Responding Gateway in response to the query (PRPA_MT201306UV02) message previously
received.
3.55.4.2.2 Message Semantics
The components of the message with cardinality greater than 0 (as shown below) are required,
and the detailed description of the message is provided in Sections 3.55.4.2.2.1 to 3.55.4.2.2.7.
All other attributes of the message are optional.

8915

8920

For each element that is required this means that it shall be provided by Responding Gateway,
unless not available, and shall be accepted by requestor but requestor is not required to process
the value in any way, only accept it without any error.
The Responding Gateway shall support Asynchronous Web Services Exchange as described in
ITI TF-2x: V.5, Synchronous and Asynchronous Web Services Exchange. If the Initiating
Gateway declares the Asynchronous Web Services Exchange Option it shall also support
Asynchronous Web Services Exchange as described in ITI TF-2x: V.5. Use of Asynchronous
Web Services Exchange is necessary when transactions scale to large numbers of communities
because it allows for more efficient handling of latency and scale.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

345

Copyright © 2017 IHE International, Inc.

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

8925

8930

The Responding Gateway may specify a duration value in the SOAP Header element of the
response. This value suggests to the Initiating Gateway a length of time that the Responding
Gateway recommends caching any correlation resulting from the interaction. The duration valueis specified in the SOAP Header using the CorrelationTimeToLive element and contains a value
conformant with the xs:duration type defined in http://www.w3.org/TR/xmlschema-2/#duration.
If no CorrelationTimeToLive element is specified in the SOAP Header the Initiating Gateway
shall interpret this as a recommendation against caching, unless a mutually agreed policy statesotherwise.
An example of specifying the CorrelationTimeToLive element follows, which recommends
caching of 7 days.
<xcpd:CorrelationTimeToLive>P0Y0M7D</xcpd:CorrelationTimeToLive>8935

3.55.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 Section 3.44.4.1.2.1. The only additional component is the QueryMatchObservation
class.

8940

Query Match Observation
The QueryMatchObservation class is used to convey information about the quality of thematch for each record returned by the query response.
3.55.4.2.2.2 Message Information Model of the Patient Registry Find Candidates
Response Message

8945

8950

8955

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•

guarantor•

guardian•contactParty__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

346

Copyright © 2017 IHE International, Inc.

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

asMember•careGiver•

asStudent

The following participations are omitted:
8965•

subjectOf2 (administrativeObservation)•

coveredPartyOf (coverage)

Figure 3.55.4.2.2-1: Patient Registry Find Candidates Response Message

8970

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.55.4.2.2-1: Attributes
PRPA_HD201310IHE
Patient Registry Find Candidates Response

This HMD extract defines the message used
to return records from a patient registry in
response to a Find Candidates Query.
Derived from Figure 3.55.4.2.2-1(PRPA_RM201310IHE)

Patient

The primary record for the focal personclassCode [1..1] (M)Patient (CS) {CNE:PAT}

Structural attribute; this is a "patient" role__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

347

Copyright © 2017 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
to return records from a patient registry in
response to a Find Candidates Query.
Derived from Figure 3.55.4.2.2-1(PRPA_RM201310IHE)

id [1..1] (M)Patient (SET<II>)

The Patient Identifier to be used in subsequent
XCA Cross Gateway Query transactions related
to this patient when sent to the Responding
Gateway sending the response. All other patient
identifiers shall be specified in the OtherIDs.id
attribute.

statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in apatient registry (based on the RIM role classstate-machine). This record is active.

confidentialityCode [0..*]Patient (SET<CE>) {CWE:Confidentiality}

Value(s) that control the disclosure of
information about this living subject as a patient

veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status
granted by the scoper organization, often
resulting in preferred treatment and special
considerations. Examples include board
member, diplomat.

PersonA subtype of LivingSubject representing ahuman being
Either Person.name or Patient.id must be nonnull

classCode [1..1] (M)Person (CS) {CNE:PSN, fixed value= "PSN"}

Structural attribute; this is a "person" entity

determinerCode [1..1] (M)Person (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}

Structural attribute; this is a specific personname [1..*]
Person (BAG<PN>)

Name(s) for this person. May be null i.e.,<name nullFlavor=”NA”/> only if the request
contained only a patient identifier and no
demographic data.

telecom [0..*]
Person (BAG<TEL>)

Telecommunication address(es) for
communicating with this person

administrativeGenderCode [0..1]
Person (CE) {CWE:AdministrativeGender}

A value representing the gender (sex) of thisperson. Note: this attribute does not include
terms related to clinical gender which is acomplex physiological, genetic and sociologicalconcept that requires multiple observations inorder to be comprehensively described.

birthTime [0..1]
Person (TS)The date and time this person was bornbirthPlace
deceasedInd [0..1]
Person (BL)An indication that this person is deaddeceasedTime [0..1]
Person (TS)The date and time this person diedmultipleBirthInd [0..1]
Person (BL)An indication that this person was part of amultiple birth__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

348

Copyright © 2017 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
to return records from a patient registry in
response to a Find Candidates Query.
Derived from Figure 3.55.4.2.2-1(PRPA_RM201310IHE)

multipleBirthOrderNumber [0..1]
Person (INT)The order in which this person was born if partof a multiple birth

addr [0..*]
Person (BAG<AD>)

Address(es) for corresponding with this person

maritalStatusCode [0..1]
Person (CE) {CWE:MaritalStatus}

A value representing the domestic partnershipstatus of this person

religiousAffiliationCode [0..1]
Person (CE) {CWE:ReligiousAffiliation}

A value representing the primary religious
preference of this person

raceCode [0..*]
Person (SET<CE>) {CWE:Race}

A set of values representing the races of thispersonethnicGroupCode [0..*]
Person (SET<CE>) {CWE:Ethnicity}

A set of values representing the ethnic groups ofthis person

OtherIDs

Used to capture additional identifiers for the
person such as a Drivers’ license or Social
Security Number.

classCode [1..1] (M)Role (CS) {CNE:ROL}

Structural attribute. This can be any
specialization of "role" except for Citizen, or
Employee.,id [1..*] (M)Role (SET<II>)

One or more identifiers issued to the focal
person by the associated scopingOrganization(e.g., identifiers from a different Patient Identity
Domain).

PersonalRelationship

A personal relationship between the focal living
subject and another living subject

classCode [1..1] (M)Role (CS) {CNE:PRS, fixed value= "PRS"}

Structural attribute; this is a "personal
relationship" role

id [0..*]
Role (SET<II>)

Identifier(s) for this personal relationshipcode [1..1] (M)Role (CE) {CWE:PersonalRelationshipRoleType}A required value specifying the type of personal
relationship between the relationshipHolder andthe scoping living subject drawn from the
PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

CitizenUsed to capture person information relating tocitizenship.

classCode [1..1] (M)Role (CS) {CNE:CIT, fixed value= "CIT"}

Structural attribute; this is a "citizen" role

id [0..*]
Role (SET<II>)

Identifier(s) for the focal person as a citizen of anationNationA politically organized body of people bonded
by territory and known as a nation.

classCode [1..1] (M)Organization (CS) {CNE:NAT, fixed value= "NAT"}

Structural attribute; this is a 'nation' type ofentity__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

349

Copyright © 2017 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
to return records from a patient registry in
response to a Find Candidates Query.
Derived from Figure 3.55.4.2.2-1(PRPA_RM201310IHE)

determinerCode [1..1] (M)Organization (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}

Structural attribute; this is a specific entity

code [1..1] (M)Organization (CD) {CWE:NationEntityType}A value that identifies a nation statename [0..1]
Organization (ON)A non-unique textual identifier or moniker forthis nation

Employee

A relationship of the focal person with anorganization 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 nature of the work actually
performed. For example, it can be used tocapture whether the person is a Military Veteranor not..

classCode [1..1] (M)Employee (CS) {CNE:EMP}

Structural attribute; this is an "employee" role

statusCode [0..1]
Employee (CS) {CNE:RoleStatus}

A value specifying the state of this employment
relationship (based on the RIM Role class statemachine), for example, active, suspended,
terminated.

occupationCode [0..1]
Employee (CE) {CWE:EmployeeOccupationCode}A code qualifying the classification of kind-ofwork based upon a recognized industry or
jurisdictional standard. OccupationCode is used
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.

LanguageCommunication

A language communication capability of the
focal person

languageCode [1..1] (M)LanguageCommunication (CE) {CWE:HumanLanguage}

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, AmericanSign

preferenceInd [0..1]
LanguageCommunication (BL)An indicator specifying whether or not thislanguage is preferred by the focal person for the
associated mode

QueryMatchObservation

Used to convey information about the quality ofthe match for each record.

classCode [1..1] (M)Observation (CS)
{CNE:http://hl7.org/v3ballot2007may/html/infrastru

Structural attribute – this is an observation

cture/vocabulary/ActClass.htm - ActClass, default="OBS"}__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

350

Copyright © 2017 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
to return records from a patient registry in
response to a Find Candidates Query.
Derived from Figure 3.55.4.2.2-1(PRPA_RM201310IHE)

moodCode [1..1] (M)Observation (CS)
{CNE:http://hl7.org/v3ballot2007may/html/infrastru

Structural attribute – this is an event

cture/vocabulary/ActMood.htm - ActMood, default="EVN"}

code [1..1] (M)Observation (CD) {CWE:QueryMatchObservationType}A code, identifying this observation as a querymatch observation.

value [1..1] (M)QueryMatchObservation (INT)

A numeric value indicating the quality of matchfor 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).

3.55.4.2.2.3 Control Act and Transmission Wrappers
8975

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.55.4.4.2-2: 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 processingModeCode shall be set to T
The acceptAckCode shall be set to NE
There shall be only one receiver Device

The value of ControlActProcess.moodCode shall be set to
EVN
The trigger event code in ControlActProcess.code shall be
set to PRPA_TE201306UV02
There shall be zero or more RegistrationEvents present inthis message.
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 inthis message
The QueryAck.resultTotalQuantity,
QueryAck.resultCurrentQuantity, andQueryAck.resultRemainingQuantity attributes shall not be
populated.
There shall be a QueryByParameter copy of the original
query which shall be in the control act wrapper following
the queryAck element.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

351

Copyright © 2017 IHE International, Inc.

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

8980

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 Appendix W. The schemas from the
HL7 V3 2008 Normative Edition can be found at:
Edition2008/processable/multicacheschemas/PRPA_IN201306UV02.xsd).
3.55.4.2.2.4 Specifying homeCommunityId in Response

8985

The homeCommunityId is a globally unique identifier for a community – further defined in
Section 3.38.4.1.2.1. The Responding Gateway shall specify this value within every
RegistrationEvent element in the Cross Gateway Patient Discovery response.
The Responding Gateway may specify the same homeCommunityId in every RegistrationEvent,or may specify different homeCommunityId’s. The Initiating Gateway shall interpret multiple
RegistrationEvents as follows:

8990

8995

9000

•

Multiple RegistrationEvents with the same homeCommunityId represent multiple
matches within the homeCommunityId identified community. The Initiating Gateway
may choose one of the matches to use for subsequent processing.

•

Each set of RegistrationEvents with the same homeComunityId represents a different
possible source for documents, so in order to get the complete list of relevant documents
for the patient, the Initiating Gateway shall select at least one RegistrationEvent fromeach set with the same homeCommunityId and use the resulting collection of patient
identifiers for subsequent processing. See ITI TF-1: 27.3.2.2 for an introduction to thisenvironment.

The homeCommunityId is specified as the id element within the assignedEntity of the custodianof the RegistrationEvent. The id element designating the homeCommunityId shall have only theroot element, the contents of which is the homeCommunityId.
The following example shows part of a response specifying a homeCommunityId value of
urn:oid:1.2.840.114350.1.13.99998.8734.

9005<subject typeCode="SUBJ"><registrationEvent classCode="REG" moodCode="EVN"><id nullFlavor="NA"/><statusCode code="active"/>9010<subject1 typeCode="SBJ">… (details of the matching patient)</subject1><custodian typeCode="CST"><assignedEntity classCode="ASSIGNED"><id root="1.2.840.114350.1.13.99998.8734"/>

9015<code code="SupportsHealthDataLocator"
codeSystem="1.3.6.1.4.1.19376.1.2.27.2"/></assignedEntity></custodian></registrationEvent>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

352

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</subject>9020

3.55.4.2.2.5 Specifying support as a Health Data Locator
The Responding Gateway shall specify its support for this patient as a Health Data Locator. This
specification is a coded value within the assignedEntity of the custodian of theRegistrationEvent. The valid codes for this designation are described in Table 3.55.4.4.2-3. The
codeSystem for these code elements is 1.3.6.1.4.1.19376.1.2.27.2.

9025

Table 3.55.4.4.2-3: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.2
Value for code
NotHealthDataLocator

Meaning of code
This community does not maintain externally available location
information about this patient and will respond with no data to a Patient
Location Query transaction related to this patient.

The following example shows part of a response specifying no support for Health Data Locator:

9030<subject typeCode="SUBJ"><registrationEvent classCode="REG" moodCode="EVN"><id nullFlavor="NA"/><statusCode code="active"/><subject1 typeCode="SBJ">… (details of the matching patient)

9035</subject1><custodian typeCode="CST"><assignedEntity classCode="ASSIGNED"><id root="1.2.840.114350.1.13.99998.8734"/>

9040<code code="NotHealthDataLocator"
codeSystem="1.3.6.1.4.1.19376.1.2.27.2"/></assignedEntity></custodian></registrationEvent></subject>

3.55.4.2.2.6 Special handling for more attributes requested
9045

9050

9055

The Responding Gateway has the option of informing the Initiating Gateway when additional
demographic attributes may result in a match. This would most often be used in cases where thesecurity and privacy policies do not allow release of patient data unless and until there is a levelof assurance that the same patient is referenced. In this case the Responding Gateway cannot
return a matching patient or patients because the level of assurance is not great enough. If theInitiating Gateway were able to specify further demographic attributes the Responding Gateway
might have greater assurance of the match and thus be able to return the match information.
To indicate this situation in its response the Responding Gateway codes a DetectedIssueEvent
within the controlActProcess element, where the code in the actOrderRequired element
references one of the coded elements described in Table 3.55.4.4.2-4. There may be as many
triggerFor elements, each of them containing an ActOrderRequired element, as needed to code__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

353

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
the attributes which would increase the assurance of the match. The codeSystem for these code
elements is 1.3.6.1.4.1.19376.1.2.27.1.

Figure 3.55.4.2.2-2: RMIM for DetectedIssueEvent
9060

Table 3.55.4.4.2-4: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.1
Value for code
LivingSubjectAdministrativeGenderRequested

Meaning of code
Requests the LivingSubjectAdministrativeGender attribute be specified

PatientAddressRequested

Requests the PatientAddress attribute be specified

PatientTelecomRequested

Requests the PatientTelecom attribute be specified

LivingSubjectBirthPlaceNameRequested

Requests the LivingSubjectBirthPlaceName attribute be specified

LivingSubjectBirthPlaceAddressRequested

Requests the LivingSubjectBirthPlaceAddress attribute be specified

MothersMaidenNameRequested

Requests the MothersMaidenName attribute be specified

The following example shows part of a response requesting the PatientAddress andPatientTelecom attributes.
9065

9070

9075

<detectedIssueEvent classCode="ALRT" moodCode="EVN"><code code="ActAdministrativeDetectedIssueCode" codeSystem="2.16.840.1.113883.5.4"/><triggerFor typeCode="TRIG"><actOrderRequired classCode="ACT" moodCode="RQO"><code code="PatientAddressRequested” codeSystem="1.3.6.1.4.1.19376.1.2.27.1"/></actOrderRequired></triggerFor><triggerFor typeCode="TRIG"><actOrderRequired classCode="ACT" moodCode="RQO"><code code="PatientTelecomRequested” codeSystem="1.3.6.1.4.1.19376.1.2.27.1"/></actOrderRequired></triggerFor></detectedIssueEvent>3.55.4.2.2.7 Specify details about problems handling request
The Responding Gateway has the option of informing the Initiating Gateway with some detailregarding a problem handling the request.
9080

The Responding Gateway may code a DetectedIssueEvent within the controlActProcess element,
where the code in the detectedIssueManagement element references one of the coded elements__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

354

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
described in Table 3.55.4.4.2-5. The codeSystem for these code elements is
1.3.6.1.4.1.19376.1.2.27.3.
Table 3.55.4.4.2-5: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.3
Value for code

9085

9090

Meaning of code

ResponderBusy

The responder was not able to process the request because it is currently
overloaded.

AnswerNotAvailable

The answer is not available. Human intervention may be needed.

InternalError

The responder was not able to respond due to an internal error orinconsistency.

The following example shows part of a response specifying that the responder is busy.
<detectedIssueEvent classCode="ALRT" moodCode="EVN"><code code="ActAdministrativeDetectedIssueCode" codeSystem="2.16.840.1.113883.5.4"/><mitigatedBy typeCode="MITGT"><detectedIssueManagement classCode="ACT" moodCode="EVN"><code code="ResponderBusy” codeSystem="1.3.6.1.4.1.19376.1.2.27.3"/></detectedIssueManagement></mitigatedBy></detectedIssueEvent>9095

3.55.4.2.3 Expected Actions
The Initiating Gateway shall accept a SOAP fault representing a transmission error. An internal
error in the Responding Gateway is covered under Case 5. The Initiating Gateway shall act on avalid query response as described by the following 5 cases:

9100

Case 1: The Responding Gateway finds exactly one patient record matching the criteria sent in
the query parameters.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

9105

9110

One RegistrationEvent (and the associated Patient role, subject of that event) is returned from thepatient information source for the patient record found. The community associated with theInitiating Gateway may use the patient demographics and identifiers to run an independentmatching algorithm to ensure the quality of the match. If the Initiating Gateway is grouped with
an XCA Initiating Gateway, it may use the designated patient identifier in a Cross Gateway
Query to get information about records related to the patient. This grouped Initiating Gateway
shall be able to handle situations where the homeCommunityId in the response is different thanthe original homeCommunityId used to identify the XCPD Responding Gateway. In particular,
the Initiating Gateway should use the new homeCommunityId to look up a potentially different
endpoint. The Initiating Gateway may also choose to cache the correlation for future use (seeSection 3.55.4.2.3.1 for more information about caching).
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

355

Copyright © 2017 IHE International, Inc.

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

9115

Case 2: The Responding Gateway finds more than one patient close to matching the criteria sentin the query parameters and the policy allows returning multiple.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

9120

9125

One RegistrationEvent (and the associated Patient role, subject of that event) is returned for eachpatient record found. The community associated with the Initiating Gateway may run its own
matching algorithm to select from the list of returned patients. If a correlation is found, theResponding Gateway may continue as if only one entry had been returned, see Case 1. If a
correlation is still not clear it is expected that human intervention is required, depending on thepolicies of the Initiating Gateway’s community.
Case 3: The Responding Gateway finds more than one patient close to matching the criteria sentin the query parameters but no matches close enough for the necessary assurance level and more
attributes might allow the Responding Gateway to return a match.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

9130

9135

No RegistrationEvent is returned in the response, but the Responding Gateway provides asuggestion in terms of demographics that may help identify a match. The mechanism forspecifying the suggestion is detailed in Section 3.55.4.2.2.6 for description of coding of the
response. The Initiating Gateway may use this feedback to initiate a new Cross Gateway Patient
Discovery request including the requested additional attributes.
Case 4: The Responding Gateway finds no patients anywhere close to matching the criteria sentin the query parameters.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
NF (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

9140

9145

There is no RegistrationEvent returned in the response. The Initiating Gateway can assume thispatient has no healthcare information held by the community represented by the Responding
Gateway. This lack of correlation may be cached, see Section 3.55.4.2.3.1 for more information
about caching.
Case 5: The Responding Gateway is unable to satisfy the request. This may be because therequest came synchronously and an asynchronous request may be feasible, or because the
Responding Gateway is overloaded with other requests and does not expect to answer for asignificant period of time. It may also be that the Responding Gateway may need some manual
configuration update to authorize responder or another error occurred while the Responding
Gateway was processing the message payload.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper).
AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

356

Copyright © 2017 IHE International, Inc.

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

There is no RegistrationEvent returned in the response. See Section 3.55.4.2.2.7 for more
information about coding errors for this case.
3.55.4.2.3.1 Caching (Informative)

9155

9160

This section presents some considerations regarding caching of information learned through the
Cross Gateway Patient Discovery transaction. There are no requirements regarding caching of
the information, as this is a complex issue and must be addressed as part of deployment. The
caching resulting from receiving and responding to the query is not updating any local
information but only saving a record in a cache if so desired.
Both the requesting and responding side of the Cross Gateway Patient Discovery transaction gain
knowledge through this transaction. That knowledge may be used immediately, by sending a
Cross Gateway Query transaction, or may be cached for use at some other time (or both). Thissection addresses caching considerations when the Cross Gateway Patient Discovery transaction
is used in the Demographic Query and Feed mode. Other modes are a simplification of this modewith corresponding simplifications of the considerations presented.
The knowledge gained on both sides can be represented as a tuple:

9165

9170

•

LocalPid – Local patient identifier and demographics associated with that identifier•

ExternalCommunityId – The homeCommunityId of another community.

•

ExternalPid – The patient identifier for the same patient as LocalPid within thecommunity identified by ExternalCommunityId. This identifier also has associateddemographics

For the Initiating Gateway the ExternalPid may be null indicating that the community
represented by ExternalCommunityId has no correlating patient identifier available.
The tuple represents a correlation, or lack thereof, of patients in a pair of communities. The
validity of this correlation may degrade over time, as changes in demographics, merge/link
events and new patient registrations affect the correlation.

9175

Local changes in demographics, merge/link
When a local change in demographics or a merge/link event affects the LocalPid, the community
may initiate a Cross Gateway Patient Discovery request to validate the correlation.
External changes in demographics, merge/link

9180

When an external change in demographics or merge/link event occurs, the external community
may initiate a Cross Gateway Patient Discovery request which, when received, can be used to reassess the correlation and adjust accordingly. Mutually agreed policies for use of theCorrelationTimeToLive SOAP header may enable greater assurance that changes are reflected
when needed.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

357

Copyright © 2017 IHE International, Inc.

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

When the Initiating Gateway’s community discovers the lack of correlation to its local patient(ExternalPid null) it may monitor incoming Cross Gateway Patient Discovery transactions inorder to discover later if that patient has arrived in the Responding Gateway’s community.
3.55.5 Security Considerations
No transaction specific security considerations.

9190

3.55.5.1 Security Audit Considerations
The Cross Gateway Patient Discovery transaction is a Query Information event as defined in ITI
TF-2a: 3.20.4.1.1.1-1.
The actors involved shall record audit events according to the following:
3.55.5.1.1 Initiating Gateway 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-55”, “IHE Transactions”, “Cross Gateway Patient
Discovery”)

Source (Initiating Gateway) (1)
Human Requestor (0..n)
Destination (Responding Gateway) (1)Audit Source (Initiating Gateway) (1)Patient (0) No patient identifiers are included in this audit message.
Query Parameters (1)9195

Where:
SourceAuditMessage/
ActiveParticipant

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

358

Copyright © 2017 IHE International, Inc.

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

UserID

M

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

Destination

UserID

M

SOAP endpoint URI.

AuditMessage/
ActiveParticipant

AlternativeUserIDU

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-55, “IHE Transactions”, “Cross Gateway Patient Discovery”)

ParticipantObjectSensitivityU

not specialized

AuditMessage/
ActiveParticipant

Identity of the human that initiated the transaction.

9200

Audit Source
AuditMessage/
AuditSourceIdentificati
on

Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded.

ParticipantObjectDetailM

The value of “ihe:homeCommunityID” as the value of the attributetype and the value of the homeCommunityID as the value of theattribute value.

3.55.5.1.2 Responding Gateway 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-55”, “IHE Transactions”, “Cross Gateway Patient
Discovery”)

Source (Initiating Gateway) (1)Destination (Responding Gateway) (1)__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

359

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Audit Source (Responding Gateway) (1)Patient (0..n) one for each patient whose demographic information was returned in the response.
Query Parameters (1)9205

Where:
SourceAuditMessage/
ActiveParticipant

Destination

AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

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.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

9210__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

360

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Query
Parameters(AuditMessage/
ParticipantObjectIde
ntification)

9215

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-55”, “IHE Transactions”, “Cross Gateway Patient Discovery”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded.

ParticipantObjectDetailM

The value of “ihe:homeCommunityID” as the value of the attributetype and the value of the homeCommunityID as the value of theattribute value.

3.55.6 Protocol Requirements
The Cross Gateway Patient Discovery request and response will be transmitted using
Synchronous or Asynchronous Web Services Exchange, according to the requirements specified
in ITI TF-2x: Appendix V. If the Deferred Response Option is being used the request andresponse will be transmitted as described in Section 3.55.6.2.

9220

The following WSDL naming conventions shall apply:
query message-> "PRPA_IN201305UV02_Message"

The following WSDL snippet describes the type for this message:
9225

9230

…
<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>9235…
The message is described by the following snippet:…
<message name="PRPA_IN201305UV02_Message"><part element="hl7:PRPA_IN201305UV02" name="Body"/></message>…

9240

3.55.6.1 Web Services Port Type and Binding Definitions
Responding Gateway:
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “RespondingGateway”.
The following WSDL naming conventions shall apply:

wsdl:definitions/@name="RespondingGateway":__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

361

Copyright © 2017 IHE International, Inc.

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

9250

9255

ITI-55 query-> "PRPA_IN201305UV02_Message"
ITI-55 response-> "PRPA_IN201306UV02_Message"
accept acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "RespondingGateway_PortType"
ITI-55 operation-> "RespondingGateway_PRPA_IN201305UV02"
ITI-55 Deferred Response operation ->“RespondingGateway_Deferred_PRPA_IN201305UV02”
SOAP 1.2 binding-> "RespondingGateway_Binding_Soap12"
SOAP 1.2 port-> "RespondingGateway_Port_Soap12"

Initiating Gateway:
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “InitiatingGateway”.
The following WSDL naming conventions shall apply:

9260

9265

wsdl:definitions/@name="InitiatingGateway":
ITI-55 response-> "PRPA_IN201306UV02_Message"
accept acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "InitiatingGateway_PortType"
ITI-55 Deferred Response operation ->“InitiatingGateway_Deferred_PRPA_IN201306UV02”
SOAP 1.2 binding-> "InitiatingGateway_Binding_Soap12"
SOAP 1.2 port-> "InitiatingGateway_Port_Soap12"

The following WSDL snippets specify the Cross Gateway Patient Discovery Query Port Typeand Binding definitions, according to the requirements specified in ITI TF-2x: Appendix V.
3.55.6.1.1 Port Type
9270
Responding Gateway:

9275

9280

<portType name="RespondingGateway_PortType"><operation name="RespondingGateway_PRPA_IN201305UV02"><input message="tns:PRPA_IN201305UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/><output message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201306UV02:CrossGatewayPatientDiscovery"/></operation><operation name="RespondingGateway_Deferred_PRPA_IN201305UV02"><input message="tns:PRPA_IN201305UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201305UV02:Deferred:CrossGatewayPatientDiscovery"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/></operation></portType>9285__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

362

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Initiating Gateway:
9290<portType name="InitiatingGatewayDeferredResponse_PortType"><operation name="InitiatingGateway_Deferred_PRPA_IN201306UV02"><input message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201306UV02:Deferred:CrossGatewayPatientDiscovery"/>9295<output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.55.6.1.2 Bindings
SOAP 1.2 binding:
9300

Responding Gateway:…

<binding name="RespondingGateway_Binding_Soap12" type="RespondingGateway_PortType"><wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="RespondingGateway_PRPA_IN201305UV02"><wsoap12:operation soapActionRequired="false"/>9305<input><wsoap12:body use="literal"/></input><output>

9310<wsoap12:body use="literal"/></output></operation><operation name="RespondingGateway_Deferred_PRPA_IN201305UV02"><wsoap12:operation soapActionRequired="false"/><input>9315<wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/>

9320</output>…

</operation></binding>__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

363

Copyright © 2017 IHE International, Inc.

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

Initiating Gateway:…

9330<binding name="InitiatingGatewayDeferredResponse_Binding"
type="tns:InitiatingGatewayDeferredResponse_PortType"><soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="InitiatingGateway_Deferred_PRPA_IN201306UV02"><soap12:operation soapActionRequired="false"/><input><soap12:body use="literal"/></input><output>

9335<soap12:body use="literal"/></output>

9340<operation></binding>…

Informative WSDL for the Responding Gateway is available online on the IHE FTP site, see ITI
TF-2x: Appendix W.
3.55.6.2 Deferred Response Option
9345

9350

The Deferred Response Message pattern is a message exchange pattern where therequest/response web service message exchange has been converted into two request/response
message exchange patterns, where the original request and response messages are used as therequest portion of each message and an application acknowledgement is the response. Figure
3.55.6.2-1 illustrates this pattern as it is used for the Cross Gateway Patient Discovery [ITI-55]
transaction.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

364

Copyright © 2017 IHE International, Inc.

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

Initiating
Gateway(Deferred
Response
RequestInvocation)

Cross Gateway Patient
Discovery Request Message
Request Application Acknowledgement(Deferred
Processing by
Responding
Gateway)(Deferred
Response
Response
Invocation)

Cross Gateway Patient
Discovery Response Message

Response Application Acknowledgement

Figure 3.55.6.2-1: Deferred Response Message Pattern

Cross Gateway Patient Discovery Request Message
9355

9360

The Initiating Gateway that supports the Deferred Response Option may request the use ofDeferred Response message exchange by specifying the following in the Cross Gateway Patient
Discovery Request Message:•

The WS-Addressing Action value shall be urn:hl7org:v3:PRPA_IN201305UV02:Deferred: CrossGatewayPatientDiscovery•

The responsePriorityCode element shall be set to a value of ‘D’ to represent the deferred
processing mode.

•

The respondTo element of the transmission wrapper, see the figure in Section
3.55.4.1.2.4, shall contain a telecom element with the Web Services Endpoint where theresponse shall be sent.

9365

Example of specifying the respondTo element:

9370<respondTo typeCode="RSP"><telecom value="service entry point url"
<entityRsp classCode="ENT" determinerCode="INSTANCE" xsi:nil="true"/></respondTo>

Cross Gateway Patient Discovery Request Application Acknowledgement Message
If the Responding Gateway supports the Deferred Response Option it shall respond with an HL7
V3 Accept Acknowledgement message (MCCI_IN000002UV01). The WS-Addressing Action
value shall be urn:hl7-org:v3:MCCI_IN000002UV01.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

365

Copyright © 2017 IHE International, Inc.

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

Cross Gateway Patient Discovery Response Message

9380

The Responding Gateway will process the Cross Gateway Patient Discovery Request Message
and generate a Cross Gateway Patient Discovery Response Message following all the applicablerequirements for the transaction. If the Responding Gateway supports the Deferred Response
Option, the Cross Gateway Patient Discovery Response Message will be sent as a new request as
follows:•

The Responding Gateway shall direct the response message to the address specified in
the respondTo element in the transmission wrapper.

•

The WS-Addressing RelatesTo element of the response message shall be populated withthe message identifier from the WS-Addressing MessageID element of the request
message•

The WS-Addressing Action value shall be urn:hl7org:v3:PRPA_IN201306UV02:Deferred:CrossGatewayPatientDiscovery•

Correlation with the request message is also supplied through the queryID element fromthe request message which shall be the same as the queryID element of the Response
message.

9385

9390

Cross Gateway Patient Discovery Response Application Acknowledgement Message
The Initiating Gateway that supports the Deferred Response Option shall respond with an HL7
V3 application acknowledgement message (MCCI_IN000002UV01). The WS-Addressing
Action value shall be urn:hl7-org:v3:MCCI_IN000002UV01.
9395__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

366

Copyright © 2017 IHE International, Inc.

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

3.56 Reserved for Patient Location Query [ITI-56]
3.57 Reserved for Update Document Set [ITI-57]
3.58 Reserved for Provider Information Query [ITI-58]
9400

3.59 Reserved for Provider Information Feed [ITI-59]
3.60 Retrieve Multiple Value Sets [ITI-60]
This section corresponds to transaction ITI-60 of the IHE IT Infrastructure Technical
Framework. The Value Set Consumer and Value Set Repository Actors use transaction ITI-60.
3.60.1 Scope

9405

This transaction is used by the Value Set Consumer to retrieve Value Sets from the Value Set
Repository.
3.60.2 Use case roles

Value Set
Consumer

Value Set Repository

Retrieve Multiple
Value Sets

9410

Figure 3.60.2-1: Use Case Roles

Actors:Actor: Value Set Consumer
Role: Requests all Value Sets that match request parameters
Actor: Value Set Repository9415

Role: Provides matching Value Sets and associated metadata
3.60.3 Referenced Standards
The referenced standards are:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

367

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.60.3-1: Referenced Standards

9420

Appendix V

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

HL7 v3 Data TypeXML ITSHL7 Version 3 Standard: XML Implementation Technology Specifications – Data Types, R1

HTTP 1.1

IETF RFC2616: Hypertext Transfer Protocol – HTTP 1.1

POSIX 1003.2

IEEE Std 1003.2 IEEE Standard for Information Technology — Portable Operating System
Interface (POSIX®) — Part 2: Shell and Utilities — Amendment 1: Batch Environment Description

3.60.4 Interaction Diagram
Value Set
Repository

Value Set
Consumer
Retrieve Multiple Value Sets
RequestRetrieve Multiple Value Sets
Response

Figure 3.60.4-1: Interaction Diagram

3.60.4.1 Retrieve Multiple Value Sets Request
9425

9430

3.60.4.1.1 Trigger Events
The Value Set Consumer wants to retrieve value sets and has one or more element values to bematched in the metadata that describes value sets. This could be from pre-configuration or user
input. The value sets that match these element values are needed for processing by the Value Set
Consumer. The Value Set Consumer sends a Retrieve Multiple Value Sets Request to the Value
Set Repository. Table 3.60.4.1.1-1 summarizes the metadata elements. See the schema for
precise encoding details.
Table 3.60.4.1.1-1: Metadata Summary
Metadata Element

Description

Mandatory
withinMetadata
returned

Usable as
Selection
Criterion

idThis is the unique identifier of the value set

MandatoryY

displayName

This is the name of the value set

MandatoryY__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

368

Copyright © 2017 IHE International, Inc.

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

Description

Mandatory
withinMetadata
returned

Usable as
Selection
Criterion

SourceThis is the source of the value set,
identifying the originator or publisher of theinformation

MandatoryY

PurposeBrief description about the general purposeof the value set

Optional

Y

Definition

A text definition describing how concepts inthe value set were selected

Optional

Y

Source URI

Most sources also have a URL or document
URI that provides further details regarding
the value set.

Optional

N

VersionA string identifying the specific version of
the value set.

MandatoryN

StatusActive, Inactive, local extensions

MandatoryN

Type

This describes the type of the value set. It
shall be:•Intensional,•
Extensional, or•Expanded
Note: This is the type of the value set in therepository. The ConceptList that will also be
returned is the current expansion of thevalue set.

MandatoryN

Binding

Shall be “Static” or “Dynamic”

Optional

N

Effective Date

The date when the value set is expected tobe effective

Optional

Y

Expiration Date

The date when the value set is no longer
expected to be used

OptionalY

Creation Date

The date of creation of the value set

Optional

Y

Revision Date

The date of revision of the value set

OptionalYGroup

The identifiers and keywords of the groups
that include this value set. A group may also
have an OID assigned.

OptionalY

3.60.4.1.2 Message Semantics
9435

The Retrieve Multiple Value Sets Request shall specify retrieval selection parameters as shownin the Table 3.60.4.1.2-1. It requests retrieval of all concept lists that have metadata matching theparameters used. At least one request parameter shall be provided.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

369

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.60.4.1.2-1: The Request Parameters in the RetrieveMultipleValueSets Request
Parameter

9440

Parameter
FormatMetadata
Element

Match
Type

Match
Rules

Note

id

OID

id

OID

equals

DisplayNameContains

string

Name

Regex

regex

POSIX rules

SourceContains

stringSource

Regex

regex

POSIX rules

PurposeContains

stringPurpose

Regex

regex

POSIX rules

DefinitionContains

stringDefinition

Regex

regex

POSIX rules

GroupContains

string

Group

Regex

regex

POSIX rules

GroupOID

OID

Group

OID

equalsEquality match for
OID attribute of aGroup element

EffectiveDateBefore

http-date

EffectiveDate

date

Before or
equal

Date comparison to
the day

EffectiveDateAfter

http-date

EffectiveDate

date

Equal or after

Date comparison to
the day

ExpirationDateBefore

http-date

ExpirationDate

date

Before or
equal

Date comparison to
the day

ExpirationDateAfter

http-date

ExpirationDate

date

Equal or after

Date comparison to
the day

CreationDateBefore

http-date

CreationDate

date

Before or
equal

Date comparison to
the day

CreationDateAfter

http-date

CreationDate

date

Equal or after

Date comparison to
the day

RevisionDateBefore

http-date

RevisionDate

date

Before or
equal

Date comparison to
the day

RevisionDateAfter

http-date

RevisionDate

date

Equal or after

Date comparison to
the dayFormatString

n/a

n/a

n/a

This specifies theformat for the
returned
information. Shall be“CE-List” if present.

3.60.4.1.3 Expected Actions
The Value Set Repository shall perform matching in accordance with the rules in Table
3.60.4.1.2-1.
•

Regex matches shall compare the contents of the referenced metadata field with theregex using the POSIX matching rules. If the regex matches the field, the value set
matches.

•

OID matching compares only for equal OIDs, ignoring leading zeroes.

•

Date comparisons convert the argument into a date, and compare it with the dates in
the metadata using a date comparison. Equality means the same day.

9445

Any value set that matches all of the request parameters shall be included in the response.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

370

Copyright © 2017 IHE International, Inc.

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

Note:

9455

Multiple queries will sometimes be needed. Rather than specify a complex query mechanism, the Retrieve
Multiple Value Sets request expects the client or user to locally eliminate any extra value sets and makeadditional queries. Value sets are relatively small and compress very well, so these extras are not a significant
communications burden. Performing the final steps of selecting the value sets based on having the full metadata
present locally allows a much richer and potentially interactive selection process. It also allows a simpler andmore robust server.

3.60.4.2 Retrieve Multiple Value Sets Response
3.60.4.2.1 Trigger Events
This message will be triggered by completion of matching for a Retrieve Multiple Value Sets
Request Message.
9460

3.60.4.2.2 Message Semantics

9465

The response shall be a Retrieve Multiple Value Sets Response as specified in the XML schema
defining RetrieveMultipleValueSetsResponse which can be accessed on the IHE FTP site, see
ITI TF-2x: Appendix W. The RetrieveMultipleValueSetsResponse element shall have one
DescribedValueSet element for each matching value set found. If no matching elements arefound, it shall be empty.
Each DescribedValueSet element contains:

9470

9475

9480

•

An id attribute, a mandatory OID, the OID for this value set•

A displayName attribute, a mandatory string, the name of this value set•

Source, an optional string, the source organization for this value set•

SourceURI, an optional URI, a URI providing more description of this value set,•

Purpose, an optional string, a description of the intended use of this value set•

Definition, an optional string, a definition of the value set provided by the source•

A version attribute, a mandatory string, a version in the format used by the source,•

Status, an optional string, the status at time of retrieval (e.g., Active or Inactive)•

Type, a mandatory string that indicates whether this is an intensional, extensional, or
expanded value set.

•

Binding, an optional string, either static or dynamic.

•

EffectiveDate, an optional XML-date, the initial effective date for this value set•

ExpirationDate, an optional XML-date, the intended expiration date for this value set•

CreationDate, an optional XML-date, the creation date of this value set,•

RevisionDate, an optional XML-date, the revision date of this value set,•

Zero or more Group elements, where each Group element has__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

371

Copyright © 2017 IHE International, Inc.

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

9485

•
9490

9495

•

an optional id attribute containing the OID for the group.

•

An optional displayName attribute, containing the name for the group,•

An optional sourceOrganization attribute, containing the name of the organizationthat defined the group.

•

Zero or more Keyword elements that contain keywords associated with the group.

One ConceptList, that contains•

One or more Concept, encoded using the HL7 CE datatype. These are the codes thatare members of the expanded form of the value set.

•

With an optional attribute xml:lang to indicate the language for the displayname forthese concepts.

The ConceptList element and structure is the same in both the ITI-48 and ITI-60 transactions.
The Identifier OID in the ITI-60 response is the OID used in the ITI-48 transaction when thevalue set is an expanded value set. It will not match in other cases.
A sample RetrieveMultipleValueSetsResponse is shown below:

9500

9505

9510

9515

9520

9525

9530

<?xml version="1.0" encoding="UTF-8"?><RetrieveMultipleValueSetsResponse xmlns="urn:ihe:iti:svs:2008"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ihe:iti:svs:2008:SVS.xsd"><DescribedValueSet id="1.2.3" displayName="placeholder" version="version1"><ConceptList xml:lang="en-US"><Concept code="code1" codeSystem="2.3.4"
codeSystemName="codeSystemName1" codeSystemVersion="codeSystemVersion1"
displayName="displayName1"></Concept><Concept code="code7" codeSystem="2.3.4"
codeSystemName="codeSystemName1" codeSystemVersion="codeSystemVersion1"
displayName="displayName7"></Concept></ConceptList><Source>Codingsource</Source><SourceURI>http://www.codingsource.com/placeholder</SourceURI><Purpose>Purpose0</Purpose><Definition>Definition0</Definition><Type>Expanded</Type><Binding>Static</Binding><Status>Status0</Status><EffectiveDate>2006-05-04</EffectiveDate><ExpirationDate>2011-09-04</ExpirationDate><CreationDate>2006-05-04</CreationDate><RevisionDate>2006-05-04</RevisionDate><Group id="2.4.5" sourceOrganization="sourceOrganization1"
displayName="displayName15"><Keyword>Keyword0</Keyword><Keyword>Keyword1</Keyword></Group><Group id="2.4.54" sourceOrganization="sourceOrganization3"
displayName="displayName17">__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

372

Copyright © 2017 IHE International, Inc.

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

9535<Keyword>Keyword2</Keyword><Keyword>Keyword3</Keyword></Group></DescribedValueSet></RetrieveMultipleValueSetsResponse>

3.60.5 Protocol Requirements
The protocol for the Retrieve Value Set transaction describes two bindings. The first is based on
SOAP 1.2, and the second is an HTTP binding. The relevant XML namespace definitions can beseen in Table 3.48.5-1 WSDL Namespace Definitions.
9540

Table 3.60.5-1: WSDL Namespace Definitions
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:svs:2008

3.60.5.1 SOAP Binding

9545

Value Set Consumers which support the SOAP Binding Option shall follow the rules for Web
Services transactions outlined in ITI TF-2x: Appendix V. These are the requirements for the
RetrieveMultipleValueSets transaction presented in the order in which they would appear in the
WSDL definition:
The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:iti:svs:2008", schema="SVS.xsd"
The /definitions/message/part/@element attribute of the Retrieve Value Set
Request message shall be defined as “ihe:RetrieveMultipleValueSetsRequest”

9550

The /definitions/message/part/@element attribute of the Retrieve Value Set
Response message shall be defined as “ihe:RetrieveMultipleValueSetsResponse”
The /definitions/portType/operation/input/@wsaw:Action attribute for the
Retrieve Multiple Value Sets Request message shall be defined as“urn:ihe:iti:2010:RetrieveMultipleValueSets”

9555

9560

The /definitions/portType/operation/output/@wsaw:Action attribute for the
Retrieve Value Set Response message shall be defined as“urn:ihe:iti:2010:RetrieveMultipleValueSetsResponse”
The/definitions/binding/operation/soap12:operation/@soapActionRequi
red attribute shall be defined as “false”

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.
__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

373

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Within the request message payload the<ihe:RetrieveMultipleValueSetsRequest/> element is defined as:
9565•

A optional /ihe:RetrieveMultipleValueSetsRequest@id element that
contains the ID of the requested Value Set within the Value Set Repository. The Value
Set ID shall be formatted as an ISO OID.

•

An optional/ihe:RetrieveMultipleValueSetsRequest@DisplayNameContains
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@SourceContains element•

An optional/ihe:RetrieveMultipleValueSetsRequest@PurposeContains element•

An optional/ihe:RetrieveMultipleValueSetsRequest@DefinitionContains
element•

An optional /ihe:RetrieveMultipleValueSetsRequest@GroupContains
element•

An optional /ihe:RetrieveMultipleValueSetsRequest@GroupOID
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@EffectiveDateBefore
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@EffectiveDateAfterelement•

An optional/ihe:RetrieveMultipleValueSetsRequest@ExpirationDateBefore
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@ExpirationDateAfterelement•

An optional/ihe:RetrieveMultipleValueSetsRequest@CreationDateBefore
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@CreationDateAfterelement

9570

9575

9580

9585

9590

9595

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

374

Copyright © 2017 IHE International, Inc.

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

9605

•

An optional/ihe:RetrieveMultipleValueSetsRequest@RevisionDateBefore
element•

An optional/ihe:RetrieveMultipleValueSetsRequest@RevisionDateAfterelement

Value Set Repositories shall include within the response message payload for the SOAP Binding
Option the <ihe:RetrieveMultipleValueSetsResponse/> element which is
described above in Section 3.60.4.2.2.
3.60.5.2 HTTP Binding
9610

9615

Value Set Consumers which support the HTTP Binding Option shall use the GET method as
defined in IETF RFC2616 for the Retrieve Value Set Request. Each parameter to be used forselection shall be encoded as an HTTP Get parameter.
A sample URL for the HTTP binding for a query to retrieve all value sets for a reporting
purpose, with either “stroke” or “JCAHO” in the value set name looks as follows:

https://example.com/RetrieveMultipleValueSets?DisplayNameContains=”stroke|JCAHO”&PurposeContains=”report”

Value Set Repositories shall format the response to the HTTP GET operation as an HTTP
response message as defined in IETF RFC2616.
9620

The Content-Type field of the HTTP header shall be “text/xml” (see Section 14.4 of IETF
RFC2616).
The content of the HTTP response message shall be an XML encoded
RetrieveMultipleValueSetsResponse, as described in Section 3.60.4.2.2.

9625

The Value Set Repository shall return an error code in case there are invalid request parameters.
It shall return an HTTP status code of 404, with an HTTP Warning header containing warn-codeof 111, and warn-text of “INV: Invalid search parameters”. See Sections 10.4.5 and 14.46 of
IETF RFC2616 for more information. A search with valid request parameters that finds nomatching value sets is not an error. It will return an empty QueryRetrievedValueSets
3.60.6 Security Requirements

9630

The value sets do not contain personal information. In some cases, the value sets are created bystandards organizations with the intention that they be or publicly shared. In other cases, there
may be licensing or other proprietary restrictions on their disclosure. These licenses or
restrictions are at the organizational level, not at the level of individual users. This greatly
reduces the security needs and eliminates privacy concerns.
For further security considerations please consult ITI TF-1: Appendix G.

9635

Audit trails shall be configurable to record access to a selected list of Value Sets. In most cases,
there is no need to audit the value set request activity, but there may be some exceptional cases__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

375

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
where auditing will be needed. See Section 3.48.6.1 for audit record recommendations in thosecases.
9640

This profile does not attempt to establish rules for managing security on proprietary value setswith licensing or access restrictions.

3.61 Register On-Demand Document Entry [ITI-61]
This section corresponds to Transaction [ITI-61] of the IHE ITI Technical Framework.
Transaction [ITI-61] is used by the On-Demand Document Source and Document Registry
Actors.
9645

3.61.1 Scope
The Register On-Demand Document Entry transaction passes a Document Submission Request(see ITI TF-3: 4.2.1.5) from an On-Demand Document Source to a Document Registry Actor.
The Document Submission Request for this transaction contains metadata describing one ormore On-Demand DocumentEntry objects and, optionally, Folders and Associations.

9650

3.61.2 Use Case Roles
On-Demand
Document
SourceDocument
Registry

Register On-Demand
Document Entry

Actor: On-Demand Document Source
Role: A Provider of On-Demand Documents that registers a patient-specific on-demand
document to the Document Registry.
9655

Actor: Document Registry
Role: A document indexing system that receives and stores metadata about available ondemand documents.
3.61.3 Referenced Standard
ebRIM

OASIS/ebXML Registry Information Model v3.0
This model defines the types of metadata and content that can be stored in an ebXML Registry, a basis forand subset of XDS metadata.

ebRS

OASIS/ebXML Registry Services Specifications v3.0
This defines the services and protocols for an ebXML Registry, used as the basis for the XDS Registry

HL7V2

HL7 Version 2.5__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

376

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
See ITI TF 2x: Appendix V for other referenced standards for SOAP encoding.
See ITI TF 3: 4.2 for other referenced standards for metadata element encoding.

9660

3.61.4 Interaction Diagram
On-Demand
Document
SourceDocument
Registry
Register On-Demand
Document Entry Request
Register On-Demand
Document Entry Response

3.61.4.1 Register On-Demand Document Entry Request

9665

The Register On-Demand Document Entry Request message is used to register metadata that canbe used to request an on-demand document. An on-demand document is one which collects thelatest, most recent available information at the time of retrieval. For more information about theOn-Demand DocumentEntry specified in the request message see ITI TF-3: 4.1.1.
The On-Demand Document Source sends metadata to the Document Registry. The metadata
contains one or more patient-specific On-Demand DocumentEntry objects and, optionally,
Folders and Associations.

9670

3.61.4.1.1 Trigger Events
The Register On-Demand Document Entry Request message is triggered when the On-Demand
Document Source chooses to make available an on-demand document for a particular patient.
3.61.4.1.2 Message Semantics

9675

9680

The Register On-Demand Document Entry Request message shall use SOAP 1.2 and Simple
SOAP (See ITI TF-2x: V.8.1). Implementors of this transaction shall comply with all
requirements described in ITI TF-2x: Appendix V: Web Services for IHE Transactions.
The Register On-Demand Document Entry Request message shall contain a Submission Request,
as defined in ITI TF-3: 4.1.4 except that it shall include at least one On-Demand DocumentEntry.
All DocumentEntry objects in this Submission Request shall be On-Demand DocumentEntry
objects and, therefore, will not be Stable DocumentEntry objects.
This transaction imposes no restrictions on the use of Folders or Associations. In particular,
workflows which replace a Stable DocumentEntry with an On-Demand DocumentEntry, add an__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

377

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
On-Demand DocumentEntry to a Folder, or replace an On-Demand DocumentEntry with a new
On-Demand DocumentEntry are all valid.
9685

9690

Note: Because a Stable DocumentEntry cannot be submitted in this transaction, Associations which require thesimultaneous submission of a Stable DocumentEntry cannot be included in this transaction. For example,
workflows which replace an On-Demand DocumentEntry with a Stable DocumentEntry are not allowed.

See ITI TF-3: 4.2.1.4 for a description of the ebRS/ebRIM representation of a Submission
Request. The metadata requirements for this Submission Request are defined in ITI TF-3: 4.3.1.
In its use of metadata, the On-Demand DocumentEntry has the same requirements as a Stable
DocumentEntry, except for the following:•creationTime – Not Applicable; shall not be specified in a Register On-Demand
Document Entry Request.

•

hash – Not Applicable; shall not be specified in a Register On-Demand Document Entry
Request.

•legalAuthenticator – Recommend this not be specified as having no clear meaning in thecontext of an On-Demand DocumentEntry.

•

repositoryUniqueId – The globally unique immutable identifier of the On-Demand
Document Source which provides an On-Demand Document corresponding to this OnDemand DocumentEntry. This unique identifier for the On-Demand Document Source
may be used to identify and connect to the specific On-Demand Document Source wherea current instance of the on-demand document may be retrieved.

•

size – Not Applicable; shall not be specified in a Register On-Demand Document Entry
Request.

9705•

serviceStartTime and serviceStopTime - For On-Demand DocumentEntry objects this
attribute represents the earliest time(serviceStartTime)/most recenttime(serviceStopTime) health service was rendered for which data is available ondemand. For some On-Demand Document Sources this attribute is not applicable and sowould not be present.

9710

•

uniqueId – The globally unique identifier assigned by the On-Demand Document Source
to this On-Demand DocumentEntry. It is used in the Retrieve Document Set [ITI-43]
transaction to identify the correct On-Demand Document to access. The use of uniqueIdin On-Demand DocumentEntry objects is different from Stable DocumentEntry objects
as this value will never represent an actual document. See ITI TF-3: 4.1.1 for more details
regarding use of uniqueId by On-Demand DocumentEntry objects.

9695

9700

9715

A full example of document metadata submission is available online on the IHE FTP site, see ITI
TF-2x: Appendix W.
XML namespace prefixes used in text and in examples below are for informative purposes only
and are documented in ITI TF-2x: Appendix V, Table 2.4-1.
9720

The requirements for the request message are:__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

378

Copyright © 2017 IHE International, Inc.

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

the <wsa:Action> SOAP element shall contain the value
urn:ihe:iti:2010:RegisterOnDemandDocumentEntry•the <soap12:Body> shall contain one <lcm:SubmitObjectsRequest> element representing
the Submission Request (see ITI TF-3: 4.2.1.4 for details of expressing a Submission
Request).

9725

A full XML Schema Document for the XDS types is available online on the IHE FTP site, see
ITI TF-2x: Appendix W.
Below is an example of the SOAP Body for a Register On-Demand Document Entry Request
message:9730<soap12:Body><lcm:SubmitObjectsRequest><!-- Submission Request contents – See ITI TF-3: 4.2.1.4 --><rim:RegistryObjectList>

9735<!-- Registry Metadata goes here --></rim:RegistryObjectList></lcm:SubmitObjectsRequest></soap12:Body>

9740

If the On-Demand Document Source supports the Asynchronous Web Services Exchange
Option, it shall be able to generate an Asynchronous Web Services request as defined in ITI TF2x: Appendix V.5.
9745

If the On-Demand Document Source supports the Basic Patient Privacy Enforcement Option, it
shall comply with the requirements as described in ITI TF-1: 10.2.9.
3.61.4.1.3 Expected Actions
Upon receipt of a Register On-Demand Document Entry Request message, the Document
Registry shall:

9750

•

Perform metadata validations•

Store all IHE-defined metadata attributes received so that they are available to return in
responses to future queries.

•

Return a response message giving the status of the operation.

If the Document Registry rejects the metadata, it shall:
9755

9760

•

Return an error including at least one error message in the response. For a complete listof applicable codes, refer to ITI TF-3: Table 4.2.4.1-2.

•

Roll back any changes made.

The Document Registry shall comply with all of the requirements specified in Sections
3.42.4.1.3.1 through 3.42.4.1.3.7 except for Section 3.42.4.1.3.3.1 which describes the validationof DocumentEntry.uniqueId. In terms of this metadata attribute, the Document Registry shallreject the message and return an error if the uniqueId attribute matches the uniqueId attribute of a__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

379

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Stable DocumentEntry currently within the Document Registry. If the uniqueId attribute matches
the uniqueId attribute of an On-Demand DocumentEntry currently within the Document Registry
the Document Registry shall accept the transaction and thereby create a new On-Demand
DocumentEntry with the same uniqueId.
9765

3.61.4.2 Register On-Demand Document Entry Response
The Document Registry sends the result of processing the On-Demand DocumentEntry metadata
to the On-Demand Document Source.
3.61.4.2.1 Trigger Events

9770

The Document Registry finishes processing a Register On-Demand Document Entry Request
message and shall return a Register On-Demand Document Entry Response message.
3.61.4.2.2 Message Semantics
The Register On-Demand Document Entry Response message shall use SOAP 1.2 and Simple
SOAP (See ITI TF-2x: V.8.1). Implementors of this transaction shall comply with all
requirements described in: ITI TF-2x: Appendix V: Web Services for IHE Transactions.

9775

The Register On-Demand Document Entry Response message shall carry the status of therequested operation. The response message may carry warning messages. If the requested
operation fails, the response message shall carry at least one error message. The conditions offailure and possible warning and error messages are given in the ebRS standard and detailed in
ITI TF-3: 4.2.4 Error Reporting. This transaction does not support a partial success response.

9780

If creationTime, hash or size metadata attributes are received in a Register On-Demand
Document Entry Request message, the Document Registry shall return an
XDSRegistryMetadataError.
XML namespace prefixes used in text and in examples below are for informational purposes
only and are documented in ITI TF-2x: Appendix V, Table 2.4-1.

9785

The requirements for the response message are:•the <wsa:Action> soap header shall contain the value
urn:ihe:iti:2010:RegisterOnDemandDocumentResponse•the <soap12:Body> soap element shall contain one <rs:RegistryResponse> element

See ITI TF-3: 4.2.4 for examples of response messages.
9790

If the Document Registry supports the Asynchronous Web Services Exchange Option and it
receives an Asynchronous Web Services request, it shall respond as defined in ITI TF-2x:
Appendix V.5.

__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

380

Copyright © 2017 IHE International, Inc.

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

The On-Demand Document Source now knows that the transaction succeeded/failed and cancontinue. The metadata added to the Document Registry as a result of this transaction is now
available for discovery.
3.61.7 Security Considerations
Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).

9800

3.61.7.1 Audit Record Considerations
The Register On-Demand Document Entry transaction is PHI-Export event, as defined in ITI TF2a: Table 3.20.4.1.1.1-1 with the following exceptions.
3.61.7.1.1 On-Demand 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-61”, “IHE Transactions”, “Register On-Demand Document
Entry”)

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

Source (On-Demand Document Source) (1)
Human Requestor (0..1)
Destination (Document Registry) (1)Audit Source (On-Demand Document Source) (1)Patient (1)SubmissionSet (1)Where:
SourceAuditMessage/
ActiveParticipant

9805
Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

381

Copyright © 2017 IHE International, Inc.

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

Destination

AuditMessage/
ActiveParticipant

Audit Source

AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

RoleIDCodeU

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

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

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

NetworkAccessPointID

M

The machine name or IP address.

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format..

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

9810
Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)

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

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

382

Copyright © 2017 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.61.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-61”, “IHE Transactions”, “Register On-Demand Document
Entry”)

UserIDM

If Asynchronous Web Services Exchange is being used, the content of
the <wsa:ReplyTo/> element. Otherwise, not specialized.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorU

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

The machine name or IP address.

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.

NetworkAccessPointTypeCodeU

not specialized

NetworkAccessPointIDU

not specialized

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.

Source (On-Demand Document Source) (1)
Human Requestor (0..1)
Destination (Document Registry ) (1)Audit Source (Document Registry) (1)Patient (1)SubmissionSet (1)Where:
SourceAuditMessage/
ActiveParticipant

9815
Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

383

Copyright © 2017 IHE International, Inc.

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

AuditMessage/
AuditSourceIdentificati
onPatient(AuditMessage/
ParticipantObjectIde
ntification)

AuditSourceIDU

not specialized

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCodeM

not specialized

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

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

9820
Submission
Set(AuditMessage/
ParticipantObjectIde
ntification)

3.62 Reserved for Remove Metadata [ITI-62]
3.63 Reserved for Cross Gateway Fetch [ITI-63]
3.64 Reserved for Notify XAP-PID Link Change [ITI-64]__________________________________________________________________________
Rev. 14.0 Final Text – 2017-07-21

384

Copyright © 2017 IHE International, Inc.