情報共有型地域連携基盤基本部仕様
Core Specification of Infrastructure for Regional Health Information Exchange and Sharing(第1.0版、2012年10月18日)
一般社団法人 日本IHE協会
本書は、情報共有型地域連携基盤基本部仕様を定める。本基本部仕様は、IHEテクニカルフレーム
ワーク（IHE IT Infrastructure Technical Framework及びIHE Radiology Technical Framework）[1][2]が定める統合プロファイルの内、下記[3]のとおり関連する部分を抜粋してまとめたものである。
IHEテクニカルフレームワークの全体像が分かるように、IntroductionやProfilesなどの記述についてはそのまま残した。
また、本書の出典元である上述のテクニカルフレームワークの記述部分が分かるように章、節などの番号はそのままの形で利用している。
[1] IHE IT Infrastructure Technical Framework
Technical Framework - Revision 8.0 (Published 2011-08-19)

Copyright © 2011: IHE International, Inc.
Final Text

http://www.ihe.net/Technical_Framework/archive.cfm#IT[2] IHE Radiology Documents
Technical Framework - Revision 11.0 (Published 2012-07-24)

Copyright © 2012: IHE International, Inc.
Final Text

http://www.ihe.net/technical_framework/[3] 本基本部仕様の該当部分
5. Patient Identifier Cross-referencing (PIX)
3.8 Patient Identity Feed [ITI-8]
3.9 PIX Query [ITI-9]
3.10 PIX Update Notification [ITI-10]
23. Patient Identifier Cross-Reference HL7 V3 (PIXV3)
Copyright © 2012:.一般社団法人 日本IHE協会

13.44 Patient Identity Feed HL7 V3 [ITI-44]
3.45 PIXV3 Query [ITI-45]
3.46 PIXV3 Update Notification [ITI-46]
8. Patient demographics Query(PDQ)

3.21 Patient Demographics Query [ITI-21]
3.22 Patient Demographics and Visit Query [ITI-22]
24. Patient Demographic Query HL7 V3 (PDQV3)
3.47 Patient Demographics Query HL7 V3 [ITI-47]
10 Cross-Enterprise Document Sharing (XDS.b)
3.18 Registry Stored Query [ITI-18]
3.41 Provide and Register Document Set-b [ITI-41]
3.42 Register Document Set-b [ITI-42]
3.43 Retrieve Document Set [ITI-43]
18 Cross-Enterprise Document Sharing for Imaging (XDS-I.b) Integration Profile
4.16 Retrieve Images [RAD-16]
4.17 Retrieve Presentation States [RAD-17]
4.27 Retrieve Reports [RAD-27]
4.31 Retrieve Key Image Note [RAD-31]
4.45 Retrieve Evidence Documents [RAD-45]
4.55 WADO Retrieve [RAD-55]
4.68 Provide and Register Imaging Document Set – MTOM/XOP [RAD-68]
4.69 Retrieve Imaging Document Set [RAD-69]
3.20 Record Audit Event
Volume 2x (ITI TF-2x): Appendices
Appendix K: XDS Security Environment
Appendix V: Web Services for IHE Transactions
Appendix W: Implementation Material

Copyright © 2012:.一般社団法人 日本IHE協会

2

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

5 Patient Identifier Cross-referencing (PIX)1160

The Patient Identifier Cross-referencing Integration Profile (PIX) is targeted at healthcare
enterprises of a broad range of sizes (hospital, a clinic, a physician office, etc.). It supports the
cross-referencing of patient identifiers from multiple Patient Identifier Domains via the followinginteractions:• The transmission of patient identity information from an identity source to the Patient
Identifier Cross-reference Manager.
• The ability to access the list(s) of cross-referenced patient identifiers either via a query/
response or via update notification.

1165

By specifying the above transactions among specific actors, this integration profile does not define
any specific enterprise policies or cross-referencing algorithms. By encapsulating these behaviors ina single actor, this integration profile provides the necessary interoperability while maintaining theflexibility to be used with any cross-referencing policy and algorithm as deemed adequate by theenterprise.

1155

The following diagram shows the intended scope of this profile (as described above).
Patient Identity Feed
& Patient Identity
References

Patient
Identifier
Domain C

Patient
Identity
Feed

Patient Identity
SourceInternal
Domaintransactions

Patient Identifier
Cross-reference Domain
Patient Identifier
Cross-referenceManager
Patient
Identity
Feed

Patient
Identity
Cross
References

Patient Identity
SourceInternal
Domaintransactions

Patient Identifier
Cross-reference
ConsumerOther
IHE Actor

Patient Identifier
Cross-reference
ConsumerOther
IHE Actor

Patient Identifier
Domain A

Patient
Identity
Cross References

Patient Identifier
Domain B

Figure 5-1 Process Flow with Patient Identifier Cross-referencing

The diagram illustrates two types of Identifier Domains: a Patient Identifier Domain and a Patient
Identifier Cross-reference Domain.
1170

A Patient Identifier Domain is defined as a single system or a set of interconnected systems that all
share a common identification scheme (an identifier and an assignment process to a patient) and________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

41

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1175

1180

1185

1190

1195

1200

1205

1210

________________________________________________________________________________
issuing authority for patient identifiers. Additionally, a Patient Identifier Domain has the following
properties:• A set of policies that describe how identities will be defined and managed according to
the specific requirements of the domain.
• An administration authority for administering identity related policies within the domain.
• A single system, known as a patient identity source system, that assigns a unique
identifier to each instance of a patient-related object as well as maintaining a collectionof identity traits.
• Ideally, only one identifier is uniquely associated with a single patient within a given
Patient Identifier Domain, though a single Patient Identity Source Actor may assign
multiple identifiers to the same patient and communicate this fact to the Patient Identifier
Cross-reference Manager. For a description of how the Patient Identifier Cross-referenceManager Actor responds to requests for a list of cross-referenced identifiers that include
these “duplicates” see ITI TF-2a: 3.9.4.2.2.6).
• An “Identifier Domain Identifier” (known as assigning authority) that is unique within a
Patient Identifier Cross-reference Domain.
• Other systems in the Patient Identifier Domain rely upon the identifiers assigned by thepatient identity source system of the domain to which they belong.
A Patient Identifier Cross-reference Domain consists of a set of Patient Identifier Domains known
and managed by a Patient Identifier Cross-reference Manager Actor. The Patient Identifier Crossreference Manager Actor is responsible for creating, maintaining and providing lists of identifiers
that are aliases of one another across different Patient Identifier Domains.
The Patient Identifier Cross-reference Domain embodies the following assumptions aboutagreement within the group of individual Identifier Domains:• They have agreed to a set of policies that describe how patient identities will be crossreferenced across participating domains;• They have agreed to a set of processes for administering these policies;• They have agreed to an administration authority for managing these processes andpolicies.
All these assumptions are critical to the successful implementation of this profile. This integration
profile imposes minimal constraints on the participating Patient Identifier Domains and centralizes
most of the operational constraints for the overall Patient Identification Cross-reference Domain in
the Patient Identifier Cross-reference Manager Actor. If the individual Identifier Domains cannot
agree to the items outlined above, implementation of this profile may not provide the expected
results.
The Patient Identifier Cross-reference Manager Actor is not responsible for improving the quality ofidentification information provided to it by the Identity Source Actors. It is assumed that the
Identity Source actors are responsible for providing high quality data to the Patient Identifier Crossreference Manager. For example, the Patient Identifier Cross-reference Manager Actor is NOT
responsible to provide a single reference for patient demographics. The intent is to leave theresponsibility for the quality and management of its patient demographics information and theintegrity of the identifiers it uses within each Patient Identity Domain (Source actors). When________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

42

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1215

1220

________________________________________________________________________________
receiving reports and displays from multiple PIX domains, it is inevitable that some of those reports
and displays will have inconsistent names.
The Patient Identifier Cross-reference Consumer may use either a query for sets of cross-reference
patient identifiers or use both a notification about cross-reference changes and a query transaction.
In the case of using a notification, the Patient Identifier Cross-reference Consumer may also use the
PIX Query Transaction to address situations where the Patient Identifier Cross-reference Consumer
may be out of synch with the Patient Identifier Cross-reference Manager. This Integration Profile
does not specify the consumer policies in using the PIX Query Transaction (ITI TF-2a: 3.9).
For a discussion of the relationship between this Integration Profile and an enterprise master patient
index (eMPI) see ITI TF-1: 5.4.

5.1 Actors/ Transactions
1225

Figure 5.1-1 shows the actors directly involved in the Patient Identifier Cross-referencing
Integration Profile and the relevant transactions between them. Other actors that may be indirectly
involved due to their participation in other related profiles are not shown.

Patient Identity Source

Patient Identity
Management
HL7 V2.5 [ITI-30]↓

Patient Identifier
Cross-reference
Consumer

Patient Identity Feed
[ITI-8]↓↓ PIX Query [ITI-9]↑ PIX Update Notification [ITI-10]

Patient Identifier Crossreference Manager

Figure 5.1-1 Patient Identifier Cross-referencing Actor Diagram

1230

Table 5.1-1 lists the transactions for each actor directly involved in the Patient Identifier Crossreferencing Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete
list of options defined by this Integration Profile and that implementations may choose to support islisted in the ITI TF-1: 5.2.

1235
Table 5.1-1 Patient Identifier Cross-referencing Integration for MPI Profile - Actors andTransactions
ActorsPatient Identity Source

Patient Identifier Cross-reference Consumer
Patient Identifier Cross-reference Manager

Transactions

Optionality

SectionPatient Identity Feed [ITI-8]

R

ITI TF-2a: 3.8

Patient Identity Management [ITI30]

OITI TF-2b: 3.30

PIX Query [ITI-9]

R

ITI TF-2a: 3.9

PIX Update Notification [ITI-10]

O

ITI TF-2a: 3.10

Patient Identity Feed [ITI-8]

R

ITI TF-2a: 3.8________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

43

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
ActorsTransactions

Optionality

SectionPatient Identity Management [ITI30]

OITI TF-2b: 3.30

PIX Query [ITI-9]

R

ITI TF-2a: 3.9

PIX Update Notification [ITI-10]

R

ITI TF-2a: 3.10

5.2 Patient Identifier Cross-referencing Integration Profile Options
1240

Options that may be selected for this Integration Profile are listed in the Table 5.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified in notes.
Table 5.2-1 Patient Identifier Cross-referencing - Actors and Options
Actor

Options

Vol & Section

Patient Identity Source

Pediatric
Demographics

ITI TF-1: 5.2.1

Patient Identifier Cross-reference Manager

Pediatric
Demographics

ITI TF-1: 5.2.1

Patient Identifier Cross-reference Consumer

PIX Update Notification

ITI TF-2a: 3.10

5.2.1 Pediatric Demographics

1245

1250

The experience of immunization registries and other public health population databases has shownthat matching and linking patient records from different sources for the same individual person inenvironments with large proportions of pediatric records requires additional demographic data.
In particular, distinguishing records for children who are twins, triplets, etc. – that is, avoiding false
positive matches - may be difficult because much of the demographic data for the two individuals
matches. For instance, twin children may have identical last names, parents, addresses, and datesof birth; their first names may be very similar, possibly differing by only one letter. It can be very
difficult for a computer or even a human being to determine in this situation whether the slight firstname difference points to two distinct individuals or just a typographical error in one of the records.
Additional information is extremely helpful in making this determination.
Pediatric Demographics makes use of the following six additional demographic fields to aid record
matching in databases with many pediatric records.

1255
Field

Reason for inclusion

Value

Mother’s Maiden Name

Any information about the mother is
helpful in making a match

Helps create true positive matches

Patient Home
TelephoneA telecom helps match into the righthousehold

Helps create true positive matches

Patient Multiple Birth
Indicator

Indicates this person is a multiple twin, triplet, etc.

Helps avoid false positive matches ofmultiplesPatient Birth OrderDistinguishes among those multiples.

Helps avoid false positive matches ofmultiples________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

44

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Last Update Date/Time,
Last Update Facility

These fields, although not strictly
demographic, can effectively substitutewhen multiple birth indicator and birthorder are not collected. They indirectly
provide visit information. Provider
visits on the same day may likely
indicate two children brought to adoctor together.

Helps avoid false positive matches ofmultiplesPatient Identity Source actors which support the Pediatric Demographics option are required tosupport the Patient Identity Management [ITI-30] transaction and shall provide values, whenavailable, for the fields identified as Pediatric Demographics fields.
1260

1265

1270

1275

Patient Identifier Cross-reference Manager actors which support the Pediatric Demographics option
are required to support the Patient Identity Management [ITI-30] transaction, and if values for one
or more of the Pediatric Demographics fields are specified in the Patient Identity Management [ITI30], they shall be considered as part of the matching algorithm of the PIX Manager.
Pediatric Demographics are defined as all of the following:• Mother’s Maiden Name
• Patient Home Telephone• Patient Multiple Birth Indicator• Patient Birth Order• Last Update Date/Time• Last Update Facility
Pediatric Demographic is particularly focused on two data issues:• Locating a record where the data or the search criterion have differences, but both thedata record and the search criterion represent the same person, and• Avoiding improper linkage of very similar records that do not belong to the same person.
This problem is most often encountered in multiple birth situations where twins may be
given extremely similar names

5.3 Patient Identifier Cross-referencing Profile Process FlowsThe following sections describe use cases that this profile addresses.
5.3.1 Use Case: Multiple Identifier Domains within a Single Facility/ Enterprise
1280

1285

A clinician in the Intensive Care Unit at General Hospital is reviewing a patient chart on the
Intensive Care information system and wishes to review or monitor the patient’s glucose level,
which is included in a laboratory report stored in the hospital’s main laboratory system. The
Intensive Care system needs to map its own patient ID, which it generates internally, to the patient’s
medical record number (MRN), which is generated from the hospital’s main ADT system and isused as the patient identity by the lab system. In this case the Intensive Care system is essentially ina different identifier domain than the rest of the hospital since it has its own notion of patient
identity.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

45

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1290

1295

1300

1305

________________________________________________________________________________In this scenario, the hospital’s main ADT system (acting as a Patient Identity Source) would provide
a Patient Identity Feed (using the patient’s MRN as the identifier) to the Patient Identifier Crossreference Manager. Similarly, the Intensive Care system would also provide a Patient Identity Feedto the Patient Identifier Cross-reference Manager using the internally generated patient ID as thepatient identifier and providing its own unique identifier domain identifier.
Once the Patient Identifier Cross-reference Manager receives the Patient Identity Feed transactions,it performs its internal logic to determine which, if any, patient identifiers can be “linked together”
as being the same patient based on the corroborating information included in the Feed transactions it
has received. The cross-referencing process (algorithm, human decisions, etc.) is performed within
the Patient Identifier Cross-reference Manager and is outside the scope of IHE. (See ITI TF-2a:3.9.4.2.2.6 for a more complete description of the scope of the cross-referencing logic boundary).
The Intensive Care system wants to get lab information associated with a patient that the Intensive
Care system knows as patient ID = ‘MC-123’. It requests the lab report from the lab system using
its own patient ID (MC-123) including the domain identifier/ assigning authority. Upon receipt of
the request, the lab system determines that the request is for a patient outside of its own identifier
domain (ADT Domain). It requests a list of patient ID aliases corresponding to patient ID = ‘MC123’ (within the “Intensive Care domain”) from the Patient Identifier Cross-reference Manager.
Having linked this patient with a patient known by medical record number = ‘007’ in the ‘ADT
Domain’, the Patient Identifier Cross-reference Manger returns this list to the lab system so that it
may retrieve the lab report for the desired patient and return it to the Intensive Care system. Figure5.3-1 illustrates this process flow.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

46

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Patient Identity
Source (Intensive
Care domain)

Display (Intensive
Care domain)

Patient Identifier
Cross-referenceManager

Patient Identity
Source (ADTdomain)Patient Identifier Crossreference Consumer/Information Source (Labsystem - ADT domain)

Patient Identity Feed [ITI-8]
Apply Xref
logic

ADT feed within
Intensive Care ID
domainPatient Identity
Feed [ITI-8]
Apply Xref
logic

ADT feed
within ADT
ID domain

Retrieve Document for Display[ITI-12] - Request
PIX Query [ITI-9]

Retrieve Document for Display [ITI-12] - Response

Use
locally
known ID
to select
lab report

1310
Figure 5.3-1. Multiple ID Domains in a Single Facility Process Flow in PIX Profile
Note: Request and Response portions of the Retrieve Document for Display transaction are not part of this profile and included
for illustration purposes only.

5.3.2 Use Case: Multiple ID Domains Across Cooperating Enterprises
1315

1320

1325

1330

A healthcare enterprise is established by the consolidation of two hospitals, each having its own
separate patient registration process run by different hospital information systems. When a patient istreated in one hospital, the access to its electronic records managed by the other hospital isnecessary. The following use case illustrates this scenario.
Hospitals A and B have been consolidated and have a single Patient Identifier Cross-referenceManager that maintains the ID links between the two hospitals. Each hospital has a different HIS
that is responsible for registering patients, but they have consolidated their cardiology information
systems. The cardiology system has been configured with a Patient Identifier Cross-reference
Consumer to receive patient identity notifications when cross-referencing activity occurs.
A patient is registered and then has some diagnostic stress tests done at hospital A. The cardiology
information system queries the Patient Identifier Cross-reference Manager to get a list of possible
ID aliases for the patient to see if any past cardiology reports may be available. No patient ID
aliases are found. Sometime later the same patient goes to hospital B to have a second diagnostic
stress test done. The patient is registered via the HIS in hospital B which then sends that identity
information to the Patient Identifier Cross-reference Manager. The Patient Identifier Crossreference Manager determines this is in fact the same patient as was registered previously at________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

47

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1335________________________________________________________________________________
hospital A. The cardiology information system was previously configured with the Patient Identifier
Cross-reference Manager to receive notifications, thus a notification is sent to the cardiology system
to inform it of the patient identifier aliases. This notification is done to allow systems that are awareof multiple identifier domains to maintain synchronization with patient identifier changes that occur
in any of the identifier domains that they are aware of.
Figure 5.3-2 illustrates the process flow for this use case.
Patient Identity
Source (domain
A)

Patient Identifier
Cross-referenceManager

Patient Identifier Crossreference Consumer(cardiology info system
in domain A)

Patient Identity
Feed [ITI-8]
ADT feed within
ID domain

PIX Query [ITI-9]

Patient Identity
Source (domain B)

Apply Xref
logic

Patient Identity
Feed [ITI-8]

PIX Update
Notification[ITI-10]

Apply Xref logic anddetermine consumers
interested in
notifications

Logic toconsolidate
internal data oflinked patients

Figure 5.3-2 Multiple ID Domains Across Cooperating Enterprises Process Flow in PIX
Profile1340

Note: PIX Update Notifications are not sent for the first Patient Identity Feed for a patient, since no cross-referencing activity
occurred after this first Patient Identity Feed Transaction.
.

5.3.3 Pediatric Demographic Option Use Cases
The following sections describe use cases that the Pediatric Demographics option addresses.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

48

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles
1345

1350

________________________________________________________________________________
5.3.3.1 Use Case: High Quality Demographic Feed from a Birth Registry
A regional Immunization Information System (IIS) receives birth registry information about a pairof twins. These twins are named “Lalainne” and “Lalannie” Smith. All of the data elements in thereceived registration are populated, and they are all identical, except for the Given Name, the Birth
Order, and the Birth Certificate #. The IIS cross-referencing system can clearly identify this very
similar data as belonging to two separate individuals, because they are both flagged as having beenpart of a Multiple Birth, their Birth Order numbers are different, and their Birth Certificate #s aredifferent.
5.3.3.2 Use Case: Normal Demographic Feed from a Point of Care

1355

1360

A couple years later, the mother of these two twins, who has now divorced and remarried, takes
them to Pediatric Healthcare, where they get the immunizations appropriate for 2 year olds.
Pediatric Healthcare completes a registration for each of them, and submits the resulting data to the
IIS. This data has their new Family Name as “Gomez,” but the clerks had appropriately recorded
the Birth Order of each twin. Again, the IIS was able to distinguish the two registration records as
belonging to separate individuals, and it was able to match them up to their earlier records because
the mother’s Maiden Name was present in both the earlier records and the records submitted from
Pediatric Healthcare. Pediatric Healthcare was able to download the full immunization history ofeach twin.
5.3.3.3 Use Case: Minimal Demographic Feed from a Health Fair

1365

1370

1375

The Jackson County Health Department puts on an annual Health Fair in a shopping mall every
August, partly to screen school age children for the minimum shots required for admission to thefirst grade. Mrs. Gomez is now working to pay for her new apartment, but her sister-in-law takes
the children to the Health Fair where they are given shots based on the paper “yellow card” thesister-in-law brings with the two twins. Jackson County Health Department staff records thechildren’s names, and the shots they were given. This information is entered into the computer
back at the Clinic the next day, and submitted to the regional IIS.
At this point, even though both children’s names were misspelled as “Lane” and “Lanna”, theImmunization Registry was again able to recognize that the records belonged to twins rather than
the same person because, although the demographic data was almost identical, the Last Update
Date/Time were very close (Date was the same) and Last Update Facility indicated the same clinic.
Unfortunately, they didn’t write down the mother’s information at the Health Fair, but recorded hersister-in-laws name and address instead, so the Immunization Registry was not able to automaticallylink this new information to the information it already had for “Lalainne” and “Lalannie”.
Other Possibilities:

1380

A better outcome could have happened if the clinic had recorded any one of several different data
elements that would have helped tie this new data to the previous data. Any one of the Mothers
Maiden Name (even the Mother’s First Name component), the Home Phone Number, or the unique
identifier for the kids which was printed on the “yellow card” from Pediatric Healthcare would havehelped.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

49

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

5.4 Relationship between the PIX Integration Profile and eMPI1385

The PIX Integration Profile achieves the integration of disparate Patient Identifier Domains byusing a cross-referencing approach between Patient Identifiers associated with the same patient.
This section discusses how this approach is compatible with environments that wish to establish
master patient identifiers (MPI), or enterprise MPI (eMPI) systems. An eMPI may be considered aparticular variation in implementation of the PIX Integration Profile.

1390

The concept of an MPI is a rather broad concept, yet it is most often associated with the creation ofa master patient identifier domain. Such a master domain is considered more broadly applicable ormore “enterprise-level” than the other patient identifier domains it includes. Such a hierarchicalinclusion of patient identification domains into a “master patient identification domain” can beconsidered a particular case of patient cross-reference, where the patient identifiers in the various
domains are cross-referenced to the patient identifiers of the master domain. Two possible
configurations are depicted by Figure 5.4-1.

1395

Patient Identity
Cross-referenceManager

Patient Identification
Domain C(Master Domain)

Master Patient Index
MasterPatient
Index

Master (C) Patient
Identity Source

Patient Identification
Domain C(Master Domain)

Master (C) Patient
Identity Source

Patient Identification
Domain A

Patient Identity Cross-referenceManager

Patient Identification
Domain B

Patient Identification
Domain A

Two domains included in a Master Patient Index

Patient Identification
Domain B

The same configuration represented as 3 cross-referenced domains

Figure 5.4-1 PIX Profile Relationship to eMPI

1400

1405

Figure 5.4-1 above shows how the Master Patient Identifier Domain (Domain C), in a typical MPI
approach, is simply another patient Identification Domain when considered in a Cross-referencing
approach. The decision to place enterprise-wide systems such as Clinical Data Repositories into theso-called master domain is simply a configuration choice. In addition, such a configuration
sometimes assumes that any system in Patient Domain A not only manages the patient Identifiers of
Domain A but is also aware of those of Domain C. In the Patient Identifier Cross-reference
Integration Profile, this is a configuration choice where certain systems have been designed andconfigured to operate across multiple domains. Thus the entity often called an MPI (shown by theoval) is actually the combination of a Patient Identity Source Actor (ADT) along with a Patient
Identifier Cross-reference Manager.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

50

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles1410________________________________________________________________________________The PIX Integration Profile can coexist with environments that have chosen to deploy a distinct
MPI, and provides a more scalable approach. Many other configurations can also be deployed, inparticular those where the creation of a master domain “including” the other domains is notnecessary (i.e., a simple federation of domains where none is actually the master).

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

51

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
document, Section 17.3.6.4, for a description of the response issued by the Context Manager
Actor.

985

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

3.8 Patient Identity Feed
990

This section corresponds to Transaction ITI-8 of the IHE IT Infrastructure Technical Framework.
Transaction ITI-8 is used by the Patient Identity Source, Patient Identifier Cross-referenceManager and Document Registry actors.
3.8.1 Scope
This transaction communicates patient information, including corroborating demographic data,
after a patient’s identity is established, modified or merged or after the key corroborating
demographic data has been modified.

995

3.8.2 Use Case Roles
Patient Identifier
Cross-reference
M anager

Patient Identity
SourceDocument
Registry

Patient Identity
Feed

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

Actor: Patient Identifier Cross-reference Manager
Role: Serves a well-defined set of Patient Identification Domains. Based on information
provided in each Patient Identification Domain by a Patient Identification Source Actor, it
manages the cross-referencing of patient identifiers across Patient Identification Domains.
Actor: Document Registry1005

Role: Uses patient identifiers provided by Patient Identity Source to ensure that XDS
Documents metadata registered is associated with a known patient and updates patient identity indocument metadata by tracking identity change operations (e.g., merge).
3.8.3 Referenced Standards
HL7 Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

40

Copyright © 2011 IHE International, Inc.

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

HL7 Version 2.3.1 was selected for this transaction for the following reasons:• It provides a broader potential base of Patient Identity Source Actors capable of participatingin the profiles associated with this transaction.
• It allows existing ADT Actors from within IHE Radiology to participate as Patient Identity
Source Actors.

1015

3.8.4 Interaction Diagram
Document RegistryorPatient Identifier
Cross-referenceManager

Patient Identity
SourceAdmit/ Register or Update Patient: HL7 ADT^** - A01, A 04, A05, A08
Patient Identity Merge: HL7 ADT^A40

Figure 3.8-1 Patient Identity Sequence

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

1025

The following events from a Patient Identity Source Actor will trigger one of the Admit/Registeror Update messages:• A01 – Admission of an in-patient into a facility• A04 – Registration of an outpatient for a visit of the facility• A05 – Pre-admission of an in-patient (i.e., registration of patient information ahead of actual
admission).
Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger
the following Admit/Register or Update message:• A08 – Update Patient Information

1030

The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic onmessages received from Patient Identity Source Actors. For a given Patient Identifier Domain
there shall be one and only one Patient Identity Source Actor, but a given Patient Identity Source
Actor may serve more than one Patient Identifier Domain.
3.8.4.1.2 Message Semantics

1035

The Patient Identity Feed transaction is conducted by the HL7 ADT message, as defined in thesubsequent sections. The Patient Identity Source Actor shall generate the message whenever apatient is admitted, pre-admitted, or registered, or when some piece of patient demographic data___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

41

Copyright © 2011 IHE International, Inc.

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

1040

changes. Pre-admission of inpatients shall use the A05 trigger event. The segments of themessage listed below are required, and their detailed descriptions are provided in the following
subsections.
Note:

Conventions used in this section as well as additional qualifications to the level of specification and HL7
profiling are stated in ITI TF-2x: Appendix C and C.1.

Required segments are defined below. Other segments are optional
1045

Table 3.8-1 ADT Patient Administration Messages
ADT

Patient Administration Message

Chapter in HL7
2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

PV1

Patient Visit

3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See ITI TF-2x: C.2.3, “Acknowledgement Modes”, for definition anddiscussion of the ACK message.
1050

1055

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

1060

1065

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of ADT; the second component shall have one of the values of A01, A04, A05 or A08 as
appropriate. The third component is optional; however, if present, it shall have the following
value for each corresponding message type:• ADT_A01 for A01 message type
• ADT_A01 for A04 message type
• ADT_A01 for A05 message type
• ADT_A01 for A08 message type___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

42

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.8.4.1.2.2 EVN Segment

1070

The Patient Identity Source Actor is not required to send any attributes within the EVN segment
beyond what is specified in the HL7 standard. See Table C.1-4 in ITI TF-2x: C.2.4 “Common
Segment Definitions” for the specification of this segment.
3.8.4.1.2.3 PID Segment
The Patient Identity Source Actor is not required to send any attributes within the PID segment
beyond what is specified in the HL7 standard.

1075

When sending ADT messages A01, A04, and A05, the Patient Identity Source actor shallpopulate appropriate values in the fields as listed in Table 3.8-2:
Table 3.8-2 IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

O

00104

Set ID - Patient ID

2

20

CX

O

00105

Patient ID

3

250

CX

R

00106

Patient Identifier List

4

20

CX

O

00107

Alternate Patient ID

5

250

XPN

R

00108

Patient Name

6

250

XPN

R+

00109

Mother’s Maiden Name

7

26

TS

R+

00110

Date/Time of Birth

8

1

IS

R+

00111

Administrative Sex

9

250

XPN

O

00112

Patient Alias

10

250

CE

O

00113

Race

11

250

XAD

R2

00114

Patient Address

12

4

IS

O

00115

County Code

13

250

XTN

R2

00116

Phone Number - Home

14

250

XTN

R2

00117

Phone Number - Business

15

250

CE

O

0296

00118

Primary Language

16

250

CE

O

0002

00119

Marital Status

17

250

CE

O

0006

00120

Religion

18

250

CX

O

00121

Patient Account Number

19

16

ST

R2

00122

SSN Number – Patient

20

25

DLN

R2

00123

Driver's License Number - Patient

21

250

CX

O

00124

Mother's Identifier

22

250

CE

O

00125

Ethnic Group

23

250

ST

O

00126

Birth Place

24

1

ID

O

00127

Multiple Birth Indicator

25

2

NM

O

00128

Birth Order

26

250

CE

O

0171

00129

Citizenship

27

250

CE

O

0172

00130

Veterans Military Status

0001
0005
0289

0189
0136

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

43

Copyright © 2011 IHE International, Inc.

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

LEN

DT

OPT

28

250

CE

O

29

26

TS

O

30

1

ID

O

TBL#

ITEM#

0212

00739

Nationality

00740

Patient Death Date and Time

00741

Patient Death Indicator

0136

ELEMENT NAME

Adapted from the HL7 standard, Version 2.3.1
1080

Note1: This table reflects attributes required to be handled by the Patient Identifier Cross-reference Manager (receiver). It is
likely that not all attributes marked as R2 or R+ above will be sent in some environments.
Note2: The field length of many attributes in this table exceeds the requirements stated in HL7 2.3.1. The Patient Identifier
Cross-reference Manager (receiver) is required to support these extended lengths to cope with the information it
needs to complete identifier cross-referencing logic. The Patient Identity Source may or may not send values ofthe full length listed in this table.

1085

1090

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

1095

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

1100

1105

1110

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
PID segment as specified in HL7 standard as well as their extended field length as defined inTable 3.8-2. 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.
If the PID-3.4 (assigning authority) component is not included in the message (as described in
ITI TF-2a: 3.8.4.1.2.3) the Patient Identifier Cross-reference Manager shall fill PID-3.4 prior tostoring the ID information and performing its cross-referencing activities. The information filledby the Patient Identifier Cross-reference Manager is based on the configuration associating eachof the Patient Identity Source actors with the subcomponents of the correct assigning authority(namespace ID, UID and UID type). (See 3.8.4.1.3.1 below for a list of required Patient
Identifier Cross-reference Manager configuration parameters).
A single Patient Identity Source Actor can serve multiple Patient Identification domains. The
Patient Identifier Cross-reference Manager Actor shall only recognize (by configuration) a single
Patient Identity Source Actor per domain. (See ITI TF-2a: 3.8.4.1.3.1 below for a list of required
Patient Identifier Cross-reference Manager configuration parameters).
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

44

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient
Identifier Cross-reference Manager Actor, but its specification is beyond the scope of IHE.
1115

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 Notificationtransaction (see ITI TF-2a: 3.10 for the details of that transaction).

1120

3.8.4.1.3.1 Required Patient Identifier Cross-reference Manager Configuration

1125

1130

The following items are expected to be parameters that are configurable on the Patient Identifier
Cross-reference Manager Actor. For each Patient Identification Domain included in the
Identification Cross-reference Domain managed by a Patient Identifier Cross-reference Manager
Actor, the following configuration information is needed:• Identifier of the Domain. This identifier shall specify all 3 components of the HL7 assigningauthority (including the namespace ID and/or both the universal ID and universal ID typesubcomponents) of the PID-3 field for the identification of the domain.
• Patient Identity Source Actor for the domain. This is expected to be the MSH-3 Sending
Application and the corresponding MSH-4 Sending Facility fields in the HL7 ADT message.
(Alternative identification schemes might include IP address of the Patient Identity Source
Actor or Node Authentication if the Audit Trail and Node Authentication Integration Profile
is used.)3.8.4.1.4 Expected Actions – Document Registry1135

The Document Registry shall be capable of accepting attributes in the PID segment as specified
in Table 3.8-2. The Patient Identity Feed transaction contains more triggers and data than what
the XDS Document Registry needs for its operation. In particular, A08 – Update Patient
Information, if received shall be ignored.
Table 3.8-2 IHE Profile - PID segment
SEQ
3

LEN
250

DT
CX

OPT

TBL#

R

ITEM#
00106

ELEMENT NAME
Patient Identifier List

Adapted from the HL7 standard, Version 2.3.1
1140

1145

Note: This table reflects only the attributes required to be handled by the Document Registry (receiver). Other attributes of
the PID Segment may be ignored.

If subcomponents 2 and 3 (the universal ID and the universal ID Type of Assigning Authority) of
the Patient Identification Domain of the XDS Affinity Domain in PID-3.4 are not filled in themessage (as described in ITI TF-2a: 3.8.4.1.2.3) the Document Registry shall fill subcomponents
2 and 3 of the Patient Identification Domain of the XDS Affinity Domain prior to storing thepatient identity in the registry. The assigning authority information filled by the Document
Registry is based on its configuration of the Patient Identification Domain of the XDS Affinity
Domain (See ITI TF-2a: 3.8.4.1.4.1 below for a list of required Document Registry
configuration parameters).
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

45

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
1150

The Document Registry shall store only the patient identifiers of the patient identification
domain designated by the XDS Affinity Domain for document sharing in the registry. Patient
identifiers of other patient identification domains (assigning authorities), if present in a received
message, shall be ignored.
3.8.4.1.4.1 Required Document Registry Configuration

1155

1160

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

1165

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

1170

3.8.4.2.2 Message Semantics
The Patient Identity Feed transaction is an HL7 ADT message. The message shall be generated
by the system (Patient Identity Source Actor) that performs the update whenever two patient
records are found to reference the same person.

1175

Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7 profilingare stated in ITI TF-2x: Appendix C and C.1.

The segments of the HL7 Merge Patient message listed below are required, and the detailed
description of the message is provided in ITI TF-2a: 3.8.4.2.2.1–3.8.4.2.2.6. The PV1 segment is
optional.
Table 3.8-3 ADT A40 Patient Administration Message
ADT A40

Patient Administration Message

Chapter in HL7
v2.3.1MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

MRG

Merge Information

3

[PV1]

Patient Visit

3___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

46

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
1180

1185

1190

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See ITI TF-2x: C.2.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
A separate merge message shall be sent for each pair of patient records to be merged. For
example, if Patients A, B, and C are all to be merged into Patient B, two ADT^A40 messages
would be sent. In the first ADT^A40 message, patient B would be identified in the PID segment
and Patient A would be identified in the MRG segment. In the second ADT^A40 message,
patient B would be identified in the PID segment, and Patient C would be identified in the MRG
segment.
Modification of any patient demographic information shall be done by sending a separate Update
Patient Information (A08) message for the current Patient ID. An A40 message is the only
method that may be used to update a Patient ID.
3.8.4.2.2.1 MSH Segment
MSH segment shall be constructed as defined in ITI TF-2x: C.2.2 “Message Control”.

1195

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of ADT; the second component shall have value of A40. The third component is optional;
however, if present, it shall have a value of ADT_A39.
3.8.4.2.2.2 EVN Segment
See ITI TF-2x: C.2.4 for the list of all required and optional fields within the EVN segment.
3.8.4.2.2.3 PID Segment

1200

The PID segment shall be constructed as defined in ITI TF-2a: 3.8.4.1.2.3.
3.8.4.2.2.4 MRG Segment

1205

The PID and PV1 segments contain the dominant patient information, including patient identifier
and the issuing assigning authority. The MRG segment identifies the “old” or secondary patient
records to be de-referenced. HL7 does not require that the “old” record be deleted; it does requirethat the “old” identifier shall not be referenced in future transactions following the merge.
The Patient Identity Source Actor shall send the “old” patient identifier (to be merged) in MRG1, with the identifier value in the component MRG-1.1 and the assigning authority in thecomponent MRG-1.4. The Patient Identity Source Actor shall populate the same value of theassigning authority in PID-3.4, in the component MRG-1.4.

1210

IHE does not require that the Patient Identity Source Actor send any attributes within the MRG
segment beyond what is specified in the HL7 standard.
3.8.4.2.2.5 PV1 Segment
PV1 segment shall be constructed as defined in ITI TF-2a: 3.8.4.1.2.4.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

47

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.8.4.2.3 Expected Actions
1215

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

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

250

CX

R

00211

Prior Patient Identifier List

2

250

CX

O

00212

Prior Alternate Patient ID

3

250

CX

O

00213

Prior Patient Account Number

4

250

CX

O

00214

Prior Patient ID

5

250

CX

O

01279

Prior Visit Number

6

250

CX

O

01280

Prior Alternate Visit ID

7

250

XPN

R2

01281

Prior Patient Name

Adapted from the HL7 Standard, Version 2.3.1
1220

1225

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

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

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

250

CX

R

00211

Prior Patient Identifier List

2

250

CX

O

00212

Prior Alternate Patient ID

3

250

CX

O

00213

Prior Patient Account Number

4

250

CX

R2

00214

Prior Patient ID

5

250

CX

O

01279

Prior Visit Number

6

250

CX

O

01280

Prior Alternate Visit ID

7

250

XPN

R2

01281

Prior Patient Name

Adapted from the HL7 Standard, Version 2.3.1

In addition, the Document Registry shall perform the Expected Actions as specified in ITI TF2a: 3.8.4.1.4.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

48

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
1235

1240

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

1245

The Patient Admit/Register transactions (A01, A04, A05) and Update Patient Information (A08)transaction are to be audited as “Patient Record” events, as defined in table 3.20.6-1. The actors
involved in the transaction shall create audit data in conformance with DICOM (Supp 95)“Patient Record”. The following tables show items that are required to be part of the audit record
for these specific PIX transactions.
3.8.5.1.1 Patient Identity Source Actor audit message:
Field Name
Event
AuditMessage/
EventIdentification

1250

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCode

M

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)“C” (create) for A01, A04, A05“U” (update) for A08

Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identity Source Actor) (1)Patient (1)Where:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

49

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Identity Source Actor facility and sending
application from the HL7 message; concatenated together, separated by
the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

AlternativeUserIDM

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

The identity of the Patient Identifier Cross-reference Manager orDocument Registry facility and receiving application from the HL7
message; concatenated together, separated by the | character.

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

50

Copyright © 2011 IHE International, Inc.

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

3.8.5.1.2 Patient Identifier Cross-reference Manager or Document Registry Actor
audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

EventID

M

EventActionCode

M

Value Constraints
EV(110110, DCM, “Patient Record”)“C” (create) for A01, A04, A05“U” (update) for A08

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-8”, “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:The identity of the Patient Identity Source Actor facility and sending
SourceUserIDM

application from the HL7 message; concatenated together, separated by
the | character.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Identifier Cross-reference Manager orDocument Registry facility and receiving application from the HL7
message; concatenated together, separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

1260
Patient___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

51

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

3.8.5.2 Audit Record Considerations – Patient Identity Merge (Merge Patient ID)

1265

The Patient Identity Merge transaction (A40) is to be audited as a “Patient Record” event, as
defined in Table 3.20.6-1. The source of the transaction shall create audit data in conformancewith DICOM (Supp 95) “Patient Record”. The following tables show items that are required tobe part of the audit record for the Patient Identity Merge transaction. 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.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

52

Copyright © 2011 IHE International, Inc.

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

1270

3.8.5.2.1 Patient Identity Source Actor audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCode

M

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)“D” (delete) for the Delete operation“U” (update) for the Update operation

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

Destination
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Identity Source Actor facility and sending
application from the HL7 message; concatenated together, separated by
the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserIDM

The identity of the Patient Identifier Cross-reference Manager orDocument Registry facility and receiving application from the HL7
message; concatenated together, separated by the | character.

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, as specified in RFC 3881.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

53

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)1275

3.8.5.2.2 Patient Identifier Cross-reference Manager or Document Registry Actor
audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCode

M

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)“D” (delete) for the Delete audit record“U” (update) for the Update audit record

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:The identity of the Patient Identity Source Actor facility and sending
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

application from the HL7 message; concatenated together, separated by
the | character.

AlternativeUserIDM

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Identifier Cross-reference Manager orDocument Registry facility and receiving application from the HL7
message; concatenated together, separated by the | character.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

54

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
M

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

UserNameUnot specialized

UserIsRequestorM“false”

AlternativeUserID

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

1280
Patient(AudittMessage/
ParticipantObjectIdentifi
cation)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

55

Copyright © 2011 IHE International, Inc.

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

3.9 PIX Query
1285

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

1290

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

Patient Identifier
Cross-referenceManager

PIX Query

1295

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

1300

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

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

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

56

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.9.4 Interaction Diagram
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

Get Corresponding
Identifiers: HL7 QBP^Q23

Return Corresponding
Identifiers: HL7 RSP^K23

Figure 3.9-1 Get Corresponding Identifiers Sequence

3.9.4.1 Get Corresponding Identifiers1310

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

3.9.4.1.2 Message Semantics

1320

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

Table 3.9-1 QBP Query By Parameter
QBP

Query By Parameter

Chapter in HL7
2.5

MSH

Message Header

2

QPD

Query Parameter Definition

5

RCP

Response Control Parameter5___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

57

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
1325

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

1330

Field MSH-9 Message Type shall have all three components populated with a value. The firstcomponent shall have a value of QBP; the second component shall have the value of Q23. The
third component shall have a value of QBP_Q21.
3.9.4.1.2.2 QPD Segment

1335

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

LEN

DT

OPT

TBL#

ITEM#

0471

01375

Message Query NameELEMENT NAME

00696

Query Tag

1

250

CE

R

2

32

ST

R+

3

250**

CX

R

Person Identifier

4

250

CX

O

What Domains Returned

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

1340

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

1345

1350

1355

The Patient Identifier Cross-reference Consumer Actor shall provide component QPD-3.4,
Assigning Authority, by including either the first subcomponent (namespace ID) or the second
and third subcomponents (universal ID and universal ID type) If all three subcomponents are
populated, the first subcomponent shall reference the same entity as is referenced by the second
and third components.
If the requesting system wishes to select the domains from which they wish to receive PatientIDs, it does so by populating QPD-4-What Domains Returned with as many repetitions as
domains for which it wants to receive Patient IDs. Each repetition of QPD-4 shall contain an
instance of data type CX in which only the fourth component (Assigning Authority) is populated;
the remaining components shall be empty. The responding system shall return the Patient ID
value for each requested domain if a value is known.
If QPD-4 is empty, the Patient Identifier Cross-reference Manager Actor shall return Patient IDs
for all domains for which it possesses a corresponding Patient ID (subject to local publication
restrictions).
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

58

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________The Consumer shall specify “IHE PIX Query” for QPD-1 Message Query Name.
3.9.4.1.2.3 RCP Segment
1360

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

1365

3.9.4.1.3 Expected Actions
The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the
QPD segment as specified in Table 3.9-2.

1370

The Patient Identifier Cross-reference Manager Actor must be capable of receiving all valid
combinations of subcomponents that make up the Assigning Authority component (i.e., all valid
combinations of QPD-3.4).
The Patient Identifier Cross-reference Manager Actor shall be capable of accepting multiple
concurrent PIX Query requests (Get Corresponding Identifiers messages) and responding
correctly using the Return Corresponding Identifiers message.
3.9.4.2 Return Corresponding Identifiers1375

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

1380

1385

The Return Corresponding Identifiers transaction is conducted by the HL7 RSP^K23 message.
The Patient Identifier Cross-reference Manager Actor shall generate this message in direct
response to the QBP^Q23 query message previously received. This message satisfies the
Application Level, Original Mode Acknowledgement for the HL7 QBP^Q23 message. The
segments of the message listed without enclosing square brackets in the Table below arerequired. Detailed descriptions of all segments listed in the table below are provided in thefollowing subsections. Other segments of the message are optional.
Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7 profilingare stated in ITI TF-2x: Appendix C and C.1.

Table 3.9-3 RSP Segment Pattern Response
RSP

Segment Pattern Response

Chapter in HL7
2.5___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

59

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
RSP

1390

Segment Pattern Response

Chapter in HL7
2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2

[ERR]

Error segment

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5

[PID]

Patient Identification

3

3.9.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in ITI TF-2x: C.2.2, “Message Control”.
Field MSH-9-Message Type shall have all three components populated with a value. The firstcomponent shall have a value of RSP; the second component shall have the value of K23. The
third component shall have a value of RSP_K23.

1395

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

1400

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

LEN

DT

OPT

1

32

ST

R

2

2

ID

R+

TBL#
0208

ITEM#

ELEMENT NAME

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5

1405

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

1410

The Patient Identifier Cross-reference Manager Actor shall return only those attributes within the
PID segment that are required by the HL7 standard: PID-3-Patient IdentifierList and PID-5Patient Name.
The PID segment is returned only when the Patient Identifier Cross-reference Manager Actor
recognizes the specified Patient Identification Domain and Patient ID and an identifier exists for___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

60

Copyright © 2011 IHE International, Inc.

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

1415

1420

1425

1430

1435

1440

the specified patient in at least one other domain. See ITI TF-2a: 3.9.4.2.2.6, “Patient Identifier
Cross-reference Manager Actor Query Response Behavior,” for a detailed description of how thePatient Identifier Cross-reference Manager Actor responds to the query request under various
circumstances.
The Patient Identifier Cross-reference Manager Actor shall use the field PID-3 Patient Identifier
List to convey the Patient ID uniquely identifying the patient within each Patient Identification
Domain for which a Patient ID exists for the specified patient. Each resulting ID returned in PID3 shall include a fully qualified Assigning Authority component. In other words, the Assigning
Authority component returned shall include ALL subcomponents (namespace ID, Universal ID,
and Universal ID type).
To eliminate the issue of conflicting name values between Patient Identifier Domains, the Patient
Identifier Cross-reference Manager Actor shall return in an empty (not present) value in the first
repetition of field PID-5-Patient Name, and shall return a second repetition of field PID-5Patient Name in which the only populated component is Component 7 (Name Type Code).
Component 7 of repetition 2 shall contain a value of S (Coded Pseudo-name to assure
anonymity). All other components of repetition 2 shall be empty (not present).
3.9.4.2.2.6 Patient Identifier Cross-reference Manager Actor Query Response
Behavior
It is wholly the responsibility of the Patient Identifier Cross-reference Manager Actor to performthe matching of patient identifiers based on the patient traits it receives. The information
provided by the Patient Identifier Cross-reference Manager Actor to Patient Identifier Crossreference Consumer Actors is a list of cross-referenced identifiers in two or more of the domains
managed by the cross-referencing Actor. The list of cross-references is not made available until
the set of policies and processes for managing the cross-reference function have been completed.
The policies of administering identities adopted by the cooperating domains are completelyinternal to the Patient Identifier Cross-reference Manager Actor and are outside of the scope of
this framework. Possible matches should not be communicated until the healthcare institution
policies and processes embodied in the Patient Identifier Cross-reference Manager Actor reach apositive matching decision.
The Patient Identifier Cross-reference Manager Actor shall respond to the query request as
described by the following 6 cases:

1445

1450

Case 1: The Patient Identifier Cross-reference Manager Actor recognizes the specified Patient
Identification Domain and Patient ID sent by the Patient Identifier Cross-reference Consumer in
QPD-3, and corresponding identifiers exist for the specified patient in at least one of the domains
requested in QPD-4 (one identifier per domain). (See Case 6 below for the required behavior if
there are multiple identifiers recognized within a given Identifier Domain by the Patient
Identifier Cross-reference Manager Actor.)
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.
A single PID segment is returned in which one repetition of PID-3 Patient Identifier List is
populated for each of the domains, if any, that the Patient Identifier Cross-reference Manager___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

61

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
1455

Actor did recognize in which a single identifier exists for the requested patient, not including thequeried-for patient identifier that is returned in QPD-3.
Case 2: The Patient Identifier Cross-reference Manager Actor recognizes the Patient
Identification Domain and Patient ID sent in QPD-3, but no identifier exists for that patient inany of the domains sent in QPD-4.

1460

AA (application accept) is returned in MSA-1.
NF (no data found, no errors) is returned in QAK-2.
No PID segment is returned.

1465

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

1470

COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

3

4

Field Repetition

1

5

Component Number

1

6

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

1475

Case 4: The Patient Identifier Cross-reference Manager Actor does not recognize the Patient
Identification Domain of the identifier sent in QPD-3.
AE (application error) is returned in MSA-1 and in QAK-2.
An ERR segment is returned in which the components of ERR-2-Error Location are valued asfollows.

1480
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence1___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

62

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________COMP #COMPONENT NAME

VALUE

3

Field Position

3

4

Field Repetition

1

5

Component Number

4

6

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

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Identifier Cross-referenceManager Actor did not recognize the value in the fourth component of QPD-3.
Case 5: The Patient Identifier Cross-reference Manager Actor does not recognize one or more of
the Patient Identification Domains for which an identifier has been requested.
AE (application error) is returned in MSA-1 and in QAK-2.

1490

For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.
COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

4

4

Field Repetition(see below)

5Component Number(empty)6

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

1500

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

1505

OK (data found, no errors) is returned in QAK-2.
A single PID segment is returned in which one repetition of PID-3-Patient Identifier List is
populated for each of the identifiers, not including the queried-for patient identifier that isreturned in QPD-3. If the Patient Identifier Cross-reference Manager Actor chooses to return___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

63

Copyright © 2011 IHE International, Inc.

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

1510

multiple identifiers associated with the same domain, it shall return these identifiers grouped insuccessive repetitions within the PID-3-Patient Identifier List.
3.9.4.2.3 Expected Actions
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.

1515

1520

In the case where the returned list of identifiers contains multiple identifiers for a single domain,
the Patient Identifier Cross-reference Consumer shall either use ALL of the multiple identifiers
from the given domain or it shall ignore ALL of the multiple identifiers from the given domain.
This allows Patient Identifier Cross-reference Consumer Actors capable of handling multiple
identities for a single patient within a single domain (i.e., those that can correctly aggregate theinformation associated with the different identifiers) to do so. For those Patient Identifier Crossreference Consumer Actors not capable of handling this situation, ignoring the entire list ofdifferent identifiers prevents the consumer from presenting incomplete data.
3.9.5 Security Considerations
3.9.5.1 Audit Record Considerations

1525

The PIX Query Transaction is a Query Information event as defined in Table 3.20.6-1. The
Actors involved in the transaction shall create audit data in conformance with DICOM (Supp 95)“Query”, with the following exceptions:3.9.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-9”, “IHE Transactions”, “PIX Query”)

Source (Patient Identifier Cross-reference Consumer) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager) (1)Audit Source (Patient Identity Cross-reference Consumer) (1)Patient (0..n)Query Parameters(1)Where:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

64

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Identifier Cross-reference Consumer Actor
facility and sending application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserIDM

The identity of the Patient Identifier Cross-reference Manager facility
and receiving application from the HL7 message; concatenated
together, separated by the | character.

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, as specified in RFC 3881.

1530
Destination
AuditMessage/
ActiveParticipant

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

65

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-9”, “IHE Transactions”, “PIX Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

The complete query message (including MSH and QPD segments),
base64 encoded.

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

3.9.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-9”, “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

UserIDM

The identity of the Patient Identifier Cross-reference Consumer Actor
facility and sending application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Identifier Cross-reference Manager facility
and receiving application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

1535
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, as specified in RFC 3881.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

66

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectSensitivity

U

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-9”, “IHE Transactions”, “PIX Query”)

ParticipantObjectSensitivity

U

Not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

Not specialized

ParticipantObjectQueryM

The complete query message (including MSH and QPD segments),
base64 encoded.

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

67

Copyright © 2011 IHE International, Inc.

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

1540

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

1545

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

1550

3.10.2 Use Case Roles
Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager

PIX Update
Notification

Actor: Patient Identifier Cross-reference Manager

1555

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

1560

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

1565

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

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

68

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.10.4 Interaction Diagram

Patient Identifier
Cross-reference
Consumer

Patient Identifier
Cross-referenceManager
Update Person Information:
HL7 ADT^A31

Figure 3.10-1 Update Person Information Sequence

3.10.4.1 Update Person Information
1570

3.10.4.1.1

Trigger Events

1575

The Patient Identifier Cross-reference Manager shall notify a Patient Identifier Cross-reference
Consumer when there is a change in a set of cross-referenced patient identifiers for any of thepatient identifiers belonging to Patient Identifier Domains of interest to the consumer. The
configuration of the domains of interest to a Patient Cross-reference Consumer is maintained by
the Patient Cross-reference Manager Actor.
Several notifications may have to be issued to communicate a single update to a set of crossreference patient identifiers as required to reflect all the changes on the resulting sets of crossreference patient Identifiers belonging to Patient Identifier Domains of interest to the Patient
Identifier Cross-referencing Consumer.

1580

The following HL7 trigger event will be used to update to the list of patient identifiers:• A31 – Update Person Information
3.10.4.1.2

Message Semantics

1585

The PIX Update Notification transaction is conducted by the ADT^A31 message. The Patient
Identifier Cross-reference Manager Actor initiates this transaction whenever identifier list
information is updated for a patient.

1590

It is wholly the responsibility of the Patient Identifier Cross-reference Manager Actor to performthe matching of patient identifiers based on the patient traits it receives. The information
provided by the Patient Identifier Cross-reference Manager Actor to Patient Identifier Crossreference Consumer Actors shall only contain a list of cross-referenced identifiers for thedomains of interest as configured with the Patient Identifier Cross-reference Manager actor in___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

69

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
two or more of the domains managed by the cross-referencing Actor. Multiple notifications mayneed to be sent. For example:

1595

1600

1605

1610

1615

Consumer CON_A is configured to receive update notifications for domains DOM_A and
DOM_AD. Notifications are sent as follows:• A PIX A01 feed is sent for a patient for DOM_A. The update notification shall contain thepatient identifier and assigning authority for DOM_A.
• A PIX A01 feed 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
identifier and assigning authority for DOM_A and DOM_AD.
• A PIX A08 feed is processed for DOM_AD changing the patient address. The Patient
Identifier Cross-reference Manager cross references determines this patient is no longer thesame patient as DOM_A. Two update notifications shall be sent. One containing the patient
identifier and assigning authority for DOM_A. The other one containing the patient identifier
and assigning authority for DOM_AD.
The list of cross-references is not made available until the set of policies and processes for
managing the cross-reference function have been completed. The policies of administering
identities adopted by the cooperating domains are completely internal to the Patient Identifier
Cross-reference Manager Actor and are outside of the scope of this standard. Possible matches
should not be communicated until the healthcare institution policies and processes embodied in
the Patient Identifier Cross-reference Manager Actor reach a positive matching decision.
The Patient Identifier Cross-reference Manager Actor Configuration is expected to haveconfiguration indicating which Identity Consumers are interested in receiving the PIX Update
Notification Transactions. This configuration information shall include identification of theidentity consumer systems interested in receiving notifications and, for each of those systems, alist of the patient identifier domains of interest. The Patient Identifier Cross-reference Manager
Actor should account for consumers interested in all domains.
The segments of the message listed in the Table below are required. Other segments are optional.
Table 3.10-1 ADT Patient Administration Message
ADT

1620

Patient Administration Message

Chapter in HL7
2.5

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

PV1

Patient Visit

3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See ITI TF-2x: C.2.3, “Acknowledgement Modes” for the definition anddiscussion of the ACK message.
3.10.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in ITI TF-2x: C.2.2, “Message Control”.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

70

Copyright © 2011 IHE International, Inc.

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

1625

Field MSH-9 Message Type shall have all three components populated with a value. The firstcomponent shall have a value of ADT; the second component shall have the value of A31. The
third component shall have a value of ADT_A05.
3.10.4.1.2.2 EVN Segment
See ITI TF-2x: C.2.4 for the list of all required and optional fields within the EVN segment.
3.10.4.1.2.3 PID Segment

1630

1635

1640

1645

The Patient Identifier Cross-reference Manager Actor shall provide only those attributes within
the PID segment that are required by the HL7 standard: PID-3-Patient Identifier List and PID-5Patient Name.
The Patient Identifier Cross-reference Manager Actor shall use the field PID-3 Patient Identifier
List to convey the Patient IDs uniquely identifying the patient within each Patient Identification
Domain for which a Patient ID exists for the specified patient. Each resulting ID returned in PID3 shall include a fully qualified Assigning Authority component. In other words, the Assigning
Authority component returned shall include ALL subcomponents (namespace ID, Universal ID,
and Universal ID type).
To eliminate the issue of multiple name values between Patient Identifier Domains, the Patient
Identifier Cross-reference Manager Actor shall return a single space character in field PID-5Patient Name.
A single PID segment is sent in which one repetition of PID-3-Patient Identifier List is populated
for each of the identifiers in the notification. If the Patient Identifier Cross-reference Manager
Actor chooses to send multiple identifiers associated with the same domain, it shall return theseidentifiers grouped in successive repetitions within the PID-3-Patient Identifier List.
3.10.4.1.2.4 PV1 Segment
As is specified by the HL7 Standard, Version 2.5, the PV1 Segment is required. The required
field PV1-2-patient class shall contain N (not applicable) to indicate the transmission of patient
information outside the context of a visit or encounter. Other fields shall be left blank.

1650
Table 3.10-2 IHE Profile – PV1 segment
SEQ
2

LEN
1

DT
IS

OPT
R

TBL#

ITEM#

0004

00132

ELEMENT NAME
Patient Class

Adapted from the HL7 Standard, version 2.5

3.10.4.1.3
1655

Expected Actions

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

71

Copyright © 2011 IHE International, Inc.

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

1660

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.

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

1670

The PIX Update Notification Transaction is ”Patient Record” event, as defined in Table 3.20.6-1.
The Actors involved in the transaction shall create audit data in conformance with DICOM(Supp 95) “Patient Record”, with the following exceptions:3.10.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-10”, “IHE Transactions”, “PIX Update Notification”)

Source (Patient Identifier Cross-reference Manager) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Manager) (1)Patient IDs(1..n) (represents the components of PID-3)
Where:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

72

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Identifier Cross-reference Manager Actor
facility and sending application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDM

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

UserNameU

Not specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

Not specialized

UserNameU

Not specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserIDM

The identity of the Patient Identifier Cross-reference Consumer facility
and receiving application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDU

Not specialized

UserNameU

Not specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

Not specialized

AuditSourceTypeCodeU

Not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

Not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

1675
Patient IDs(AudittMessage/
ParticipantObjectIdentifi
cation)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

73

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectDetail3.10.5.1.2
Event
AuditMessage/
EventIdentification

M

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

Patient Identifier Cross-reference Consumer audit message:
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-10”, “IHE Transactions”, “PIX Update Notification”)

Source (Patient Identifier Cross-reference Manager) (1)Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Consumer) (1)Patient IDs(1..n) (represents the components of PID-3)

Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

The identity of the Patient Identifier Cross-reference Manager Actor
facility and sending application from the HL7 message; concatenated
together, separated by the | character.

UserID

M

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Identifier Cross-reference Consumer facility
and receiving application from the HL7 message; concatenated
together, separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

1680
Patient IDs(AudittMessage/
ParticipantObjectIdentifi
cation)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

74

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

75

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

23 Patient Identifier Cross-referencing HL7 V3 (PIXV3)
4375

The Patient Identifier Cross-referencing HL7 V3 Integration Profile (PIXV3) is targeted at crossenterprise Patient Identifier Cross-reference Domains (as defined in ITI TF-1: 5) as well as
healthcare enterprises with developed IT infrastructure. The discussion in ITI TF-1: 5 fully applies
here, with the obvious adjustments to the referenced transactions.

Patient
Identifier
Domain C

Patient Identifier
Cross-referenceManager

Patient
Identity
Feed HL7 V3Patient Identity
SourceInternal
Domaintransactions

Patient Identifier
Cross-reference
ConsumerOther
IHE Actor

4380

Patient
Identity Feed
HL7 V3

PIX V3UpdateNotification

Patient Identity
SourceInternal
Domaintransactions

Patient Identifier
Cross-reference Domain

Patient Identity Feed HL7
V3, PIXV3 Query & PIXV3
Update Notification

Other
IHE Actor

Patient Identifier
Domain A

PIXV3
UpdateNotification

Patient Identifier
Cross-reference
Consumer
Patient Identifier
Domain B

Figure 23-1 Process Flow with Patient Identifier Cross-referencing HL7 V3

23.1 Actors/Transactions

4385

The actors in this profile are the same as the actors defined in the PIX profile (ITI TF-1: 5.1). Figure23.1-1 shows the actors directly involved in the Patient Identifier Cross-referencing HL7 V3Integration Profile and the relevant transactions between them. Other actors that may be indirectly
involved due to their participation in other related profiles are not shown.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

170

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Patient Identifier
Cross-reference
Consumer

Patient Identity Source

Patient Identity Feed HL7 V3 [ITI-44]↓↓ PIXV3 Query [ITI-45]↑ PIXV3 Update Notification [ITI-46]

Patient Identifier Crossreference Manager

Figure 23.1-1 Patient Identifier Cross-referencing HL7 V3 Actor Diagram

4390

Table 23.1-1 lists the transactions for each actor directly involved in the Patient Identifier Crossreferencing Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete
list of options defined by this Integration Profile and that implementations may choose to support islisted in the ITI TF-1: 23.2.
Table 23.1-1 Patient Identifier Cross-referencing HL7 V3 Integration Profile - Actors andTransactions
Actors4395

Transactions

Optionality

SectionPatient Identity Source

Patient Identity Feed HL7 V3[ITI-44]

R

ITI TF-2b: 3.44

Patient Identifier Crossreference Consumer

PIXV3 Query[ITI-45]

R

ITI TF-2b: 3.45

PIXV3 Update Notification [ITI-46]

O

ITI TF-2b: 3.46

Patient Identifier Crossreference Manager

Patient Identity Feed HL7 V3[ITI-44]

R

ITI TF-2b: 3.44

PIXV3 Query[ITI-45]

R

ITI TF-2b: 3.45

PIXV3 Update Notification[ITI-46]

R

ITI TF-2b: 3.46

The transactions in this profile directly correspond to the transactions used in the PIX profile (ITI
TF-1: 5) and provide the identical functionality. Table 23.1-2 describes this correspondence.
Table 23.1-2 Transactions Correspondence between the PIX and PIXV3 profiles

4400

Transactions in PIX

Section in
VolumeTransactions in PIXV3

SectionPatient Identity Feed [ITI-8]

ITI TF-2a: 3.8

Patient Identity Feed HL7 V3[ITI-44]

ITI TF-2b: 3.44

PIX Query[ITI-9]

ITI TF-2a: 3.9

PIXV3 Query[ITI-45]

ITI TF-2b: 3.45

PIX Update Notification [ITI-10]

ITI TF-2a: 3.10

PIXV3 Update Notification [ITI-46]

ITI TF-2b: 3.46

23.2 Patient Identifier Cross-referencing HL7 V3 Integration Profile
Options
Options that may be selected for this Integration Profile are listed in the Table 23.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified in notes.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

171

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Table 23.2-1 Patient Identifier Cross-referencing HL7 V3 - Actors and Options
Actor

Options

Vol & Section

Patient Identity Source

Pediatric Demographics

Patient Identifier Cross-reference Manager

Pediatric Demographics

Patient Identifier Cross-reference Consumer

PIXV3 Update Notification Transaction

ITI TF-2b: 3.46

4405
23.2.1 Pediatric Demographics
The experience of immunization registries and other public health population databases has shownthat matching and linking patient records from different sources for the same individual person inenvironments with large proportions of pediatric records requires additional demographic data.
4410

4415

In particular, distinguishing records for children who are twins, triplets, etc. – that is, avoiding false
positive matches - may be difficult because much of the demographic data for the two individuals
matches. For instance, twin children may have identical last names, parents, addresses, and dates ofbirth; their first names may be very similar, possibly differing by only one letter. It can be very
difficult for a computer or even a human being to determine in this situation whether the slight firstname difference points to two distinct individuals or just a typographical error in one of the records.
Additional information is extremely helpful in making this determination.
Pediatric Demographics makes use of the following six additional demographic fields to aid record
matching in databases with many pediatric records.

Field

Reason for inclusion

Value

Mother’s Maiden Name

Any information about the mother is
helpful in making a match

Helps create true positive matches

Patient Home
TelephoneA telecom helps match into the righthousehold

Helps create true positive matches

Patient Multiple Birth
Indicator

Indicates this person is a multiple – twin,
triplet, etc.

Helps avoid false positive matches ofmultiplesPatient Birth OrderDistinguishes among those multiples.

Helps avoid false positive matches ofmultiples

Last Update
Date/Time, Last
Update Facility

These fields, although not strictly
demographic, can effectively substitutewhen multiple birth indicator and birthorder are not collected. They indirectly
provide visit information. Provider visitson the same day may likely indicate twochildren brought to a doctor together.

Helps avoid false positive matches ofmultiples4420________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

172

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Patient Identity Source actors which support the Pediatric Demographics option are required tosupport the Patient Identity Management [ITI-30] transaction and shall provide values, whenavailable, for the fields identified as Pediatric Demographics fields.
4425

4430

Patient Identifier Cross-reference Manager actors which support the Pediatric Demographics option
are required to support the Patient Identity Management [ITI-30] transaction, and if values for one
or more of the Pediatric Demographics fields are specified in the Patient Identity Management [ITI30], they shall be considered as part of the matching algorithm of the PIX Manager.
Pediatric Demographics are defined as all of the following:•
Mother’s Maiden Name•
Patient Home Telephone•
Patient Multiple Birth Indicator•
Patient Birth Order•
Last Update Date/Time•
Last Update Facility

4435

23.3 Patient Identifier Cross-referencing HL7 V3 Integration Profile
Process Flows
4440

Sections ITI TF-1: 5.3.1 and ITI TF-1: 5.3.2 describe use cases that this profile addresses. Figures
5.3-1 and 5.3-2 also apply with the changes to the corresponding PIXV3 transactions as specified intable 23.1-2.

23.4 Relationship between the PIXV3 Integration Profile and eMPIThe discussion in ITI TF-1: 5.4 fully applies to this profile.

23.5 Patient Identifier Communication Requirement
4445

4450

The patient identifier in HL7 V3 messages is represented by the II data type. This data type has twocomponents: a root, and an extension. For compatibility with the use of patient identifiers in profiles
using HL7 V2 messages, and with the specification of the patient identifier in the XDS profile, thepatient identifier SHALL be represented as a root and an extension, where the root is anappropriately assigned OID. The direct correspondence between the II data type and the HL7
Version 2.5 CX data type (used in field PID-3) is shown in ITI TF-2x: Appendix R.

23.6 Security Considerations
The implementer of this profile is advised that many risks cannot be mitigated by the IHE profile
and instead the responsibility for mitigation is transferred to the vendor, and occasionally to theoperational environment.
In order to address identified security risks:________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

173

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles
4455________________________________________________________________________________• All actors in PIXV3 should be grouped with a Consistent Time (CT) Profile - Time Client
actor. This grouping will assure that all systems have a consistent time clock to assure a
consistent timestamp for audit logging.
•

All actors in PIXV3 should be grouped with an Audit Trail and Node Authentication(ATNA) profile - Secure Node actor or ATNA Secure Application actor. This grouping willassure that only highly trusted systems can communicate and that all changes are recorded in
the audit log.

•

All actors in PIXV3 should be grouped with an XUA X-Service User or X-Service Provider
actor as appropriate. This grouping will enable service side access control and more detailed
audit logging.

•

All actors in PIXV3 should be grouped with the appropriate actor from the Enterprise User
Authentication (EUA) profile to enable single sign-on inside an enterprise by facilitating one
name per user for participating devices and software.

4460

4465

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

174

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(9, RFC-3881, “Report Number”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

ParticipantObjectQueryU

not specialized
The ParticipantObjectDetail element may occur more than once.

ParticipantObjectDetail3895

In one element, the value of <ihe:RepositoryUniqueId/> in value
attribute, “Repository Unique Id” in type attribute

M

In another element, the value of “ihe:homeCommunityID” as the valueof the attribute type and the value of the homeCommunityID as thevalue of the attribute value

3.44 Patient Identity Feed HL7 V3This section corresponds to Transaction ITI-44 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-44 is used by the Patient Identity Source, Patient Identifier Crossreference Manager and Document Registry Actors.
3.44.1 Scope

3900

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
3905

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

3910

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.

Rev. 8.0 Final Text 2011-08-19

152

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)
Actor: Document Registry3915

Role: Uses patient identifiers provided by Patient Identity Source to ensure that XDS
Documents metadata registered is associated with a known patient and updates patient identity indocument metadata by tracking identity change operations (e.g., merge).
Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)

3920

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

3925

Figure 3.44-1 Patient Identity Sequence

Rev. 8.0 Final Text 2011-08-19

153

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.1 Patient Identity Management – Add or Revise Patient Record
3.44.4.1.1 Trigger Events
The following events from a Patient Identity Source will trigger one of the Add or Revise Patient
Record messages:
3930

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:
Patient Registry Record Revised (PRPA_TE201302UV02)

3935

This trigger event signals that patient information was revised in a Patient Identity Source.
The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic onmessages received from Patient Identity Source Actors. For a given Patient Identifier Domain
there shall be one and only one Patient Identity Source Actor, but a given Patient Identity Source
Actor may serve more than one Patient Identifier Domain.

3940

3945

3.44.4.1.2 Message Semantics
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.

3950

The message information model in ITI TF-2b: 3.44.4.1.2.2.describes the relevant data elements
for this transaction. Specific requirements for the particular actors are found in ITI TF-2b:
3.44.4.1.3 Expected Actions.
3.44.4.1.2.1 Major Components of the Patient Registry Record Added/Revised
Messages
Patient

3955

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.

3960

Provider OrganizationRev. 8.0 Final Text 2011-08-19

154

Copyright © 2011 IHE International, Inc.

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

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

3970

Information about what language(s) should be used to communicate with the focal person can besent in the LanguageCommunication class.
PersonalRelationshipThis is used for sending information pertaining to the mother’s maiden name.
Citizen

3975

Citizenship 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

3980

3985

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.
3.44.4.1.2.2 Message Information Model of the Patient Registry Record
Added/Revised Messages

3990

3995

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 andRev. 8.0 Final Text 2011-08-19

155

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Edition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions are
made on the original RMIMs to arrive at the restricted model:
4000

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

4005

The following roles are omitted:
asPatientOfOtherProvider
guarantor
guardiancontactParty

4010

asMembercareGiver
asStudent
The following participations are omitted:
subjectOf (administrativeObservation)

4015

coveredPartyOf (coverage)

Rev. 8.0 Final Text 2011-08-19

156

Copyright © 2011 IHE International, Inc.

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

Figure 3.44.4.1.2-1

4020

The attributes of this model are described in the following table. Note that CMETs are notdiscussed, as the HL7 definitions for them are being used.
Table 3.44.4.1.2-1
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Patient

The primary record for the focal person in a Patient Identity SourceclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Identifiers designated by this patient identity source for the focal
personPatient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

confidentialityCode [0..*]

Value(s) that control the disclosure of information about this living

Rev. 8.0 Final Text 2011-08-19

157

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Patient (SET<CE>) {CWE:Confidentiality}

subject as a patient

veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status granted by the scoperorganization, often resulting in preferred treatment and special
considerations. Examples include board member, diplomat.

PersonA subtype of LivingSubject representing a human being
Either Person.name or Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
telecom [0..*]

Telecommunication address(es) for communicating with this person

Person (BAG<TEL>)
administrativeGenderCode [0..1]

A value representing the gender (sex) of this person. Note: this
attribute does not include terms related to clinical gender which is acomplex physiological, genetic and sociological concept that
requires multiple observations in order to be comprehensively
described.

Person (CE) {CWE:AdministrativeGender}

birthTime [0..1]

The date and time this person was born

Person (TS)deceasedInd [0..1]

An indication that this person is dead

Person (BL)deceasedTime [0..1]

The date and time this person died

Person (TS)multipleBirthInd [0..1]

An indication that this person was part of a multiple birth

Person (BL)multipleBirthOrderNumber [0..1]

The order in which this person was born if part of a multiple birth

Person (INT)
addr [0..*]Address(es) for corresponding with this person

Person (BAG<AD>)maritalStatusCode [0..1]

A value representing the domestic partnership status of this person

Person (CE) {CWE:MaritalStatus}
religiousAffiliationCode [0..1]

A value representing the primary religious preference of this person

Person (CE) {CWE:ReligiousAffiliation}
raceCode [0..*]A set of values representing the races of this person

Person (SET<CE>) {CWE:Race}ethnicGroupCode [0..*]A set of values representing the ethnic groups of this person

Person (SET<CE>) {CWE:Ethnicity}

Rev. 8.0 Final Text 2011-08-19

158

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number. Please see notes abovein the Major Components section on the use of OtherIDs.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role" except
for Citizen, or Employee.

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)
PersonalRelationship

A personal relationship between the focal living subject and anotherliving subject

classCode [1..1] (M)Structural attribute; this is a "personal relationship" role

Role (CS) {CNE:PRS, fixed value= "PRS"}
id [0..*]

Identifier(s) for this personal relationshipRole (SET<II>)code [1..1] (M)A required value specifying the type of personal relationshipbetween the relationshipHolder and the scoping living subject
drawn from the PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

Role (CE) {CWE:PersonalRelationshipRoleType}A value specifying the state of this personal relationship (based on
the RIM Role class state-machine), for example, following divorce
a spouse relationship would be "terminated".

statusCode [0..1]
Role (CE){CWE:RoleStatus}
effectiveTime [0..1]
Role (IVL<TS>)

An interval of time specifying the period during which this personal
relationship is in effect, if such time is applicable and known.

CitizenUsed to capture person information relating to citizenship.

classCode [1..1] (M)Structural attribute; this is a "citizen" role

Role (CS) {CNE:CIT, fixed value= "CIT"}
id [0..*]

Identifier(s) for the focal person as a citizen of a nationRole (SET<II>)
effectiveTime [0..1]

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

Employee (IVL<TS>)
NationA politically organized body of people bonded by territory andknown as a nation.

classCode [1..1] (M)Structural attribute; this is a 'nation' type of entity

Organization (CS) {CNE:NAT, fixed value= "NAT"}
determinerCode [1..1] (M)Structural attribute; this is a specific entity

Organization (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
code [1..1] (M)A value that identifies a nation state

Organization (CD) {CWE:NationEntityType}name [0..1]

Rev. 8.0 Final Text 2011-08-19

A non-unique textual identifier or moniker for this nation

159

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201301IHE
Patient Activate/Revise

This HMD extract defines the message used toreport that a new patient record was added, or apatient record was updated.
Derived from Figure 3.44.4.1.2-1(PRPA_RM201301IHE)

Organization (ON)
Employee

A relationship of the focal person with an organization to receive
wages or salary. The purpose of this class is to identify the type of
relationship the employee has to the employer rather than the natureof the work actually performed. For example, it can be used tocapture whether the person is a Military Veteran or not..

classCode [1..1] (M)Structural attribute; this is an "employee" role

Employee (CS) {CNE:EMP}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
effectiveTime [0..1]

An interval of time specifying the period during which this
employment relationship is in effect, if such time limit is applicableand known.

Employee (IVL<TS>)
occupationCode [0..1]

A code qualifying the classification of kind-of-work based upon arecognized industry or jurisdictional standard. OccupationCode isused to convey the person's occupation as opposed to jobClassCode(not used in this transaction) which characterizes this particular job.
For example, it can be used to capture whether the person is a
Military Veteran or not.

Employee (CE) {CWE:EmployeeOccupationCode}BirthPlace

The birthplace of the focal living subject.

classCode [1..1] (M)Structural attribute; this is a "birthplace" role.

Birthplace (CS) {CNE:BIRTHPL}
id [0..*]

A living subject's birth place represented by a unique identifier.

hplace (SET<II>)addr [0..*]Patient (BAG<AD>)

A living subject's birth place represented as an address. Note:
Either BirthPlace.addr or an associated Place.name must be valued.

classCode [1..1] (M)Structural attribute; this is a "birthplace" role.

Birthplace (CS) {CNE:BIRTHPL}
LanguageCommunication

A language communication capability of the focal person

languageCode [1..1] (M)A value representing a language for which the focal person has
some level of proficiency for written or spoken communication.
Examples: Spanish, Italian, German, English, American Sign

LanguageCommunication (CE){CWE:HumanLanguage}
preferenceInd [0..1]

An indicator specifying whether or not this language is preferred by
the focal person for the associated mode

LanguageCommunication (BL)Rev. 8.0 Final Text 2011-08-19

160

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

4025

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thetwo interactions, and the associated constraints.
Table 3.44.4.1.2-2 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201301UV02 or PRPA_IN201302UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201301UV02 or
PRPA_TE201302UV02 respectively

The value of processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device

4030

RegistrationEvent.statusCode SHALL be set to“active”
There SHALL be no InReplacementOf act
relationship for these interactions.

The composite message schemas which describe the full payload of these interactions, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the HL7 V3
2008 Normative Edition schemas are at
Edition2008/processable/multicacheschemas/PRPA_IN201301UV02.xsd andEdition2008/processable/multicacheschemas/PRPA_IN201302UV02.xsd).
3.44.4.1.2.4 Web Services Types and Messages
The Patient Registry Record Added/Revised messages will be transmitted using Web Services,
according to the requirements specified in ITI TF-2x: Appendix V.

4035

The following WSDL naming conventions SHALL apply:“add” message-> "PRPA_IN201301UV02_Message"“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:
4040

4045

4050

4055

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201301UV02.xsd"/><xsd:element name="PRPA_IN201301UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201302UV02.xs
d"/>Rev. 8.0 Final Text 2011-08-19

161

Copyright © 2011 IHE International, Inc.

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

4060

4065

4070

4075

4080

<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_IN201301UV02_Message"><part element="hl7:PRPA_IN201301UV02" name="Body"/></message><message name="PRPA_IN201302UV02_Message"><part element="hl7:PRPA_IN201302UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Identity Feed Service are described together
with the expected actions of the actors which receive these messages in sections ITI TF-2b:
3.44.4.1.3 and TF-2b: 3.44.4.1.4.
3.44.4.1.3 Expected Actions – PIX Manager
4085

4090

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes specified
in Table 3.44.4.1.2-1 above. This is to ensure that the Patient Identifier Cross-reference Manager
can handle a sufficient set of corroborating information in order to perform its cross-referencing
function.
The Patient Identifier Cross-reference Manager shall only recognize a single Patient Identity
Source per domain.
The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient
Identifier Cross-reference Manager, but its specification is beyond the scope of IHE.

4095

Once the Patient Identifier Cross-reference Manager has completed its cross-referencing
function, it shall make the newly cross-referenced identifiers available to PIX queries and sendout notification to any Patient Identifier Cross-reference Consumers that have been configured as
being interested in receiving such notifications using the PIX Update Notification HL7 V3transaction (see ITI TF-2b: 3.46 for the details of that transaction).
3.44.4.1.3.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.

Rev. 8.0 Final Text 2011-08-19

162

Copyright © 2011 IHE International, Inc.

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

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"

4105

4110

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
4115

4120

4125

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

4135

4140

4145

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_IN201301UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201301UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PIXManager_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/><input><wsoap12:body use="literal"/></input><output>

Rev. 8.0 Final Text 2011-08-19

163

Copyright © 2011 IHE International, Inc.

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

…

4155

<wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Manager implementing the PIXV3 profile is available online
on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.1.3.2 Message Examples
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

4160

4165

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

4170

4175

4180

The following WSDL naming conventions SHALL apply:

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.
3.44.4.1.3.1.1 Port Type
4185

4190

<portType name="DocumentRegistry_PortType"><operation name="DocumentRegistry_PRPA_IN201301UV02"><input message="tns:PRPA_IN201301UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201301UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation>Rev. 8.0 Final Text 2011-08-19

164

Copyright © 2011 IHE International, Inc.

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

4195<operation name="DocumentRegistry_PRPA_IN201302UV02"><input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7org:v3:PRPA_IN201302UV02"/><output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7org:v3:MCCI_IN000002UV01"/></operation></portType>3.44.4.1.3.1.2 Bindings
4200

4205

4210

4215

4220

4225

SOAP 1.2 binding:…

<binding name="DocumentRegistry_Binding_Soap12"
type="DocumentRegistry_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="DocumentRegistry_PRPA_IN201301UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201301UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="DocumentRegistry_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

An informative WSDL for the Document Registry implementing the XDS.b profile is available
online on the IHE FTP site, see ITI TF-2x: Appendix W.
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.
4230

3.44.4.2 Patient Identity Management – Patient Identity Merge
3.44.4.2.1 Trigger Events
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:

4235

Patient Registry Duplicates Resolved (PRPA_TE201304UV02)

Rev. 8.0 Final Text 2011-08-19

165

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This trigger event signals that duplicate records were resolved in a patient registry.
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.
4240

3.44.4.2.2 Message Semantics
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.

4245

The components of the HL7 Merge Patient message listed below are required, and the detailed
description of the message is provided in Sections ITI TF-2b: 3.44.4.2.2.1 to 3.44.4.2.2.4.
Each message shall be acknowledged by the HL7 v3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.

4250

4255

When two Patient identifiers are to be merged, the subsumed identifier is referenced in theRegistry Trigger Event Control Act Wrapper and the payload is sent for the surviving identifier.
For example, if Patients A, B, and C are all to be merged into Patient B, then two messages aresent. In the first message Patient A’s identifier is referenced in the Registry Trigger EventControl Act Wrapper via the replacementOf act relationship and Patients B’s identifier isreferenced in the Patient class of the payload. In the second message Patient C’s identifier isreferenced in the wrapper, and Patient B’s identifier is, again, in the payload.
The message information model in ITI TF-2b: 3.44.4.2.2.2 describes the relevant data elements
for this transaction. Specific requirements for the particular actors are found in ITI TF-2b:
3.44.4.2.3 Expected Actions.
3.44.4.2.2.1 Major Components of the Patient Registry Duplicates Resolved

4260

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

4265

4270

Provider Organization
The Patient class is scoped by the provider organization which is the assigning authority for thepatient’s identifier. For this message the provider organization class is optional. The HL7
definition of the CMET requires that the provider organization needs to be identified by an id
attribute, and at least one of address, telecommunications address, or contact person to bepresent. The id attribute SHALL have only a root expressed as an ISO OID, and it shall matchthe root of the Patient.id attribute
PersonRev. 8.0 Final Text 2011-08-19

166

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The Person class contains the name for the focal person (similarly to the requirement for the
HL7 v2.x PID segment).
4275

3.44.4.2.2.2 Message Information Model of the Patient Registry Duplicates
Resolved Message
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.

4280

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:
The focal entity choice is restricted to be only a person
All optional classes are removed

4285

4290

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.

Figure 3.44.4.2.2-1

Rev. 8.0 Final Text 2011-08-19

167

Copyright © 2011 IHE International, Inc.

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

The attributes of this model are described in the following table.
Table 3.44.4.2.2-1
PRPA_HD201303IHE
Duplicates Resolved

This HMD extract defines the message used toreport that two patient identifiers were merged (i.e.,a duplicate was resolved).
Derived from Figure 3.44.4.2.2-1(PRPA_RM201303IHE)

Patient

The primary record for the focal person in a Patient Identity SourceclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Identifiers designated by various patient identity sources for the
focal person

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human being
Both Person.name and Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)

3.44.4.2.2.3 Control Act and Transmission Wrappers

4300

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.44.4.2.2-3 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201304UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201304UV02

The value of processingModeCode SHALL be set to T

RegistrationEvent.statusCode SHALL be set to“active”

The acceptAckCode SHALL be set to AL

There SHALL be an InReplacementOf act
relationship

There SHALL be only one receiver Device

The value of PriorRegistration.statusCode SHALL be“obsolete”
There SHALL be a PriorRegisteredRole role
There SHALL be a single PriorRegisteredRole.id
attribute, representing the subsumed patient
identifier.

Rev. 8.0 Final Text 2011-08-19

168

Copyright © 2011 IHE International, Inc.

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

4305

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201304UV02.xsd).
3.44.4.2.2.4 Web Services Types and Messages
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:

4310"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
Acknowledgement-> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:
4315

4320

4325

4330

4335

4340

4345

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201304UV02.xsd"/><xsd:element name="PRPA_IN201304UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…

The messages are described by the following snippet:…
<message name="PRPA_IN201304UV02_Message"><part element="hl7:PRPA_IN201304UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Resolved Duplicates Service are described together
with the expected actions of the actors which receive these messages in ITI TF-2b: 3.44.4.2.3
and 3.44.4.2.4.

Rev. 8.0 Final Text 2011-08-19

169

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.4.2.3 Expected Actions – PIX Manager
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.
4350

4355

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

4360

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"

4365

4370

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

4375

4380

<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
SOAP 1.2 binding:…

4385<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXManager_PRPA_IN201304UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201304UV02"/>
Rev. 8.0 Final Text 2011-08-19

170

Copyright © 2011 IHE International, Inc.

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

4395
…

4400

<input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>

An informative WSDL for the PIX Manager implementing the PIXV3 profile is available online
on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.2.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.44.4.2.4 Expected Actions – Document Registry4405

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

4410

4415

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.

4420

4425

See ITI TF-2a: 3.18.4.1.2.3.8.1 of the Technical Framework for details of how this message typeaffects results of a Stored Query transaction and the end of ITI TF-2a: 3.14.4.1.2.12 to see how it
affects the Register transaction.
A Resolve Duplicates message contains two attributes of interest:• PriorRegistrationRole.id – subsumed patient identifier: the patient identifier which is tobecome obsolete• Patient.id – surviving patient identifier: the patient identifier which is to remain active.
After a duplicate resolution, the Patient.id attribute represents all records formerly represented byeither the Patient.id attribute or the PriorRegistrationRole.id attribute. All other attributes may beignored.

Rev. 8.0 Final Text 2011-08-19

171

Copyright © 2011 IHE International, Inc.

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

4430

4435

4440

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 Register
Document Set [ITI-14] transactions. See ITI TF-2a: 3.14.4.1.2.12 XDS Registry
Adaptor for details.

2.

Multiple merge transactions can form a recorded merge chain, where the Subsumed
identifier of the current merge is the Surviving identifier of a previous merge.

3.

Register Document Set transactions referencing a subsumed identifier are rejected with
an XDSUnknownPatientId error.

4.

Stored Query transactions referencing a subsumed identifier return no content.

5.

Stored Query transactions referencing a surviving identifier successfully match theentire recorded merge chain and return appropriate metadata.

6.

No change in the Registry Query transaction.

4445

4450

4455

Note: This transaction does not specify how the merge is to be implemented. It may or may not change the stored form of
the metadata. It only specifies the observable results from the perspective of the Registry Stored Query
transaction [ITI-18] and the Register Document Set transaction [ITI-14].

3.44.4.2.4.1 Web Services Port Type and Binding Definitions
IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “DocumentRegistry”.
4460

4465

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"

Rev. 8.0 Final Text 2011-08-19

172

Copyright © 2011 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.
4470

4475

4480

3.44.4.2.4.1.1 Port Type<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:
…

4485

4490

4495

4500

<binding name="DocumentRegistry_Binding_Soap12"
type="DocumentRegistry_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="DocumentRegistry_PRPA_IN201304UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201304UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

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.
3.44.5 Security Requirements

4505

4510

This transaction is generally used in profiles that require actors to be grouped with a Secure
Node as defined in the IHE Audit Trail and Node Authentication Integration profile. This use of
the ATNA profile in an XDS Affinity Domain does not require a centralized XDS Affinity
Domain Audit Record Repository.
The use of ATNA along with XDS does require that each member of the XDS Affinity Domain
have audit and security mechanisms in place. See ITI TF-1: Appendix G and ITI-TF-2x:
Appendix K.
Rev. 8.0 Final Text 2011-08-19

173

Copyright © 2011 IHE International, Inc.

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

4520

4525

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.
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.
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 table 3.20.6-1. The following tables show items
that are required to be part of the audit record for this transaction.
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.

4530

3.44.5.1.1 Patient Identity Source audit message
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCodeM“C” (create) , “U” (update), or “D” (delete) as appropriate

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)

Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identity Source Actor) (1)Patient (1)Where:

Rev. 8.0 Final Text 2011-08-19

174

Copyright © 2011 IHE International, Inc.

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

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format (see ITI TF-2x: appendix E)

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)4535
3.44.5.1.2 Patient Identifier Cross-reference Manager audit message
Field Name
Event

Opt

EventID

Rev. 8.0 Final Text 2011-08-19

M

175

Value Constraints
EV(110110, DCM, “Patient Record”)

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
EventActionCodeM“C” (create) , “U” (update), or “D” (delete) as appropriate

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)

Source (Patient Identity Source Actor) (1)Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)Patient(1)Where:
UserIDM
the content of the <wsa:ReplyTo/> element
SourceAuditMessage/
ActiveParticipant

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserID

M

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

Destination
AuditMessage/
ActiveParticipant

4540
Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Rev. 8.0 Final Text 2011-08-19

176

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.44.5.1.3 Document Registry audit message
Document Registry audit message are the same as Patient Identifier Cross-reference Manager
audit message as presented in section ITI TF-2b: 3.44.5.1.2
4545

3.45 PIXV3 Query
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.
4550

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

Actor: Patient Identifier Cross-reference Consumer4555

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)
Actor: Patient Identifier Cross-reference Manager

4560

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)
3.45.3 Referenced Standards

4565

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. 8.0 Final Text 2011-08-19

177

Copyright © 2011 IHE International, Inc.

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

3.9B-1 Get Corresponding Identifiers Sequence

3.45.4.1 Get Corresponding Identifiers
3.45.4.1.1 Trigger Events
4575

A Patient Identifier Cross-reference Consumer’s need to get the patient identifier associated witha domain for which it needs patient related information will trigger the request forcorresponding patient identifiers message based on the following HL7 trigger event:
Patient Registry Get Identifiers Query (PRPA_TE201309UV02)
This query requests all other identifiers associated with a particular person identifier.
3.45.4.1.2 Message Semantics

4580

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.

4585

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. 8.0 Final Text 2011-08-19

178

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
4590
3.45.4.1.2.1 Major Components of the Patient Registry Query by Identifier
PatientIdentifier Parameter

4595

This required parameter specifies the identifier associated with the person whose information is
being queried. For this parameter item, a single patient identifier is specified in thePatientIdentifier.value attribute. Please see Appendix E for the use of the II data type for patient
identifiers.
DataSource Parameter

4600

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
Message4605

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:

4610

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

4615

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. 8.0 Final Text 2011-08-19

179

Copyright © 2011 IHE International, Inc.

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

4620

Figure 3.45.4.1.2-1

The attributes of this model are described in the following table.
Table 3.45.4.1.2-2
PRPA_HD201307IHE
Patient Registry Query by IdentifierThis HMD extract defines the message used toquery a patient registry for a list of identifiers.
Derived from Figure 3.45.4.1.2-1(PRPA_RM201307IHE)

QueryByParameter

The entry point for the domain content in this query

queryId [1..1]
QueryByParameter (II)Unique identifier for the query

statusCode [1..1] (M)QueryByParameter (CS) {CNE:QueryStatusCode,
fixed value="new"}

There are no continuations necessary for this type of query, so thestatus is always "new"responsePriorityCode [1..1]
QueryByParameter (CS) {CNE:QueryPriority, fixedvalue="I"}

The PIX manager is required to send an immediate response.

DataSource

Optional parameter specifying the assigning authority of a PatientRev. 8.0 Final Text 2011-08-19

180

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201307IHE
Patient Registry Query by IdentifierThis HMD extract defines the message used toquery a patient registry for a list of identifiers.
Derived from Figure 3.45.4.1.2-1(PRPA_RM201307IHE)
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"}

4625

4630

4635

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

4640

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

Rev. 8.0 Final Text 2011-08-19

181

Copyright © 2011 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 processingModeCode SHALL be set to T
The acceptAckCode SHALL be set to AL

The value of authroOrPerformer.typeCode SHALL
be set to AUT

There SHALL be only one receiver Device

4645

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201309UV02

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

4650

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"

4655

4660

4665

4670

4675

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:4680…
<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. 8.0 Final Text 2011-08-19

182

Copyright © 2011 IHE International, Inc.

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

The port types for the WSDL describing the Resolved Duplicates Service are described together
with the expected actions of the actors which receive these messages in sections ITI TF-2b:3.45.4.1.3.
3.45.4.1.3 Expected Actions

4690

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes as
specified in Table 3.45.4.1.2-1 above.
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

4695

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXManager":"get identifiers" query-> "PRPA_IN201309UV02_Message""get identifiers" response -> "PRPA_IN201310UV02_Message"
portType-> "PIXManager_PortType"get identifiers operation -> "PIXManager_PRPA_IN201309UV02"
SOAP 1.2 binding-> "PIXManager_Binding_Soap12"
SOAP 1.2 port-> "PIXManager_Port_Soap12"

4700

4705

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

4710

4715

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

4725

…

<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXManager_PRPA_IN201309UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201309UV02"/><input><wsoap12:body use="literal"/></input>

Rev. 8.0 Final Text 2011-08-19

183

Copyright © 2011 IHE International, Inc.

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

4730
…

4735

<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

4740

3.45.4.2.1 Trigger Events
The Patient Identifier Cross-reference Manager’s response to the Get Corresponding Identifiers
message will trigger the following message:
Patient Registry Get Identifiers Query Response (PRPA_TE201310UV02)
This query response returns all other identifiers associated with a particular person identifier.

4745

3.45.4.2.2 Message Semantics
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.

4750

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.

4755

PersonThe Person class contains the name of the patient for additional verification purposes.
Provider Organization

4760

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. 8.0 Final Text 2011-08-19

184

Copyright © 2011 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
4765

4770

The OtherIDs class can optionally be used to capture other identifiers associated with the personsuch as a 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

4775

3.45.4.2.2.2 Message Information Model of the Patient Identifiers 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 Identifiers (PRPA_RM201304UV02) RMIM.

4780

The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201304UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:• The focal entity choice is restricted to be only a person• All optional classes are removed, except for the provider organization, and other identifiers• All optional attributes in the Patient and Person class are removed

4785

Rev. 8.0 Final Text 2011-08-19

185

Copyright © 2011 IHE International, Inc.

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

Figure 3.45.4.2.2-1

The attributes of this model are described in the following table.
4790
Table 3.45.4.2.2-3
PRPA_HD201304IHE
PatientIdentifiersThis HMD extract defines the message used torespond to the Patient Registry Query By Identifier
Derived from Figure 3.45.4.2.2-1(PRPA_RM201304IHE)

Patient

The primary record for the focal person in a Patient Identity CrossReference Manager

classCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Linked patient identifiers from one or more Patient Identity
Domains

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human being
Both Person.name and Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Rev. 8.0 Final Text 2011-08-19

Structural attribute; this is a specific person

186

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201304IHE
PatientIdentifiersThis HMD extract defines the message used torespond to the Patient Registry Query By Identifier
Derived from Figure 3.45.4.2.2-1(PRPA_RM201304IHE)

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role"

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)

3.45.4.2.2.3 Control Act and Transmission Wrappers

4795

Please see ITI TF-2x: Appendix O for details on the IHE guidelines for implementing thewrappers. Table 3.44.4.1.2-2 contains the Transmission and Control Act wrappers used for thisinteraction, and the associated constraints.
Table 3.45.4.4.2-5 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

MFMI_MT700711UV01 – Master File/Registry
Query Response Control Act (Role Subject)

The value of interactionId SHALL be set to
PRPA_IN201310UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN

The value of processingModeCode SHALL be set to T

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201310UV02

The acceptAckCode SHALL be set to NE

There SHALL be zero or one RegistrationEvents
present in this message.

There SHALL be only one receiver Device

If a RegistrationEvent is part of the message, there
SHALL be exactly one Patient role present in the
payload.
There SHALL be no replacementOf act-relationshippresent in this message
There SHALL be a QueryByParameter copy of theoriginal query.

4800

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemafrom the HL7 V3 2008 Normative Edition are at
Edition2008/processable/multicacheschemas/PRPA_IN201310UV02.xsd).
3.45.4.2.2.4 Web Services Types and Messages
Since this is a response to a query, please see ITI TF-2b: 3.45.4.1.2.4 for the web services
components of this message.

Rev. 8.0 Final Text 2011-08-19

187

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.45.4.2.3 Expected Actions - Patient Identifier Cross-reference Manager
4805

4810

4815

4820

4825

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 Appendix E for a detailed description of the use of the II data typefor 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:

4830

4835

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

4840

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).
Case 2: The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sentby the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, there are noRev. 8.0 Final Text 2011-08-19

188

Copyright © 2011 IHE International, Inc.

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

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

4850

4855

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

4860

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

4865

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.

4870

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

4875

VALUE

typeCodeEcode

204 (Unknown Key Identifier)location

XPath expression for the value element of the PatientIdentifier parameter

Case 5: The Patient Identifier Cross-reference Manager does not recognize one or more of thePatient Identification Domains for which an identifier has been requested.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
Rev. 8.0 Final Text 2011-08-19

189

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________No RegistrationEvent is returned.
4880

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

4885

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

4890

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

4895

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

4900

The WSDL snippets for this message are shown in ITI TF-2b: 3.45.4.1.3.1
3.45.4.2.3.2 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.45.4.2.4 Expected Actions - Patient Identifier Cross-reference Consumer

4905

The Patient Identifier Cross-reference Consumer will use the list of patient identifier aliases
provided by the Patient Identifier Cross-reference Manger to perform the functions, for which it
requested the list. The identifiers found in both Patient.id and OtherIDs.id attributes shall beconsidered together to form a complete list of patient identifiers from the different Patient
Identity domains (either requested or available).

Rev. 8.0 Final Text 2011-08-19

190

Copyright © 2011 IHE International, Inc.

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

4910

4915

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.

4920

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 table 3.20.6-1. The following tables show
items that are required to be part of the audit record for this transaction.

4925

3.45.5.1.1 Patient Identifier Cross-reference Consumer audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

Source (Patient Identifier Cross-reference Consumer) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager) (1)Audit Source (Patient Identity Cross-reference Consumer) (1)Patient (0..n)Query Parameters(1)Where:

Rev. 8.0 Final Text 2011-08-19

191

Copyright © 2011 IHE International, Inc.

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

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)Rev. 8.0 Final Text 2011-08-19

192

Copyright © 2011 IHE International, Inc.

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

4930

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

3.45.5.1.2 Patient Identifier Cross-reference Manager audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-45”, “IHE Transactions”, “PIX Query”)

Source (Patient Identifier Cross-reference Manager) (1)Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Manager) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserID

M

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format (see ITI TF-2x: appendix E).

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Rev. 8.0 Final Text 2011-08-19

193

Copyright © 2011 IHE International, Inc.

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

Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)U

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

4935

3.46 PIXV3 Update Notification
This section corresponds to Transaction ITI-46 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-46 is used by the Patient Identifier Cross-reference Consumer andPatient Identifier Cross-reference Manager actors.
4940

3.46.1 Scope
The scope is identical to the scope of transaction ITI-10, described in section ITI TF-2a: 3.10.1.
3.46.2 Use Case Roles
Patient Identifier
Cross-referenceManager

Patient Identifier
Cross-reference
Consumer

PIXV3 Update
Notification

Actor: Patient Identifier Cross-reference Manager
4945

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

4950

Patient Registry Informer (PRPA_AR201301UV02)
Actor: Patient Identifier Cross-reference Consumer
Role: Receives notifications from the Patient Identifier Cross-reference Manager of changes topatient ID aliases. Typically the Patient Identifier Cross-reference Consumer uses thisinformation to maintain information links about patients in a different patient ID domain.
Rev. 8.0 Final Text 2011-08-19

194

Copyright © 2011 IHE International, Inc.

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

Corresponding HL7 v3 Application Roles:
Patient Registry Tracker (PRPA_AR201302UV02)
3.46.3 Referenced Standards
HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at
http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008)

4960

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

Patient Identifier
Cross-Reference
Consumer

Patient Identifier
Cross-ReferenceManager

Patient Registry Record Revised
PRPA_IN201302UV02

3.46-1 Update Patient Information Sequence4965

3.46.4.1 Update Patient Information
3.46.4.1.1 Trigger Events

4970

4975

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)

Rev. 8.0 Final Text 2011-08-19

195

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
This trigger event signals that patient information was revised in a patient registry.
3.46.4.1.2 Message Semantics
4980

The PIX Update Notification transaction is conducted by the Patient Revise(PRPA_MT201302UV02) message. The Patient Identifier Cross-reference Manager initiates thistransaction whenever identifier list information is updated for a patient.
Each message shall be acknowledged by the HL7 V3 Accept Acknowledgement(MCCI_MT000200UV01), which is described in ITI TF-2x: Appendix O.

4985

4990

4995

5000

5005

5010

5015

It is wholly the responsibility of the Patient Identifier Cross-reference Manager to perform thematching of patient identifiers based on the patient traits it receives. The information provided by
the Patient Identifier Cross-reference Manager to Patient Identifier Cross-reference Consumer
Actors shall only contain a list of cross-referenced identifiers for the domains of interest as
configured with the Patient Identifier Cross-reference Manager in two or more of the domains
managed by the Patient Identifier Cross-reference Manager. Multiple notifications may need to
be sent. For example:
Consumer CON_A is configured to receive update notifications for domains DOM_A and
DOM_AD. Notifications are sent as follows:
A PIXV3 Patient Registry Record Add message is sent for a patient for DOM_A. The
update notification shall contain the patient identifier for DOM_A.
A PIXV3 Patient Registry Record Add message is processed for DOM_AD. The Patient
Identifier Cross-reference Manager cross references this patient with DOM_A. The
update notification shall contain the patient identifiers for both DOM_A and
DOM_AD.
A PIXV3 Patient Registry Record Revise message is processed for DOM_AD changing
the patient address. The Patient Identifier Cross-reference Manager cross references
determines this patient is no longer the same patient as DOM_A. Two update
notifications shall be sent. One containing the patient identifier for DOM_A. The
other one containing the patient identifier for DOM_AD.
The list of cross-references is not made available until the set of policies and processes for
managing the cross-reference function have been completed. The policies of administering
identities adopted by the cooperating domains are completely internal to the Patient Identifier
Cross-reference Manager and are outside of the scope of this profile. Possible matches should
not be communicated until the healthcare institution policies and processes embodied in thePatient 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.

Rev. 8.0 Final Text 2011-08-19

196

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Each message shall be acknowledged by the Accept Acknowledgment message sent by thereceiver of the Patient Registry Record Revise message to its sender.
3.46.4.1.2.1 Major Components of the Patient Registry Record Revised
5020

Patient
The Patient class is the entry point to the R-MIM for the Patient Revise(PRPA_RM201302UV02). This is where the updated list of patient identifiers will be present.
PersonThe Person class contains the name of the patient for additional verification purposes.

5025

5030

Provider Organization
The Patient class is optionally scoped by the provider organization where this person is a patient.
The HL7 definition of the CMET requires that the provider organization needs to be identified
by an id attribute, and at least one of address, telecommunications address, or contact person to
be present. The id attribute SHALL have only a root, expressed as an ISO OID, and at least oneof the id attributes of the Patient class SHALL have a matching root component (see ITI TF-2x:
Appendix E on the use of the II data type for patient identifiers).
Other Identifiers

5035

5040

The OtherIDs class can be optionally used to capture other identifiers associated with the personsuch as a 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.46.4.1.2.2 Message Information Model of the Patient Registry Record Revise
Message

5045

5050

Below is the Message Information Model for the Patient Identifiers message, as restricted for thistransaction. The purpose of the model is to describe the data elements relevant for thistransaction. It is a strict subset of the Patient Revise (PRPA_RM201302UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model (note that the resulting model is
identical to the one described in ITI TF-2b: 3.45.4.2.2.2):
The focal entity choice is restricted to be only a person

Rev. 8.0 Final Text 2011-08-19

197

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________All optional classes are removed, except for the provider organization, and otheridentifiers
All optional attributes in the Patient and Person class are removed

5055

Figure 3.46.4.1.2-1

The attributes of this model are described in the following table.
5060

Table 3.46.4.1.2-4
PRPA_HD201302IHE
PatientRevise

This HMD extract defines the message used tosend a Patient Update Notification
Derived from Figure 3.46.4.1.2-1(PRPA_RM201302IHE)

Patient

The primary record for the focal person in a Patient Identity CrossReference Manager

classCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Linked identifiers from one or more Identity Domains

Patient (SET<II>)statusCode [1..1]
Patient (CS) {CNE:active, fixed value= "active"}

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

PersonA subtype of LivingSubject representing a human being
Both Person.name and Patient.id must be non-nullclassCode [1..1] (M)Rev. 8.0 Final Text 2011-08-19

Structural attribute; this is a "person" entity

198

Copyright © 2011 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 tosend a Patient Update Notification
Derived from Figure 3.46.4.1.2-1(PRPA_RM201302IHE)

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role"

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., a Driver’s License number issued by a
DMV)Role (SET<II>)

3.46.4.1.2.3 Control Act and Transmission Wrappers
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.
5065

Table 3.46.4.1.2-6 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry
Notification Control Act, Role Subject

The value of interactionId SHALL be set to
PRPA_IN201302UV02

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201302UV02

The value of processingModeCode SHALL be set to T

RegistrationEvent.statusCode SHALL be set to“active”

The acceptAckCode SHALL be set to AL

There SHALL be no InReplacementOf act
relationship for these interactions.

There SHALL be only one receiver Device

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

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.
The following WSDL naming conventions SHALL apply:

5075“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"Rev. 8.0 Final Text 2011-08-19

199

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
The following WSDL snippet describes the types for these messages:

5080

5085

5090

5095

…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201302UV02.xsd"/><xsd:element name="PRPA_IN201302UV02"/></xsd:schema><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…

The messages are described by the following snippet:

5100

5105

…
<message name="PRPA_IN201302UV02_Message"><part element="hl7:PRPA_IN201302UV02" name="Body"/></message><message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Identity Feed Service are described together
with the expected actions of the actors which receive these messages in section ITI TF-2b:
3.46.4.1.3.
3.46.4.1.3 Expected Actions - Patient Identifier Cross-reference Consumer
5110

5115

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.

5120

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 Cross-Rev. 8.0 Final Text 2011-08-19

200

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
reference Consumers not capable of handling this situation, ignoring the entire list of different
identifiers prevents the consumer from presenting incomplete data.
3.46.4.1.3.1 Web Services Port Type and Binding Definitions
5125

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXConsumer”.
The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXConsumer":PIX update message-> "PRPA_IN201302UV02_Message"
acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "PIXConsumer_PortType"get identifiers operation -> "PIXConsumer_PRPA_IN201302UV02"
SOAP 1.2 binding-> "PIXConsumer_Binding_Soap12"
SOAP 1.2 port-> "PIXConsumer_Port_Soap12"

5130

5135

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

5140

5145

<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
SOAP 1.2 binding:
5150

5155

5160

5165

…

<binding name="PIXConsumer_Binding_Soap12" type="PIXConsumer_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PIXConsumer_PRPA_IN201302UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201302UV02"/><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.

Rev. 8.0 Final Text 2011-08-19

201

Copyright © 2011 IHE International, Inc.

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

5170

5175

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 table 3.20.6-1. The following tables show items
that are required to be part of the audit record for this transaction.
3.46.5.1.1 Patient Identifier Cross-reference Manager audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110110, DCM, “Patient Record”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)

Source (Patient Identifier Cross-reference Manager) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Manager) (1)Patient IDs(1..n) (represents the components of PID-3)
Where:
UserIDM
the content of the <wsa:ReplyTo/> element
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

Rev. 8.0 Final Text 2011-08-19

202

SOAP endpoint URI.

Copyright © 2011 IHE International, Inc.

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

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

5180
Patient IDs(AudittMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format (see ITI TF-2x: appendix E).

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailM

Type=II (the literal string), Value=the value of message.id

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

Source (Patient Identifier Cross-reference Manager) (1)Destination (Patient Identifier Cross-reference Consumer) (1)Audit Source (Patient Identifier Cross-reference Consumer) (1)Patient IDs(1..n) (represents the components of PID-3)

Where:
SourceAuditMessage/
ActiveParticipant

Destination

UserID

M

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserID

M

SOAP endpoint URI.

Rev. 8.0 Final Text 2011-08-19

203

the content of the <wsa:ReplyTo/> element

Copyright © 2011 IHE International, Inc.

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

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

UserNameUnot specialized

UserIsRequestorM“false”

AlternativeUserID

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

5185
Patient IDs(AudittMessage/
ParticipantObjectIdentifi
cation)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

3.47 Patient Demographics Query HL7 V3
5190

This section corresponds to Transaction ITI-47 of the IHE Technical Framework. Transaction
ITI-47 is used by the Patient Demographics Consumer and Patient Demographics Supplieractors. Additional components to be included if the Pediatric Demographics option is supported
are also indicated in ITI TF-2b: 640 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.
3.47.2 Use Case Roles
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient
Demographics
Query HL7 V3

5195

Rev. 8.0 Final Text 2011-08-19

204

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

8 Patient Demographics Query (PDQ)
1540

The Patient Demographics Query Integration Profile (PDQ) provides ways for multiple distributed
applications to query a patient information server for a list of patients, based on user-defined search
criteria, and retrieve a patient’s demographic (and, optionally, visit or visit-related) information
directly into the application.

8.1 Actors/ Transactions
1545

Figure 8.1-1 shows the actors directly involved in the Patient Demographics Query Integration
Profile and the relevant transactions between them. Other actors that may be indirectly involved
due to their participation in Patient ID Cross-referencing, etc. are not necessarily shown.

Patient Demographics
Supplier

Patient
Demographics
Query [ITI-21] ↑↑ Patient Demographics andVisit Query [ITI-22]

Patient Demographics
Consumer

Figure 8.1-1. Patient Demographics Query Profile Actor Diagram

1550

Table 8.1-1 lists the transactions for each actor directly involved in the Patient Demographics Query
Profile. In order to claim support of this Integration Profile, an implementation must perform therequired transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of
options defined by this Integration Profile and that implementations may choose to support is listed
in ITI TF-1: 8.2.

1555
Table 8.1-1. Patient Demographics Query Integration Profile - Actors and Transactions
ActorsTransactions

Optionality

SectionPatient Demographics Consumer

Patient Demographics Query [ITI-21]

R

ITI TF-2a: 3.21

Patient Demographics and Visit Query[ITI-22]OITI TF-2a: 3.22

Patient Demographics Query [ITI-21]

R

ITI TF-2a: 3.21

Patient Demographics and Visit Query[ITI-22]OITI TF-2a: 3.22

Patient Demographics Supplier________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

58

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

8.2 Patient Demographics Query Integration Profile Options
1560

Options that may be selected for this Integration Profile are listed in Table 8.2-1 along with theactors to which they apply. Dependencies between options when applicable are specified in notes.
Table 8.2-1 Patient Demographics Query - Actors and Options
Actor

Options

Vol & Section

Patient Demographics Consumer

Patient Demographics and Visit Query

ITI TF-2a: 3.22

Pediatric Demographics

ITI TF-1: 8.2.2

Patient Demographics and Visit Query

ITI TF-2a: 3.22

Pediatric Demographics

ITI TF-1: 8.2.2

Patient Demographics Supplier8.2.2 Pediatric Demographics
1565

The experience of immunization registries and other public health population databases has shownthat retrieving patient records for an individual person in environments with large proportions ofpediatric records requires additional demographic data.
Information about the mother of the patient or a household telephone number is helpful in retrieving
records in large population databases where data quality may be uneven.

1570

Certain other demographics fields are important to include in the query response as they may be
used by the Patient Demographics Consumer in verifying the identity of the patient, in particular,
they aid in distinguishing records for twins, triplets, and so forth.
Pediatric Demographics makes use of the following six additional demographic fields to aid record
matching in databases with many pediatric records.
Field

Reason for inclusion

Value

Mother’s Maiden Name

Any information about the mother is
helpful in making a match

Helps create true positive matches

Patient Home
TelephoneA telecom helps match into the righthousehold

Helps create true positive matches

Patient Multiple Birth
Indicator

Indicates this person is a multiple twin, triplet, etc.

Helps avoid false positive matches ofmultiplesPatient Birth OrderDistinguishes among those multiples.

Helps avoid false positive matches ofmultiples

Last Update Date/Time,
Last Update Facility

These fields, although not strictly
demographic, can effectively substitutewhen multiple birth indicator and birthorder are not collected. They indirectly
provide visit information. Provider
visits on the same day may likely
indicate two children brought to adoctor together.

Helps avoid false positive matches ofmultiples________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

59

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles
1575

1580

1585

1590

________________________________________________________________________________
Patient Demographics Consumer actors which support the Pediatrics Demographics option will beable to provide Pediatric Demographics query parameter fields in the Patient Demographics Query
transaction [ITI-21], and shall be able to receive and process any values returned for the fields
identified as Pediatric Demographics.
Patient Demographics Supplier actors which support the Pediatrics Demographics option will beable to match on values provided for any Pediatric Demographics fields in the Patient
Demographics Query transaction [ITI-21]. and shall return values, when available, for the fields
identified as Pediatric Demographics.
Pediatric Demographics query parameter fields are:• Mother’s Maiden Name
• Patient Home Telephone
Pediatric Demographics are defined as all of the following:• Mother’s Maiden Name
• Patient Home Telephone• Patient Multiple Birth Indicator• Patient Birth Order• Last Update Date/Time• Last Update Facility

8.3 Patient Demographics Query Process Flow
1595

The Patient Demographics Supplier performs the following functions.
• It receives patient registration and update messages from other systems in the enterprise(e.g., ADT Patient Registration systems), which may or may not represent different Patient
ID Domains. The method in which the Patient Demographics Supplier obtains the updated
patient demographic information is not addressed by this profile.
• It responds to queries for information.

1600

Specific methods for acquiring demographic information are beyond the scope of this Profile. It is aprerequisite that the Patient Demographics Supplier possess current demographic information. One
method by which current demographic information may be obtained is for the Patient Demographic
Supplier to be grouped with another IHE actor, such as Order Filler, that either maintains or
receives such information.

1605

In all cases, the Patient Demographics Supplier receives a Patient Demographics Query or Patient
Demographics and Visit Query request from the Patient Demographics Consumer, and returns
demographics (and, where appropriate, visit) information from the single domain that is associatedwith the application to which the query message is sent. Identifier information may be returned
from multiple or single domains; see the “Using Patient Data Query (PDQ) in a Multi-Domain
Environment” section (ITI TF-2x: Appendix M) for a discussion of the architectural issues
involved.

1610

Use Case 1: Patient Information Entering at Bedside________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

60

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1615

1620

1625

________________________________________________________________________________
An admitted patient is assigned to a bed. The patient may or may not be able to provide
positive ID information. The nurse needs to enter patient identity information into somebedside equipment to establish the relationship of the assigned bed to the patient. The
equipment issues a query for a patient pick list to a patient demographics supplier thatprovides data for a patient pick list. Search criteria entered by the nurse might include one
or more of the following:• Partial or complete patient name (printed on the patient record or told by the patient)• Patient ID (this may be obtained from printed barcode, a bed-side chart, etc.)• Partial ID entry or scan.
• Date of birth / age range• Bed ID
The system returns a list of patients showing the MRN, full name, age, sex, room/bed, andadmit date, and displays the list to the nurse. The nurse then selects the appropriate record toenter the patient identity information into the bedside equipment application.
Use Case 2: Patient Identity Information Entering in Physician Offices

1630

1635

A patient visits a physician office for the first time. The nurse needs to register the patient;in doing so, it is desired to record the patient’s demographic data in the practicemanagement information system (PMIS). The physician office is connected to a hospitalenterprise’s central patient registry. The nurse issues a patient query request to the central
patient registry, with some basic patient demographics data as search criteria. In the returned
patient list, she picks up an appropriate record for the patient, including the hospital’s patientID, to enter into the PMIS. (Note that the PMIS uses a different Patient ID domain than thatof the central patient registry.)
The PMIS uses its own patient identifier, coordinating this identifier with the patient
identifier returned in the pick list (sharing the hospital’s Patient ID Domain) to retrieve
information from the hospital’s clinical repository.
Use Case 3: Patient Demographics Query in an Enterprise with Multiple Patient ID Domains

1640

A lab technician enters some basic demographics data (e.g., patient name) into a lab
application to query a patient demographics supplier to identify a patient for his lab exams.
As the application also needs the patient identifier in another Patient ID Domain in theenterprise for results delivery, the application is configured to receive patient IDs from otherdomains in the query response.

1645________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

61

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Patient Demographics
Consumer

Patient Demographics
Supplier

Patient Demographics Query[ITI-21]
Patient Demographics Response[ITI-21]

Patient Demographics and Visit
Query [ITI-22]

Patient Demographics and Visit
Response [ITI-22]

Figure 8.2-1. Basic Process Flow in Patient Demographics Query Profile

8.3.1 Combined Use of PDQ with Other IHE Workflow Profiles
1650

When the Patient Demographics Supplier Actor is grouped with actors in other IHE profiles that
perform patient information reconciliation activities (e.g., Radiology PIR), the PDQ Supplier Actor
may use the updated information to respond to PDQ Queries. In addition, the Patient Demographics
Query Profile may play an integral workflow role in conjunction with other IHE Profiles.
8.3.2 Supplier Data Configuration

1655

A Patient Demographics Supplier Actor that holds demographic information for a single Patient ID
domain shall provide matches in that domain.

1660

In the case where the Patient Demographics Supplier Actor holds demographic information for
multiple Patient ID domains, the Patient Demographics Supplier Actor shall return information forthe domain associated with MSH-5-Receiving Application and MSH-6-Receiving Facility. See the“Using Patient Data Query (PDQ) in a Multi-Domain Environment” section (ITI TF-2x: AppendixM) for a further discussion of this case and an illustration of the supporting architecture.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

62

Copyright © 2011: IHE International, Inc.

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

3825

3.21 Patient Demographics Query
This section corresponds to Transaction ITI-21 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-21 is used by the Patient Demographics Consumer and Patient
Demographics Supplier actors.
3.21.1 Scope

3830

This transaction involves a request by the Patient Demographics Consumer Actor for information
about patients whose demographic data match data provided in the query message. The request
is received by the Patient Demographics Supplier Actor. The Patient Demographics Supplier
Actor immediately processes the request and returns a response in the form of demographic
information for matching patients.

3835

3.21.2 Use Case Roles
Patient
Demographics
Supplier

Patient
Demographics
Consumer

Patient
Demographics
Query

Actor: Patient Demographics Consumer

3840

Role: Requests a list of patients matching a minimal set of demographic criteria (e.g., ID or
partial name) from the Patient Demographics Supplier. Populates its attributes withdemographic information received from the Patient Demographics Supplier.
Actor: Patient Demographics SupplierRole: Returns demographic information for all patients matching the demographic criteria
provided by the Patient Demographics Consumer.
3.21.3 Referenced Standards

3845

HL7: Version 2.5, Chapter 2 – Control
Version 2.5, Chapter 3 – Patient Administration
Version 2.5, Chapter 5 – Query___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

149

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.4 Interaction Diagram
Patient
Demographics
Consumer

Patient
Demographics
Supplier
Patient Demographics
Query: QBP^Q22
Patient Demographics
Response: RSP^K22

3850

3.21.4.1 Patient Demographics Query
3.21.4.1.1

Trigger Events

A Patient Demographics Consumer’s need to select a patient based on demographic information
about patients whose information matches a minimal set of known data will trigger the Patient
Demographics Query based on the following HL7 trigger event:3855

Q22 – Find Candidates
3.21.4.1.2

3860

Message Semantics

The Patient Demographics Query is conducted by the HL7 QBP^Q22 message. The Patient
Demographics Consumer actor shall generate the query message whenever it needs to selectfrom a list of patients whose information matches a minimal set of demographic data. The
segments of the message listed below are required, and their detailed descriptions are provided in
the following subsections.
Table 3.21-1 QBP Query by Parameter
QBP

Query by Parameter

Chapter in HL7 2.5

MSH

Message Header

2

QPD

Query Parameter Definition

5

RCP

Response Control Parameter

5

[DSC]

Continuation Pointer2

The receiver shall respond to the query by sending the RSP^K22 message. This satisfies therequirements of original mode acknowledgment; no intermediate ACK message is to be sent.
3865

Each Patient Demographics Query request specifies two distinct concepts. The Patient
Demographics Query is always targeted at a single source of patient demographic information(referred to in this Transaction as the patient information source). A Patient Demographics
Supplier may have knowledge of more than one source of demographics. A Patient
Demographics Supplier shall support at least one source of patient demographics and may___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

150

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3870

3875

3880

support multiple sources of demographics. ITI TF-2a: 3.21.4.1.2.1 describes how the Patient
Demographics Consumer specifies which source of demographics are requested by the query.
Each query response shall return demographics from a single patient information source.
The second concept present in the query is the set of patient identifier domains referenced by thequery. These patient identifier domains may or may not be associated with the patient
information source. A Patient Demographics Supplier shall support at least one patient identifier
domain and may support multiple identifier domains. ITI TF-2a: 3.21.4.1.2.2 describes how thePatient Demographics Consumer requests identifiers from one or more patient identifier
domains. Query responses may return patient identifiers from 0, 1 or multiple patient identifier
domains.
3.21.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).

3885

3890

3895

The Patient Demographics Supplier is able to obtain demographics from at least one and possibly
multiple patient information sources. When more than one patient information source isavailable, Field MSH-5-Receiving Application specifies the patient information source that thisquery is targeting. The Patient Demographics Supplier shall return this value in MSH-3-Sending
Application of the RSP^K22 response. The value specified in MSH-5 is not related to the value
requested in QPD-8 What Domains Returned.
A list shall be published of all Receiving Applications that the Patient Demographics Suppliersupports, for the Patient Demographics Consumer to choose from. Each query is processedagainst one and only one source of patient demographic information.
Field MSH-9-Message Type shall have all three components populated with a value. The firstcomponent shall have a value of QBP; the second component shall have a value of Q22. The
third component it shall have a value of QBP_Q21.
3.21.4.1.2.2 QPD Segment
The Patient Demographics Consumer Actor shall send attributes within the QPD segment as
described in Table 3.21-2.
Table 3.21-2. IHE Profile - QPD segment
SEQ LEN DT OPT TBL# ITEM#

3900

1

250

CE

R

2

32

ST

R+

0471

ELEMENT NAME

01375

Message Query Name

00696

Query Tag

3

QIP R

Demographics Fields

8

CX

What Domains ReturnedO

Adapted from the HL7 standard, version 2.5
The Consumer shall specify “IHE PDQ Query” for QPD-1 Message Query Name.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

151

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.4.1.2.2.1

3905

Populating QPD-3-Demographics Fields

Field QPD-3-Demographics Fields consists of one or more repetitions, each of which contains
two components that together contain the name and value of a distinct parameter to the query.
Acceptable segments are PID and PD1.
The first component of each parameter contains the name of an HL7 element in the form@<seg>.<field no>.<component no>.<subcomponent no>
The above format is populated according to common HL7 usage for specifying elements used inquery parameters, as follows:

3910<seg> represents a 3-character segment ID from the HL7 Standard.
<field no> is the number of a field within the segment as shown in the SEQ column of thesegment attribute table for the segment selected.

3915

3920

<component no>, for fields whose data types contain multiple components, shall contain the
cardinal number of the component being valued. For fields whose data types do not containmultiple components, <component no> shall not be valued and its preceding period shall notappear.
<subcomponent no>, for components whose data types contain multiple subcomponents, shallcontain the cardinal number of the subcomponent being valued. For components whose datatypes do not contain multiple subcomponents, <subcomponent no> shall not be valued and its
preceding period shall not appear.
The second subcomponent of each parameter contains the value that is to be matched. If it isdesired to constrain the quality of a match within the bounds of an algorithm known to the
Supplier, the algorithm and constraint values may be specified in Fields QPD-4 through QPD-7.

3925

The Patient Demographics Consumer may specify, and the Patient Demographics Supplier shallsupport, the fields in Table 3.21-3. If the Pediatric Demographics option is supported, thenadditionally, the Patient Demographics Consumer may specify, and the Patient Demographics
Supplier shall support, the fields in Table 3.21-4.
The Patient Demographics Supplier shall return demographic records that reflect the best fit toall of the search criteria.

3930
Table 3.21-3. PDQ Profile – QPD-3 fields required to be supported
FLD

ELEMENT NAME

PID.3

Patient Identifier List

PID.5

Patient Name

PID.7

Date/Time of Birth

PID.8

Administrative Sex

PID.11 Patient Address
PID.18 Patient Account Number___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

152

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Table 3.21-4. PDQ Profile – Additional QPD-3 fields required to be supported if thePediatric Demographic Option is supported
FLD

ELEMENT NAME

PID.6

Mother’s Maiden Name

PID.13 Phone Number - Home

3935
An example of parameter expressions in QPD-3:@PID.5.1.1^SMITH~@PID.8^F

3940

requests all patients whose family name (first subcomponent (data type ST) of the firstcomponent (data type FN) of PID-5-Patient Name (data type XPN)) matches the value ‘SMITH’
and whose sex (PID-8-Sex (data type IS)) matches the value ‘female’.
3.21.4.1.2.2.2

Populating QPD-8-What Domains Returned

As is specified in the discussion of the Find Candidates (Q22) Query in Chapter 3 of the HL7
Standard, field QPD-8 restricts the set of domains for which identifiers are returned in PID-3:
3945

1.

In a multiple-domain environment, QPD-8 may be used to identify one or moredomains of interest to the Patient Demographics Consumer and from which theConsumer wishes to obtain a value for PID-3-Patient Identifier. Note that the patient
information source designated by MSH-5 may or may not be associated with any of thePatient ID Domains listed in QPD-8-What Domains Returned.

3950

2.

If QPD-8 is empty, the Patient Demographics Supplier shall return all Patient IDs
known by the Patient Demographics Supplier for each patient that matches the search
criteria. See Case 1 in ITI TF-2a: 3.21.4.2.2.8 for details on how this information isreturned.

3.

If QPD-8 is specified and the domains are recognized, the Patient Demographics
Supplier shall return the Patient IDs for each patient that matches the search criteria.
See Case 2 in ITI TF-2a: 3.21.4.2.2.8 for details on how this information is returned.

4.

Any domain not recognized by the Patient Demographics Supplier is an error condition.
See Case 3 in ITI TF-2a: 3.21.4.2.2.8 how to handle this condition.

5.

In a single-domain environment, QPD-8 may be ignored by the Patient Demographics
Supplier. The Supplier shall always return the identifier from the Patient ID Domain
known by the Patient Demographics Supplier.

3955

3960

Within field QPD-8, only component 4 (Assigning Authority) shall be valued.
The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. A discussion of how QPD-8 is processed is included in the___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

153

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3965

architectural discussion in the “Using Patient Data Query (PDQ) in a Multi-Domain
Environment” section (ITI TF-2x: Appendix M).
The Patient Demographics Consumer shall be able to support at least one of the following
mechanisms for specifying QPD-8:

3970

1.

Transmit an empty value and receive all identifiers in all domains known by the Patient
Demographics Supplier (one or more domains), or

2.

Transmit a single value and receive zero or more identifiers in a single domain, or

3.

Transmit multiple values and receive multiple identifiers in those multiple domains.

3.21.4.1.2.3 RCP Segment
3975

The Patient Demographics Consumer Actor shall send attributes within the RCP segment as
described in Table 3.21-5. Fields not listed are optional and may be ignored.
Table 3.21-5. IHE Profile - RCP segment
SEQ LEN DT OPT TBL# ITEM#ELEMENT NAME

1

1

ID

R

0091

00027

Query Priority

2

10

CQ O

0126

00031

Quantity Limited Request

Adapted from the HL7 standard, version 2.5
3.21.4.1.2.3.1
3980

Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is tobe returned in Immediate mode.
3.21.4.1.2.3.2

3985

Populating RCP-1-Query Priority

Populating RCP-2-Quantity Limited Request

The Patient Demographics Consumer Actor may request that responses to the query be sent,
using the HL7 Continuation Protocol, in increments of a specified number of patient records. (Inthe context of the HL7 query, a patient record is defined as the PID segment and any segments
accompanying it for each patient.) It is desirable to request an incremental response if the query
could result in hundreds or thousands of matches or “hits.”
The Patient Demographics Supplier Actor shall support the HL7 Continuation Protocol.

3990

Field RCP-2 is of data type CQ, which contains two components. The first component contains
the number of increments, always expressed as an integer greater than 0, while the second
component contains the kind of increment, always RD to signify that incremental replies are
specified in terms of records.
For example, 50^RD requests 50 records at a time.

3995

See the “Incremental Response Processing” (ITI TF-2a: 3.21.4.1.3.3) and the “Expected
Actions” section of the Patient Demographics Query Response message (ITI TF-2a: 3.21.4.2.3)
for more information on the implementation of the continuation protocol.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

154

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.4.1.2.4 DSC Segment

4000

The Patient Demographics Consumer Actor may request additional increments of data by
specifying this segment on the query request. This segment should be omitted on the initial query
request. Its purpose is to request additional increments of the data from the Patient Demographic
Supplier Actor.
Table 3.21-9. IHE Profile - DSC segment4005

3.21.4.1.2.4.1

SEQ

LEN

DT

OPT

1

180

ST

O

2

1

ID

O

TBL#

0398

ITEM
#

ELEMENT NAME

00014

Continuation Pointer

01354

Continuation Style

Populating DSC-1 Continuation PointerTo request additional increments of data, DSC-1 (Continuation Pointer) shall echo the value
from RSP^K22 DSC-1.
4010

3.21.4.1.2.4.2

Populating DSC-2 Continuation Style

DSC-2 (Continuation Style) shall always contain I, signifying that this is part of an interactive
continuation message.

4015

3.21.4.1.3

Expected Actions

3.21.4.1.3.1 Immediate Acknowledgement

4020

The Patient Demographics Supplier shall immediately return an RSP^K22 response message as
specified below in ITI TF-2a: 3.21.4.2, “Patient Demographics Response.” The RSP^K22
response message incorporates original mode application acknowledgment as specified in the“Acknowledgment Modes” section (ITI TF-2x: C.2.3). The Supplier shall use MSH-3-Sending
Application of the RSP^K22 to return the value it received from the Patient Demographics
Consumer in Field MSH-5-Receiving Application of the QBP^Q22 message.
3.21.4.1.3.2 Query Parameter Processing

4025

The Patient Demographics Supplier Actor shall be capable of accepting, searching on, andresponding with attributes in the QPD segment as specified in Table 3.21-2.
The Patient Demographics Supplier Actor must be capable of receiving all possible
representations of an Assigning Authority (patient identifier domain) in QPD.8.4 (What Domain
Returned): 1) namespace, 2) universal id (OID) and 3) both namespace and universal id (OID).
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

155

Copyright © 2011 IHE International,

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

4030

Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented
characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplierrather than by the Patient Demographics Consumer. The Supplier shall return at least all exact
matches to the query parameters sent by the Consumer; IHE does not further specify matchingrequirements.
3.21.4.1.3.3 Incremental Response Processing

4035

4040

The Patient Demographics Supplier Actor shall be capable of accepting and processing attributes
in the RCP segment as listed in Table 3.21-5. In particular, the Patient Demographics Supplier
Actor shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I).
Also, the Patient Demographics Supplier Actor shall be able to interpret RCP-2-Quantity Limited
Request to return successive responses of partial lists of records according to the HL7Continuation Protocol, as described in ITI TF-2a: 3.21.4.2 below and in the HL7 Standard.
3.21.4.2 Patient Demographics Response
3.21.4.2.1

Trigger Events

The Patient Demographics Supplier’s response to the Find Candidates message shall be thefollowing message:4045

K22 – Find Candidates response
3.21.4.2.2

4050

Message Semantics

The Patient Demographics Response is conducted by the RSP^K22 message. The Patient
Demographics Supplier Actor shall generate this message in direct response to the QBP^Q22
message previously received. This message satisfies the Application Level, Original Mode
Acknowledgement for the HL7 QBP^Q22 message.
The segments of the message listed without enclosing square brackets in the Table below arerequired. Detailed descriptions of all segments listed in the table below are provided in thefollowing subsections. Other segments of the message are optional.
Table 3.21-6 RSP Segment Pattern Response
Segment Pattern Response

Chapter in HL7 2.5

MSH

RSP

Message Header

2

MSA

Message Acknowledgement

2[ {ERR} ]

Error

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5[ { PID

Patient Identification

3[ QRI ] } ]Query Response Instance5[ DSC ]

Continuation Pointer2[ PD1 ]___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

156

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
4055

3.21.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).

4060

Field MSH-3-Sending Application specifies the patient information source that processed thequery. The Patient Demographics Supplier shall use Field MSH-3-Sending Application of the
RSP^K22 message to return the value it received from the Patient Demographics Consumer in
Field MSH-5-Receiving Application of the QBP^Q22 message.
Field MSH-9-Message Type shall have all three components populated with a value. The firstcomponent shall have a value of RSP; the second component shall have a value of K22. The
third component shall have a value of RSP_K21.

4065

3.21.4.2.2.2 MSA Segment
The Patient Demographics Supplier Actor is not required to send any attributes within the MSA
segment beyond what is specified in the HL7 standard. See the “Acknowledgment Modes”
section (ITI TF-2x: C.2.3) for the list of all required and optional fields within the MSA segment.
3.21.4.2.2.3 QAK Segment

4070

4075

The Patient Demographics Supplier Actor shall send attributes within the QAK segment as
defined in Table 3.21-7. For the details on filling in QAK-2 (Query Response Status) refer to the“Patient Demographics Supplier Actor Query Response Behavior” section (ITI TF-2b:
3.21.4.2.2.8).
QAK-1 (Query Tag) shall echo the same value of QPD-2 (Query Tag) of the QBP^Q22 message,
to allow the Patient Demographics Query Consumer to match the response to the corresponding
query request.
Table 3.21-7. PDQ Profile - QAK segment
SEQ

LEN

DT

OPT

1

32

ST

R

2

2

ID

R+

TBL#
0208

ITEM#

ELEMENT NAME

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5
4080

3.21.4.2.2.4 QPD Segment
The Patient Demographics Supplier Actor shall echo the QPD Segment value that was sent in the
QBP^Q22 message.
3.21.4.2.2.5 PID Segment

4085

The Patient Demographics Supplier Actor shall return one PID segment group (i.e., one PID
segment plus any segments associated with it in the message syntax shown in Table 3.21-5) for
each matching patient record found. The Supplier shall return the attributes within the PID___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

157

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
segment as specified in Table 3.21-8. In addition, the Patient Demographics Supplier Actor shallreturn all other attributes within the PID segment for which it is able to supply values.
4090

Table 3.21-8. PDQ Profile - PID segment
SEQ LENDT

OPT TBL# ITEM#R

ELEMENT NAME

3250 CX

00106 Patient Identifier List

5

250 XPN R

00108 Patient Name

7

26 TS

R2

00110 Date/Time of Birth

8

1 IS

R2

0001

00111 Administrative Sex

11

250 XAD R200114 Patient Address

18

250 CX

00121 Patient Account Number

R2

Adapted from the HL7 standard, version 2.5
The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. Inability to supply an identifier in a particular domain is not anerror, provided that the domain is recognized.
4095

4100

The PID segment and its associated PD1 and QRI segments are returned only when the Patient
Demographics Supplier Actor is able to associate the search information in QPD-3 with one ormore patient records in the patient information source associated with MSH-5-Receiving
Application. See the “Patient Demographics Supplier Actor Query Response Behavior” section(ITI TF-2a: 3.21.4.2.2.8) for a detailed description of how the Patient Demographics Supplier
Actor responds to the query request under various circumstances.
3.21.4.2.2.6 QRI Segment
For each patient for which the Patient Demographics Supplier Actor returns a PID Segment, it
may optionally return the QRI (Query Response Instance) segment, but is not required to do so.
Refer to the HL7 Standard, Version 2.5, Chapter 5, Section 5.5.5, for more information.

4105

3.21.4.2.2.7 DSC Segment
If the number of records is specified in RCP-2-Quantity Limited Request, the Patient
Demographics Supplier Actor shall return an incremental response of that number of records
when the number of matching records it finds exceeds the number of records specified in RCP-2.

4110

4115

As long as the Patient Demographics Supplier Actor has records to return in addition to those
returned in the incremental response, the Supplier shall return a DSC Segment. The single fieldof the DSC Segment shall contain a unique alphanumeric value (the Continuation Pointer) that
the Patient Demographics Consumer may return in the DSC of the QBP^Q22 message to request
the next increment of responses. The Supplier shall return increments as many times as theConsumer requests them (and there are increments to return), and shall stop when the Consumer
sends a cancel query (QCN^J01) message (or when there are no more increments to return).

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

158

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.4.2.2.8 Patient Demographics Supplier Actor Query Response Behavior

4120

The Patient Demographics Supplier shall perform the matching of patient data based on thequery parameter values it receives. The information provided by the Patient Demographics
Supplier Actor to Patient Demographics Consumer Actors is a list of possible matching patientsfrom the patient information source associated with the value that the Consumer sent in MSH-5Receiving Application of the query message.
If domains are specified in QPD-8-What Domains Returned and are recognized by the Patient
Demographics Supplier, the response will also, for each patient, contain any Patient ID values
found in the specified domains.

4125

The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier Actor and are outside of the scope of this framework.
The Patient Demographics Supplier Actor shall respond to the query request as described by thefollowing 3 cases:

4130

Case 1: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. No patient identifier domains are requested in QPD-8What Domains Returned.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

4135

4140

One PID segment group (i.e., one PID segment plus any segments associated with it in themessage syntax shown in Table 3.21-5) is returned from the patient information source for eachpatient record found. If the Patient Demographics Supplier Actor returns data for multiple
patients, it shall return these data in successive occurrences of the PID segment group.
Within each PID segment, field PID-3-Patient Identifier List contains one or more identifiers
from the set of Patient ID Domains known by the Patient Demographics Supplier.
If an incremental number of records are specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.

4145

4150

The consumer will specify the value of the continuation pointer in the DSC segment on thesubsequent query request to request the next increment of responses.
Case 2: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. One or more patient identifier domains are requested in
QPD-8-What Domains Returned; the Supplier recognizes all the requested domains.
AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

159

Copyright © 2011 IHE International,

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

4155

4160

4165

One PID segment group (i.e., one PID segment plus any segments associated with it in themessage syntax shown in Table 3.21-5) is returned for each matching patient record found. If
the Patient Demographics Supplier Actor returns data for multiple patients, it shall return thesedata in successive occurrences of the PID segment group.
Within each PID segment, field PID-3-Patient Identifier List contains, in successive occurrencesdelimited by the repetition separator, the identifiers from all the Patient ID Domains requested in
QPD-8. In each occurrence of PID-3, component 4 contains the assigning authority value for
one Patient ID Domain, and component 1 contains the Patient ID value in that domain. If an
identifier does not exist for a domain that was specified on QPD-8, nothing is returned in the list.
If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.
The consumer will specify the value of the continuation pointer in the DSC segment on thesubsequent query request to request the next increment of responses.

4170

Case 3: The Patient Demographics Supplier Actor does not recognize one or more of thedomains in QPD-8-What Domains Returned.
AE (application error) is returned in MSA-1 and in QAK-2.
For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.

4175

4180

COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

8

4

Field Repetition(see below)

5Component Number(empty)6

Subcomponent Number(empty)ERR-2.4-Field Repetition identifies the ordinal occurrence of QPD-8 that contained theunrecognized domain. As specified by HL7, ERR-2.5-Component Number and ERR-2.6Subcomponent Number are not valued because we are referring to the entire field QPD-8.
ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Demographics Supplier Actor
did not recognize the domain for QPD-8-What Domains Returned.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

160

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.4.2.3

Expected Actions

The Patient Demographics Consumer will use the demographic information provided by thePatient Demographics Supplier to perform the functions for which it requested the information,e.g., providing a pick list to the user.
4185

4190

4195

If the Supplier has sent a DSC segment containing a continuation pointer value, additional
increments of data are available upon request by the Consumer. After receiving each incrementof data that includes a DSC segment containing a continuation pointer value, the Consumer
should take one of the following actions.
• If the Consumer wishes to receive another increment of the data, the Consumer reissues thequery message using a new unique value in MSH-10-message control ID and adding the DSC
segment after the RCP segment. DSC-1 shall echo the continuation pointer returned in
RSP^K22 DSC-1 segment.
• If the Consumer does not wish to receive another increment of the data, the Consumer issues
a cancel query (QCN^J01) message. The consumer shall echo the query tag from QAK-1 in
QID-1 and the query message name from QPD-1 in QID-2.
• If the Consumer does not reissue the query or send a cancel query message, the query will
eventually terminate.
If the Supplier has not sent a DSC segment containing a continuation pointer value, no moreincrements of data are available and no further action by the Consumer is required.

4205

3.21.4.3 Canceling a query
The Patient Demographic Consumer can send a cancel trigger to notify the Patient Demographic
Supplier that no more incremental responses will be requested, and the interactive query can beterminated. This cancellation trigger is optional. How long the Patient Demographic Supplierretains query results (for incremental response) is an implementation decision and therefore
beyond the scope of IHE.

4210

3.21.4.3.1
Trigger Events
The Patient Demographic Consumer which received a RSP^K22 response message indicating
there are more incremental responses data available, can terminate the interactive query with thefollowing HL7 trigger event:
J01 – Cancel query status4215

3.21.4.3.2
Message Semantics
Canceling a query is conducted by the QCN^J01 message. The Patient Demographic Consumer
can generate this message to notify the Patient Demographic Supplier that no more data isdesired. The segments of the message listed below are required, and their details descriptions areprovided in the following subsections.

4200

Table 3.21.10 QCN Cancel query
QCN
MSH

Cancel query
Message Header

Chapter in HL7 2.5
2___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

161

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
QCN

Cancel query

QID

Query identification Segment

Chapter in HL7 2.55

The receiver shall acknowledge this cancel by the HL7 ACK message. See ITI TF-2x: C.2.3,“Acknowledgement Modes”, for definition and discussion of the ACK message.
4220

4225

3.21.4.3.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).
MSH-9 (Message Type) shall have three components. The first component shall have the valueof QCN; the second component shall have a value of J01. The third component shall have thevalue of QCN_J01.
3.21.4.3.2.2 QID Segment

4230

The QID segment contains the information necessary to uniquely identify the query being
cancelled.
Table 3.21-9. IHE Profile - QID segment
SEQ

4235

LEN

DT

OPT

1

32

ST

R

2

250

CE

R

3.21.4.3.2.2.1

TBL#
0471

ITEM#

ELEMENT NAME

00696

Query Tag

01375

Message Query Name

Populating QID-1 Query Tag

QID-1 (Query Tag) uniquely identifies the query to be canceled. This field shall contain the samevalue specified in QPD-2.
3.21.4.3.2.2.2
4240

Populating QID-2 Message Query Name

QID-2 (Message Query Name) identifies the name of the query. It is an identifier of theconformance statement for this query. This field shall contain the same value specified in QPD1.
3.21.5 Security Considerations

4245

3.21.5.1 Audit Record Considerations
The Patient Demographics Query Transaction is a Query Information event as defined in Table
3.20.6-1. The Actors involved shall record audit events according to the following:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

162

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.21.5.1.1

Patient Demographics Consumer audit message:

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)

UserIDM

The identity of the Patient Demographics Consumer Actor facility andsending application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserIDM

The identity of the Patient Demographics Source facility and receiving
application from the HL7 message; concatenated together, separated by
the | character.

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, as specified in RFC 3881.

Source (Patient Demographics Consumer) (1)
Human Requestor (0..n)
Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Consumer) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

4250
Destination
AuditMessage/
ActiveParticipant___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

163

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)3.21.5.1.2

ParticipantObjectSensitivity

U

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-21”, “IHE Transactions”, “Patient Demographics Query”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

The complete query message (including MSH and QPD segments),
base64 encoded.

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

Patient Demographics Source audit message:

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)

Source (Patient Demographics Consumer) (1)Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Supplier) (1)Patient (0..n)Query Parameters(1)4255

Where:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

164

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Demographics Consumer Actor facility andsending application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Demographics Supplier facility andreceiving application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

The complete query message (including MSH and QPD segments),
base64 encoded.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

165

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

4260___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

166

Copyright © 2011 IHE International,

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

3.22 Patient Demographics and Visit Query
This section corresponds to Transaction ITI-22 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-22 is used by the Patient Demographics Consumer and Patient
Demographics Supplier actors.
4265

3.22.1 Scope

4270

This transaction involves a request by the Patient Demographics Consumer Actor for information
about patients whose demographic and visit data match data provided in the query message. The
request is received by the Patient Demographics Supplier actor. The Patient Demographics
Supplier actor immediately processes the request and returns a response in the form of
demographic and visit information for matching patients.
3.22.2 Use Case Roles
Patient
Demographics
Supplier

Patient
Demographics
Consumer

Patient
Demographics andVisit Query

Actor: Patient Demographics Consumer
4275

Role: Requests a list of patients matching a minimal set of demographic (e.g., ID or partialname) and visit criteria from the Patient Demographics Supplier. Populates its attributes withdemographic and visit information received from the Patient Demographics Supplier.
Actor: Patient Demographics SupplierRole: Returns demographic and visit information for all patients matching the demographic andvisit criteria provided by the Patient Demographics Consumer.

4280

3.22.3 Referenced Standards
HL7: Version 2.5, Chapter 2 – Control
Version 2.5, Chapter 3 – Patient Administration
Version 2.5, Chapter 5 – Query___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

167

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
4285
3.22.4 Interaction Diagram
Patient
Demographics
Consumer

Patient
Demographics
Supplier
Patient Demographics andVisit Query: QBP^ZV1

Patient Demographics andVisit Response: RSP^ZV2

3.22.4.1 Patient Demographics and Visit Query
4290

3.22.4.1.1

Trigger Events

A Patient Demographics Consumer’s need to select a patient based on demographic and visit
information about patients whose information matches a minimal set of known data will trigger
the Patient Demographics and Visit Query based on the following HL7 trigger event:ZV1 – Find Candidates from Visit Information
4295

3.22.4.1.2

Message Semantics

4300

The Patient Demographics and Visit Query transaction is conducted by the HL7 QBP^ZV1
message. The Patient Demographics Consumer actor shall generate the query message wheneverit needs to select from a list of patients whose information matches a minimal set of demographic
and visit data. The segments of the message listed below are required, and their detailed
descriptions are provided in the following subsections.
Table 3.22-1 QBP Query by Parameter
QBP

Query by Parameter

Chapter in HL7 2.5

MSH

Message Header

2

QPD

Query Parameter Definition

5

RCP

Response Control Parameter

5

[DSC]

Continuation Pointer2

The receiver shall respond to the query by sending the RSP^ZV2 message. This satisfies therequirements of original mode acknowledgment; no intermediate ACK message is to be sent.
4305

Each Patient Demographics and Visit Query request specifies two distinct concepts. The Patient
Demographics and Visit Query is always targeted at a single source of patient demographic___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

168

Copyright © 2011 IHE International,

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

4310

4315

information (referred to in this Transaction as the patient information source). A Patient
Demographics Supplier may have knowledge of more than one source of demographics. A
Patient Demographics Supplier shall support at least one source of patient demographics andmay support multiple sources of demographics. ITI TF-2a: 3.21.4.1.2.1 describes how the Patient
Demographics Consumer specifies which source of demographics are requested by the query.
Each query response shall return demographics from a single patient information source.
The second concept present in the query is the set of patient identifier domains referenced by thequery. These patient identifier domains may or may not be associated with the patient
information source. A Patient Demographics Supplier shall support at least one patient identifier
domain and may support multiple identifier domains. ITI TF-2a: 3.21.4.1.2.2 describes how thePatient Demographics Consumer requests identifiers from one or more patient identifier
domains. Query responses may return patient identifiers from 0, 1 or multiple patient identifier
domains.
3.22.4.1.2.1 MSH Segment

4320

4325

4330

The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).
The Patient Demographics Supplier is able to obtain demographics from at least one and possibly
multiple patient information sources. When more than one patient information source isavailable, Field MSH-5-Receiving Application specifies the patient information source that thisquery is targeting. The Patient Demographics Supplier shall return this value in MSH-3-Sending
Application of the RSP^ZV2 response. The value specified in MSH-5 is not related to the value
requested in QPD-8 What Domains Returned.
A list shall be published of all Receiving Applications that the Patient Demographics Suppliersupports, for the Patient Demographics Consumer to choose from. Each query is processedagainst one and only one source of patient demographic information.
Field MSH-9-Message Type shall have all three components populated with a value. The firstcomponent shall have a value of QBP; the second component shall have a value of ZV1. The
third component shall have a value of QBP_Q21.
3.22.4.1.2.2 QPD Segment

4335

The Patient Demographics Consumer Actor shall send attributes within the QPD segment as
described in Table 3.22-2.
Table 3.22-2 PDQ Profile - QPD segment
SEQ LEN DT OPT TBL# ITEM#
1

250

CE

R

2

32

ST

R+

0471

ELEMENT NAME

01375

Message Query Name

00696

Query Tag

3

QIP R

Demographics and Visit Fields

8

CX

What Domains ReturnedO

Adapted from the HL7 standard, version 2.5___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

169

Copyright © 2011 IHE International,

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

4340

The Consumer shall specify “IHE PDVQ Query” for QPD-1 Message Query Name.
3.22.4.1.2.2.1

4345

Parameters in QPD-3-Demographics and Visit-Related Fields

Field QPD-3-Demographics and Visit-Related Fields consists of one or more repetitions, each ofwhich contains two components that together contain the name and value of a distinct parameterto the query. Acceptable segments are PID, PD1, PV1, and PV2.
The first component of each parameter contains the name of an HL7 element in the form@<seg>.<field no>.<component no>.<subcomponent no>
The above format is populated according to common HL7 usage for specifying elements used inquery parameters, as follows:

4350<seg> represents a 3-character segment ID from the HL7 Standard.
<field no> is the number of a field within the segment as shown in the SEQ column of thesegment attribute table for the segment selected.

4355

4360

<component no>, for fields whose data types contain multiple components, shall contain the
cardinal number of the component being valued. For fields whose data types do not containmultiple components, <component no> shall not be valued and its preceding period should notappear.
<subcomponent no>, for components whose data types contain multiple subcomponents, shallcontain the cardinal number of the subcomponent being valued. For components whose datatypes do not contain multiple subcomponents, <subcomponent no> shall not be valued and its
preceding period shall not appear.
The second subcomponent of each parameter contains the value that is to be matched. If it isdesired to constrain the quality of a match within the bounds of an algorithm known to the
Supplier, the algorithm and constraint values may be specified in Fields QPD-4 through QPD-7.

4365

The Patient Demographics Consumer may specify, and the Patient Demographics Supplier shallsupport, the fields in Table 3.22-3. If the Pediatric Demographics option is supported, thenadditionally, the Patient Demographics Consumer may specify, and the Patient Demographics
Supplier shall support, the fields in Table 3.22-4.
Table 3.22-3 PDQ Profile – QPD-3 fields required to be supported
FLD

ELEMENT NAME

PID.3

Patient Identifier List

PID.5

Patient Name

PID.7

Date/Time of Birth

PID.8

Administrative Sex

PID.11 Patient Address___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

170

Copyright © 2011 IHE International,

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

ELEMENT NAME

PID.18 Patient Account Number

4370

Table 3.22-4 PDQ Profile – QPD-3 fields required to be additionally supported if Pediatric
Demographics is supported
FLD

ELEMENT NAME

PID.6

Mother’s Maiden Name

PID.13 Phone Number - Home

4375

In addition, the Patient Demographics Supplier should support the fields in the following table,
and it shall support at least one of them. Some fields may not be relevant to particular caresettings (e.g., inpatient, day patient) and will thus not be supportable by domains in those caresettings.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

171

Copyright © 2011 IHE International,

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

4380

Table 3-22.4 PDQ Profile – QPD-3 fields recommended to be supported
FLD

ELEMENT NAME

PV1.2

Patient Class

PV1.3

Assigned Patient Location

PV1.7

Attending Doctor

PV1.8

Referring Doctor

PV1.9

Consulting Doctor

PV1.10 Hospital Service
PV1.17 Admitting Doctor
PV1.19 Visit Number

The Patient Demographics Supplier shall return demographic records that reflect the best fit toall of the search criteria.
Examples of parameter expressions in QPD-3:
4385@PID.5.1.1^SMITH~@PID.8^F

requests all patients whose family name (first subcomponent (data type ST) of the firstcomponent (data type FN) of PID-5-Patient Name (data type XPN)) matches the value ‘SMITH’
and whose sex (PID-8-Sex (data type IS)) matches the value ‘female’.
4390@PV1.3.2^389~@PV1.3.3^2

requests all patients whose room number (second component (data type IS) of PV1-3-Assigned
Patient Location (data type PL)) matches the value 389 and whose bed number (third component(data type IS) of PV1-3-Assigned Patient Location (data type PL)) matches the value 2.
4395

3.22.4.1.2.2.2

Populating QPD-8-What Domains Returned

As in the Patient Demographics Query (Transaction ITI-21), field QPD-8 restricts the set of
domains for which identifiers are returned in PID-3:
1.

In a multiple-domain environment, QPD-8 may be used to identify one or moredomains of interest to the Patient Demographics Consumer and from which theConsumer wishes to obtain a value for PID-3-Patient Identifier. Note that the patient
information source designated by MSH-5 may or may not be associated with any of thePatient ID Domains listed in QPD-8-What Domains Returned.

2.

If QPD-8 is empty, the Patient Demographics Supplier shall return all Patient IDs
known by the Patient Demographics Supplier for each patient that matches the search
criteria. See Case 1 in ITI TF-2a: 3.21.4.2.2.8 for details on how this information isreturned.

4400

4405

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

172

Copyright © 2011 IHE International,

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

4410

4415

3.

If QPD-8 is specified and the domains are recognized, the Patient Demographics
Supplier shall return the Patient IDs for each patient that matches the search criteria.
See Case 2 in ITI TF-2a: 3.21.4.2.2.8 for details on how this information is returned.

4.

Any domain not recognized by the Patient Demographics Supplier is an error condition.
See Case 3 in ITI TF-2a: 3.21.4.2.2.8 how to handle this condition.

5.

In a single-domain environment, QPD-8 may be ignored by the Patient Demographics
Supplier. The Supplier shall always return the identifier from the Patient ID Domain
known by the Patient Demographics Supplier.

Within field QPD-8, only component 4 (Assigning Authority) shall be valued.
The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. A discussion of how QPD-8 is processed is included in thearchitectural discussion in the “Using Patient Data Query (PDQ) in a Multi-Domain
Environment” section (ITI TF-2x: Appendix M).

4420

4425

The Patient Demographics Consumer shall be able to support at least one of the following
mechanisms for specifying QPD-8:
1.

Transmit an empty value and receive all identifiers in all domains known by the Patient
Demographics Supplier (one or more domains), or

2.

Transmit a single value and receive zero or more identifiers in a single domain, or

3.

Transmit multiple values and receive multiple identifiers in those multiple domains.

3.22.4.1.2.3 RCP Segment
The Patient Demographics Consumer Actor shall send attributes within the RCP segment as
described in Table 3.22-5. Fields not listed are optional.
Table 3.22-5 IHE Profile - RCP segment
SEQ LEN DT OPT TBL# ITEM#

4430

ELEMENT NAME

1

1

ID

R

0091

00027

Query Priority

2

10

CQ O

0126

00031

Quantity Limited Request

Adapted from the HL7 standard, version 2.5
3.22.4.1.2.3.1

Populating RCP-1-Query Priority

Field RCP-1-Query Priority shall always contain I, signifying that the response to the query is tobe returned in Immediate mode.
3.22.4.1.2.3.2
4435

Populating RCP-2-Quantity Limited Request

The Patient Demographics Consumer Actor may request that responses to the query be sent,
using the HL7 Continuation Protocol, in increments of a specified number of patient records. (Inthe context of the HL7 query, a patient record is defined as the PID segment and any segments___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

173

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
accompanying it for each patient.) It is desirable to request an incremental response if the query
could result in hundreds or thousands of matches or “hits.”
4440

The Patient Demographics Supplier Actor shall support the HL7 Continuation Protocol.
Field RCP-2 is of data type CQ, which contains two components. The first component contains
the number of increments, always expressed as an integer greater than 0, while the second
component contains the kind of increment, always RD to signify that incremental replies are
specified in terms of records.

4445

For example, 50^RD requests 50 records at a time.
See the “Incremental Response Processing” section (ITI TF-2a: 3.22.4.1.3.3) and the “Expected
Actions” section of the Patient Demographics Query Response message (ITI TF-2a: 3.22.4.2.3)
for more information on the implementation of the continuation protocol.
3.22.4.1.2.4 DSC Segment

4450

The Patient Demographics Consumer Actor may request additional increments of data by
specifying this segment on the query request. This segment should be omitted on the initial query
request. Its purpose is to request additional increments of the data from the Patient Demographic
Supplier Actor.

4455

Table 3.22-9 IHE Profile - DSC segment

4460

SEQ

LEN

DT

OPT

1

180

ST

O

2

1

ID

O

TBL#
0398

ITEM#

ELEMENT NAME

00014

Continuation Pointer

01354

Continuation Style

3.22.4.1.2.4.1
Populating DSC-1 Continuation PointerTo request additional increments of data, DSC-1 (Continuation Pointer) shall echo the value
from RSP^K22 DSC-1.
3.22.4.1.2.4.2
Populating DSC-2 Continuation Style
DSC-2 (Continuation Style) shall always contain “I”, signifying that this is part of an interactive
continuation message.

4465

3.22.4.1.3

Expected Actions

3.22.4.1.3.1 Immediate Acknowledgement
The Patient Demographics Supplier shall immediately return an RSP^ZV2 response message as
specified below in ITI TF-2a: 3.22.4.2, “Patient Demographics Response.” The RSP^ZV2
response message incorporates original mode application acknowledgment as specified in the___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

174

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
4470“Acknowledgment Modes” section (ITI TF-2x: C.2.3). The Supplier shall use Field MSH-3Sending Application of the RSP^ZV2 message to return the value it received from the Patient
Demographics Consumer in Field MSH-5-Receiving Application of the QBP^ZV1 message.
3.22.4.1.3.2 Query Parameter Processing

4475

The Patient Demographics Supplier Actor shall be capable of accepting, searching on, andresponding with attributes in the QPD segment as specified in Table 3.22-2.
The Patient Demographics Supplier Actor must be capable of receiving all valid combinations of
subcomponents that make up the Assigning Authority component (i.e., all valid combinations of
QPD-3.8).

4480

Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented
characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplierrather than by the Patient Demographics Consumer. The Supplier shall return at least all exact
matches to the query parameters sent by the Consumer; IHE does not further specify matchingrequirements.
3.22.4.1.3.3 Incremental Response Processing

4485

4490

The Patient Demographics Supplier Actor shall be capable of accepting and processing attributes
in the RCP segment as listed in Table 3.22-5. In particular, the Patient Demographics Supplier
Actor shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I).
Also, the Patient Demographics Supplier Actor shall be able to interpret RCP-2-Quantity Limited
Request to return successive responses of partial lists of records according to the HL7Continuation Protocol, as described in ITI TF-2a: 3.22.4.2 below and in the HL7 Standard.
3.22.4.2 Patient Demographics and Visit Response
3.22.4.2.1

Trigger Events

The Patient Demographics Supplier’s response to the Find Candidates with Visit Information
message shall be the following message:4495

ZV2 – Find Candidates with Visit Information response
3.22.4.2.2

4500

Message Semantics

The Patient Demographics and Visit Response transaction is conducted by the RSP^ZV2
message. The Patient Demographics Supplier Actor shall generate this message in direct
response to the QBP^ZV1 message previously received. This message satisfies the Application
Level, Original Mode Acknowledgement for the HL7 QBP^ZV1 message.
The segments of the message listed without enclosing square brackets in Table 3.22-6 arerequired. Detailed descriptions of all segments listed in the table below are provided in thefollowing subsections. Other segments of the message are optional.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

175

Copyright © 2011 IHE International,

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

4505

Table 3.22-6 RSP Segment Pattern Response
RSP

Segment Pattern Response

Chapter in HL7 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2[ {ERR} ]

Error

2

QAK

Query Acknowledgement

5

QPD

Query Parameter Definition

5[ { PID

Patient Identification

3[ PD1 ]

Additional Patient Demographics

3

PV1

Patient Visit

3[ PV2 ]

Patient Visit – Additional Information

3[ QRI ] } ]Query Response Instance5[ DSC ]

Continuation Pointer2

3.22.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).
4510

4515

Field MSH-3-Sending Application specifies the patient information source that processed thequery. The Patient Demographics Supplier shall use Field MSH-3-Sending Application of the
RSP^ZV2 message to return the value it received from the Patient Demographics Consumer in
Field MSH-5-Receiving Application of the QBP^Q22 message.
Field MSH-9-Message Type shall have all three components populated with a value. The firstcomponent shall have a value of RSP; the second component shall have a value of ZV2. The
third component shall have a value of RSP_ZV2.
3.22.4.2.2.2 MSA Segment

4520

The Patient Demographics Supplier Actor is not required to send any attributes within the MSA
segment beyond what is specified in the HL7 standard. See the “Acknowledgment Modes”
section (ITI TF-2x: C.2.3) for the list of all required and optional fields within the MSA segment.
3.22.4.2.2.3 QAK Segment

4525

The Patient Demographics Supplier Actor shall send attributes within the QAK segment as
defined in table 3.22-7. For the details on filling in QAK-2 (Query Response Status) refer to the“Patient Demographics Supplier Actor Query Response Behavior” section (ITI TF-2a:3.22.4.2.2.11).
QAK-1 (Query Tag) shall echo the same value of QPD-2 (Query Tag) of the QBP^Q22 message,
to allow the Patient Demographics Query Consumer to match the response to the corresponding
query request.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

176

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Table 3.22-7 IHE Profile - QAK segment
SEQ LEN DT OPT TBL# ITEM#

4530

1

32 ST

R

2

2 ID

R+

0208

ELEMENT NAME

00696

Query Tag

00708

Query Response Status

Adapted from the HL7 standard, version 2.5
3.22.4.2.2.4 QPD Segment
The Patient Demographics Supplier Actor shall echo the QPD Segment value that was sent in the
QBP^ZV1 message.
3.22.4.2.2.5 PID Segment

4535

4540

The Patient Demographics Supplier Actor shall return one PID segment group (i.e., one PID
segment plus any segments associated with it in the message syntax shown in Table 3.22-6) for
each matching patient record found. The Supplier shall return the attributes within the PID
segment as specified in Table 3.22-8. If the Pediatric Demographics option is supported, thenadditionally, the Supplier shall return the attributes within the PID segment as specified in Table
3.22-9. In addition, the Patient Demographics Supplier Actor shall return all other attributes
within the PID segment for which it is able to supply values.
Table 3.22-8 PDQ Profile - PID segment
SEQ LENDT

OPT TBL# ITEM#R

ELEMENT NAME

3250 CX

00106 Patient Identifier List

5

250 XPN R

00108 Patient Name

7

26 TS

R2

00110 Date/Time of Birth

8

1 IS

R2

0001

00111 Administrative Sex

11

250 XAD R200114 Patient Address

18

250 CX

00121 Patient Account Number

R2

Table 3.22-9 PDQ Profile, Pediatric Demographics Option - PID segment
SEQ LEN

4545

DT

OPT TBL# ITEM#

6250 XPN R2

13250 XTN R2

ELEMENT NAME

00109 Mother’s Maiden Name
00116 Phone Number - Home

24

1 ID

R2

0136

00127 Multiple Birth Indicator

25

2 NM

R2

00128 Birth Order (within live
births)

33

26 TS

R2

01537 Last Update Date/Time34

241 HD

R2

01538 Last Update Facility

Adapted from the HL7 standard, version 2.5___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

177

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________The Patient Demographics Supplier may or may not be able to supply additional identifiers fromthe domains specified in QPD-8. Inability to supply an identifier in a particular domain is not anerror, provided that the domain is recognized.
4550

4555

The PID segment and the PD1, PV1, PV2, and QRI segments that are associated with it are
returned only when the Patient Demographics Supplier Actor is able to associate the search
information in QPD-3 with one or more patient records in the patient information source
associated with MSH-5-Receiving Application. See the “Patient Demographics Supplier Actor
Query Response Behavior” section (ITI TF-2a: 3.22.4.2.2.11) for a detailed description of how
the Patient Demographics Supplier Actor responds to the query request under various
circumstances.
3.22.4.2.2.6 PD1 Segment
For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the PD1 (Patient Additional Demographics) segment, but is not required to
do so.

4560

3.22.4.2.2.7 PV1 Segment
For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
shall also return a PV1 Segment in which attributes are populated as specified in Table 3.22-9.
In addition, the Patient Demographics Supplier Actor shall return all other attributes within thePV1 segment for which it is able to supply values.

4565
Table 3.22-9 PDQ Profile – PV1 segment
SEQ LENDT

OPT TBL# ITEM#

1 IS

R

3

80 PL

R2

7

250 XCN R20010

00137 Attending Doctor

8

250 XCN R20010

00138 Referring Doctor

9250 XCN R20010

00139 Consulting Doctor

R2

0069

00140 Hospital Service

17

250 XCN R20010

00147 Admitting Doctor

19

250 CX

10

3 IS

0004

ELEMENT NAME

200132 Patient Class
00133 Assigned Patient Location

R200149 Visit Number

Adapted from the HL7 standard, version 2.5
3.22.4.2.2.8 PV2 Segment
4570

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the PV2 (Patient Visit – Additional Information) segment, but is not
required to do so.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

178

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.22.4.2.2.9 QRI Segment4575

For each patient for which the Patient Demographics Supplier Actor returns a PID segment, it
may optionally return the QRI (Query Response Instance) segment, but is not required to do so.
Refer to the HL7 Standard, Version 2.5, Chapter 5, Section 5.5.5, for more information.
3.22.4.2.2.10 DSC Segment
If a number of records is specified in RCP-2-Quantity Limited Request, the Patient
Demographics Supplier Actor shall return an incremental response of that number of records
when the number of matching records it finds exceeds the number of records specified in RCP-2.

4580

4585

As long as the Patient Demographics Supplier Actor has records to return in additional to those
returned in the incremental response, the Supplier shall return a DSC Segment. The single fieldof the DSC Segment shall contain a unique alphanumeric value (the Continuation Pointer) that
the Patient Demographics Consumer may return in the DSC segment of the QBP^ZV1 message
to request the next increment of responses. The Supplier shall return increments as many times
as the Consumer requests them (and there are increments to return), and shall stop when theConsumer sends a cancel query (QCN^J01) message (or when there are no more increments toreturn). The Supplier shall signal no more increments by omitting the DSC segment.
3.22.4.2.2.11 Patient Demographics Supplier Actor Query Response Behavior

4590

4595

The Patient Demographics Supplier shall perform the matching of patient data based on thequery parameter values it receives. The information provided by the Patient Demographics
Supplier Actor to Patient Demographics Consumer Actors is a list of possible matching patientsfrom the patient information source associated with the value that the Consumer sent in MSH-5Receiving Application of the query message.
If domains are specified in QPD-8-What Domains Returned and are recognized by the Patient
Demographics Supplier, the response will also, for each patient, contain any Patient ID values
found in the specified domains.
The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier Actor and are outside of the scope of this framework.

4600

The Patient Demographics Supplier Actor shall respond to the query request as described by thefollowing 3 cases:
Case 1: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. No patient identifier domains are requested in QPD-8What Domains Returned.

4605

AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.
One PID-PV1 segment group (i.e., one PID segment and one PV1 segment, plus any segments
associated with them in the message syntax shown in Table 3.22-6) is returned from the patient___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

179

Copyright © 2011 IHE International,

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

4610

information source for each patient record found. If the Patient Demographics Supplier Actor
returns data for multiple patients, it shall return these data in successive occurrences of the PIDPV1 segment group.
Within each PID segment, field PID-3-Patient Identifier List contains one or more identifiers
from the set of Patient ID Domains known by the Patient Demographics Supplier.

4615

If an incremental number of records are specified in RCP-2-Quantity Limited Request, and thenumber of records found exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.
The consumer will specify the value of the continuation pointer in the DSC segment on thesubsequent query request to request the next increment of responses.

4620
Case 2: The Patient Demographics Supplier Actor finds (in the patient information source
associated with MSH-5-Receiving Application) at least one patient record matching the criteria
sent in QPD-3-Demographics Fields. One or more patient identifier domains are requested in
QPD-8-What Domains Returned; the Supplier recognizes all the requested domains.
4625

AA (application accept) is returned in MSA-1.
OK (data found, no errors) is returned in QAK-2.

4630

One PID-PV1 segment group (i.e., one PID and one PV1 segment plus any segments associatedwith them in the message syntax shown in Table 3.22-6) is returned for each matching patient
record found. If the Patient Demographics Supplier Actor returns data for multiple patients, it
shall return these data in successive occurrences of the PID segment group.

4635

Within each PID segment, field PID-3-Patient Identifier List contains, in successive occurrencesdelimited by the repetition separator, the identifiers from all the Patient ID Domains requested in
QPD-8. In each occurrence of PID-3, component 4 contains the assigning authority value for
one Patient ID Domain, and component 1 contains the Patient ID value in that domain. If an
identifier does not exist for a domain that was specified on QPD-8, nothing is returned in the list.
If an incremental number of records is specified in RCP-2-Quantity Limited Request, and thenumber of records to be sent exceeds that incremental number, the Supplier returns only theincremental number of records, followed by a DSC segment containing a uniquely valued
Continuation Pointer.

4640

The consumer will specify the value of the continuation pointer in the DSC segment on thesubsequent query request to request the next increment of responses.
Case 3: The Patient Demographics Supplier Actor does not recognize one or more of thedomains in QPD-8-What Domains Returned.

4645

AE (application error) is returned in MSA-1 and in QAK-2.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

180

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________For each domain that was not recognized, an ERR segment is returned in which the components
of ERR-2-Error Location are valued as follows.

4650

COMP #COMPONENT NAME

VALUE

1

Segment ID

QPD

2Sequence

1

3

Field Position

8

4

Field Repetition(see below)

5Component Number(empty)6

Subcomponent Number(empty)ERR-2.4-Field Repetition identifies the ordinal occurrence of QPD-8 that contained theunrecognized domain. As specified by HL7, ERR-2.5-Component Number and ERR-2.6Subcomponent Number are not valued because we are referring to the entire field QPD-8.
ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier).
Together with the values in ERR-2, this signifies that the Patient Demographics Supplier Actor
did not recognize the domain for QPD-8-What Domains Returned.

4655

3.22.4.2.3

Expected Actions

The Patient Demographics Consumer will use the demographic information provided by thePatient Demographics Supplier to perform the functions for which it requested the information,e.g., providing a pick list to the user.
4660

4665

4670

If the Supplier has sent a DSC segment containing a continuation pointer value, additional
increments of data are available upon request by the Consumer. After receiving each incrementof data that includes a DSC segment containing a continuation pointer value, the Consumer
should take one of the following actions.
• If the Consumer wishes to receive another increment of the data, the Consumer reissues thequery message using a new unique value in MSH-10-message control ID and adding the DSC
segment after the RCP segment. DSC-1 shall echo the continuation pointer returned in
RSP^K22 DSC-1 segment.
• If the Consumer does not wish to receive another increment of the data, the Consumer issues
a cancel query (QCN^J01) message.
• If the Consumer does not reissue the query or send a cancel query message, the query will
eventually terminate.
If the Supplier has not sent a DSC segment containing a continuation pointer value, no moreincrements of data are available and no further action by the Consumer is required.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

181

Copyright © 2011 IHE International,

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

4675

4680

4685

4690

3.22.4.3 Canceling a query
The Patient Demographic Consumer can send a cancel trigger to notify the Patient Demographic
Supplier that no more incremental response will be requested, and interactive query can beterminated. This cancellation trigger is optional. How long the Patient Demographic Supplierretains query results (for incremental response) is an implementation decision and therefore
beyond the scope of IHE.
3.22.4.3.1
Trigger Events
The Patient Demographic Consumer which received a RSP^K22 response message indicating
there more incremental response data available, can terminate the interactive query with thefollowing HL7 trigger event:
J01 – Cancel query status
3.22.4.3.2
Message Semantics
Canceling a query is conducted by the QCN^J01 message. The Patient Demographic Consumer
can generate this message to notify the Patient Demographic Supplier that no more data isdesired. The segments of the message listed below are required, and their details descriptions areprovided in the following subsections.
Table 3.22-10 QCN Cancel query
QCN

4695

4700

4705

Cancel query

Chapter in HL7 2.5

MSH

Message Header

2

QID

Query identification Segment

5

The receiver shall acknowledge this cancel by the HL7 ACK message. See ITI TF-2x: C.2.3,“Acknowledgement Modes”, for definition and discussion of the ACK message.
3.22.4.3.2.1 MSH Segment
The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2x:
C.2.2).
MSH-9 (Message Type) shall have three components. The first component shall have the valueof QCN; the second component shall have a value of J01. The third component shall have thevalue of QCN_J01.
3.22.4.3.2.2 QID Segment
The QID segment contains the information necessary to uniquely identify the query being
cancelled.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

182

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
4710

Table 3.22-11 IHE Profile - QID segment
SEQ

LEN

DT

OPT

1

32

ST

R

2

250

CE

R

TBL#

0471

ITEM#

ELEMENT NAME

00696

Query Tag

01375

Message Query Name

3.22.4.3.2.2.1
Populating QID-1 Query Tag
QID-1 (Query Tag) uniquely identifies the query to be canceled. This field shall contain the samevalue specified in QPD-2.
4715

3.22.4.3.2.2.2
Populating QID-2 Message Query Name
QID-2 (Message Query Name) identifies the name of the query. It is an identifier of theconformance statement for this query. This field shall contain the same value specified in QPD1.
3.22.5 Security Considerations

4720

3.22.5.1 Audit Record Considerations
The Patient Demographics Query Transaction is a Query Information event as defined in Table
3.20.6-1. The Actors involved shall record audit events according to the following:
3.22.5.1.1
Event
AuditMessage/
EventIdentification

Patient Demographics Consumer audit message:
Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-22”, “IHE Transactions”, “Patient Demographics and Visit
Query”)

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:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

183

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
SourceAuditMessage/
ActiveParticipant

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

UserIDM

The identity of the Patient Demographics Consumer Actor facility andsending application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserIDM

The identity of the Patient Demographics Source facility and receiving
application from the HL7 message; concatenated together, separated by
the | character.

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, as specified in RFC 3881.

4725
Destination
AuditMessage/
ActiveParticipant

Audit Source

AuditSourceIDU

Not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)

Patient(AudittMessage/
ParticipantObjectIdentifi
cation)Query___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

184

Copyright © 2011 IHE International,

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

3.22.5.1.2

ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-22”, “IHE Transactions”, “Patient Demographics and Visit
Query”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QPD segment of the query - Base64 encoded

ParticipantObjectDetailM

Type=MSH-10 (the literal string), Value=the value of MSH-10 (fromthe message content, base64 encoded)

Patient Demographics Source audit message:

Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-22”, “IHE Transactions”, “Patient Demographics and Visit
Query”)

UserIDM

The identity of the Patient Demographics Consumer Actor facility andsending application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

Source (Patient Demographics Consumer) (1)Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Supplier) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

The identity of the Patient Demographics Supplier facility andreceiving application from the HL7 message; concatenated together,
separated by the | character.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

4730
Destination
AuditMessage/
ActiveParticipant___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

185

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

24 Patient Demographics Query HL7 V3 (PDQV3)
4470

The Patient Demographics Query HL7 V3 Integration Profile (PDQV3) provides ways for multiple
distributed applications to query a patient information server for a list of patients, based on userdefined search criteria, and retrieve a patient’s demographic information directly into theapplication. The discussion and use cases in ITI TF-1: 8 fully apply here, with the obvious
adjustments to the referenced transactions.

24.1 Actors/Transactions
4475

The actors in this profile are the same as the actors defined in the PDQ profile (ITI TF-1: 8.1).
Table 24.1-1. Patient Demographics Query HL7 V3 Integration Profile - Actors andTransactions
ActorsTransactions

Optionality

SectionPatient Demographics Consumer

Patient Demographics Query HL7 V3R

ITI TF-2b: 3.47

Patient Demographics Supplier

Patient Demographics Query HL7 V3R

ITI TF-2b: 3.47

4480

The transaction in this profile directly corresponds to one of the transactions used in the PDQ
profile (ITI TF-1: 8) and provide the identical functionality. Table 24.1-2 describes thiscorrespondence. Note that unlike the PDQ profile there is no transaction which corresponds to thePatient Demographics and Visit query (ITI-22).

4485

Table 24.1-2 Transactions Correspondence between the PDQ and PDQV3 profiles
Transactions in PDQ

Section in
VolumeTransactions in PDQV3

Section in
VolumePatient Demographics Query [ITI-21]

ITI TF-2: 3.21

Patient Demographics Query HL7 V3 [ITI47]

ITI TF-2b: 3.47

24.2 Patient Demographics Query HL7 V3 Integration Profile Options

4490

Options that may be selected for this Integration Profile are listed in the Table 24.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified in notes.
Table 24.2-1 Patient Demographics Query HL7 V3 - Actors and Options
Actor
Patient Demographics Consumer

Options

Vol & Section

Continuation Option

ITI TF-1: 24.2.2

Pediatric Demographics
Patient Demographics SupplierContinuation Option

ITI TF-1: 24.2.2

Pediatric Demographics________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

175

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4495________________________________________________________________________________
Support of continuations is described in transaction ITI-47. This option allows the Patient
Demographics Consumer to get the full set of responses in several increments, as opposed to in one
single response.
24.2.1 Continuation
Support of continuations is described in transaction ITI-47. This option allows the Patient
Demographics Consumer to get the full set of responses in several increments, as opposed to in one
single response.

4500

24.2.2 Pediatric Demographics Option
The experience of immunization registries and other public health population databases has shownthat matching and linking patient records from different sources for the same individual person inenvironments with large proportions of pediatric records requires additional demographic data.

4505

4510

In particular, distinguishing records for children who are twins, triplets, etc. – that is, avoiding false
positive matches - may be difficult because much of the demographic data for the two individuals
matches. For instance, twin children may have identical last names, parents, addresses, and dates ofbirth; their first names may be very similar, possibly differing by only one letter. It can be very
difficult for a computer or even a human being to determine in this situation whether the slight firstname difference points to two distinct individuals or just a typographical error in one of the records.
Additional information is extremely helpful in making this determination.
Pediatric Demographics makes use of the following six additional demographic fields to aid record
matching in databases with many pediatric records.

Field

Reason for inclusion

Value

Mother’s Maiden Name

Any information about the mother is
helpful in making a match

Helps create true positive matches

Patient Home
TelephoneA telecom helps match into the righthousehold

Helps create true positive matches

Patient Multiple Birth
Indicator

Indicates this person is a multiple – twin,
triplet, etc.

Helps avoid false positive matches ofmultiplesPatient Birth OrderDistinguishes among those multiples.

Helps avoid false positive matches ofmultiples

Last Update
Date/Time, Last
Update Facility

These fields, although not strictly
demographic, can effectively substitutewhen multiple birth indicator and birthorder are not collected. They indirectly
provide visit information. Provider visitson the same day may likely indicate twochildren brought to a doctor together.

Helps avoid false positive matches ofmultiples________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

176

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
4515

4520

Patient Identity Source actors which support the Pediatric Demographics option are required tosupport the Patient Identity Management [ITI-30] transaction and shall provide values, whenavailable, for the fields identified as Pediatric Demographics fields.
Patient Identifier Cross-reference Manager actors which support the Pediatric Demographics option
are required to support the Patient Identity Management [ITI-30] transaction, and if values for one
or more of the Pediatric Demographics fields are specified in the Patient Identity Management [ITI30], they shall be considered as part of the matching algorithm of the PIX Manager.

4525

Pediatric Demographics are defined as all of the following:•
Mother’s Maiden Name•
Patient Home Telephone•
Patient Multiple Birth Indicator•
Patient Birth Order•
Last Update Date/Time•
Last Update Facility

4530

24.3 Patient Demographics Query HL7 V3 Process FlowITI TF-1: 8.3 describes use cases that this profile addresses. Figure 8.3-1 also applies to this profile
with the changes to the corresponding PDQV3 transactions as specified in Table 24.1-2, andomitting transaction ITI-22, which has no correspondence in this profile.
24.3.1 Combined Use of PDQV3 with other IHE Workflow Profiles

4535

In addition to the discussion in ITI TF-1: 8.3.1, the use of web services as the transport in thetransactions in this profile makes it well suited in cases where other web services-based profiles areused, like XDS.b and PIXV3.
24.3.2 Supplier Data Configuration

4540

4545

The Patient Demographics Supplier provides demographics information about possible matches tothe parameters of the query. As described in ITI TF-2x: Appendix M, while it is possible for the
supplier to have demographics information from multiple domains, only a single set of
demographics shall be returned by the supplier.
If the supplier holds information for a single Patient ID domain, it shall provide the demographics
information from that domain. In the case where the supplier holds demographics information frommultiple Patient ID domains, the determination of which set of information to return must be basedon the ID values for the Receiver’s Device and Organization classes of the query transmission
wrapper (the equivalent of MSH-5 and MSH-6 in the HL7 Version 2.5 corresponding message).

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

177

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

24.4 Intentionally left blank4550

24.5 Security Considerations
The implementer of this profile is advised that many risks cannot be mitigated by the IHE profile
and instead the responsibility for mitigation is transferred to the vendor, and occasionally to theoperational environment.
In order to address identified security risks:

4555

•

All actors in PDQV3 should be grouped with a Consistent Time (CT) Profile - Time Client
actor. This grouping will assure that all systems have a consistent time clock to assure a
consistent timestamp for audit logging.

•

All actors in PDQV3 should be grouped with an Audit Trail and Node Authentication(ATNA) profile - Secure Node actor or ATNA Secure Application actor. This grouping willassure that only highly trusted systems can communicate and that all changes are recorded in
the audit log.

•

All actors in PDQV3 should be grouped with an XUA X-Service User or X-Service
Provider actor as appropriate. This grouping will enable service side access control andmore detailed audit logging.

•

All actors in PDQV3 should be grouped with the appropriate actor from the Enterprise User
Authentication (EUA) profile to enable single sign-on inside an enterprise by facilitating one
name per user for participating devices and software.

4560

4565

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

178

Copyright © 2011: IHE International, Inc.

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

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

UserNameUnot specialized

UserIsRequestorM“false”

AlternativeUserID

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

5185
Patient IDs(AudittMessage/
ParticipantObjectIdentifi
cation)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

3.47 Patient Demographics Query HL7 V3
5190

This section corresponds to Transaction ITI-47 of the IHE Technical Framework. Transaction
ITI-47 is used by the Patient Demographics Consumer and Patient Demographics Supplieractors. Additional components to be included if the Pediatric Demographics option is supported
are also indicated in ITI TF-2b: 640 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.
3.47.2 Use Case Roles
Patient
Demographics
Consumer

Patient
Demographics
Supplier

Patient
Demographics
Query HL7 V3

5195

Rev. 8.0 Final Text 2011-08-19

204

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Actor: Patient Demographics Consumer
Role: Requests a list of patients matching a minimal set of demographic criteria (e.g., ID or
partial name) from the Patient Demographics Supplier. Populates its attributes withdemographic information received from the Patient Demographics Supplier.
5200

Corresponding HL7 v3 Application Roles:
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.

5205

Corresponding HL7 v3 Application Roles:
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)

5210

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

Rev. 8.0 Final Text 2011-08-19

205

Copyright © 2011 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
5215

Figure 3.46.4-1 Find Candidates Query

3.47.4.1 Patient Demographics Query
3.47.4.1.1 Trigger Events

5220

A Patient Demographics Consumer’s need to select a patient based on demographic information
about patients whose information matches a set of known data will trigger the Patient
Demographics Query based on the following HL7 trigger event:Find Candidates Query (PRPA_TE201305UV02)
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.

5225

3.47.4.1.2 Message Semantics
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. 8.0 Final Text 2011-08-19

206

Copyright © 2011 IHE International, Inc.

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

The components of the Patient Registry Query by Demographics message with cardinality
greater than 0 (as shown below) are required, and the detailed description of the message isprovided in ITI TF-2b: 3.47.4.1.2.1 to 3.47.4.1.2.4. Additional components to be included if thePediatric Demographics option is supported are also indicated in ITI TF-2b: 3.47.4.1.2.1 to3.47.4.1.2.4.

5235

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.

5240

3.47.4.1.2.1 Major Components of the Patient Registry Query by Demographics
LivingSubjectName Parameter

5245

5250

5255

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

5260

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

5265

PatientAddress Parameter
This optional parameter specifies one or more addresses associated with the person whose
information is being queried.
LivingSubjectId Parameter

Rev. 8.0 Final Text 2011-08-19

207

Copyright © 2011 IHE International, Inc.

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

5270

This optional repeating parameter specifies an identifier associated with the patient whose
information is being queried (e.g., a local identifier, or an account identifier). If multiple
instances of this parameter are provided in the query, all of the associated identifiers must match.
The identifier specified in the LivingSubjectId.value attribute is expressed using the II data type.
Please see Appendix E for the use of the II data type for patient identifiers.
OtherIDsScopingOrganization Parameter

5275

5280

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

5285

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

5290

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

5295

MothersMaidenName Parameter

5300

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
This optional parameter specifies the primary telephone number or email address of the person
whose information is being queried.

Rev. 8.0 Final Text 2011-08-19

208

Copyright © 2011 IHE International, Inc.

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

5310

5315

5320

5325

5330

5335

3.47.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. 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. 8.0 Final Text 2011-08-19

209

Copyright © 2011 IHE International, Inc.

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

5340

Figure 3.47.4.1.2-1

The attributes of this model are described in the following table:
Table 3.47.4.1.2-1
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)

QueryByParameter

The entry point for the domain content in this query

queryId [1..1]
QueryByParameter (II)Unique identifier for the query

statusCode [1..1] (M)QueryByParameter (CS) {CNE:QueryStatusCode,default="new"}

The status of the query, default is "new"responseModalityCode [1..1]
QueryByParameter (CS) {CNE:ResponseModality,
fixed value="R"}

The mode of the response – always real-time.

responsePriorityCode [1..1]
QueryByParameter (CS) {CNE:QueryPriority, fixedvalue="I"}

The Patient Demographics Supplier is required to send an
immediate response.

initialQuantity [0..1]
QueryByParameter (INT)

Defines the maximum size of the response that can be
accepted by the requesting application

initialQuantityCode [0..1]
QueryByParameter (CE){CWE:QueryRequestLimit, default="RD"}Defines the units associated with the initialQuantity; default is"records".

Rev. 8.0 Final Text 2011-08-19

210

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)

MatchAlgorithm

This parameter conveys instructions to the patient demographics
supplier specifying the preferred matching algorithm to use

value [1..1]
ParameterItem (ST)The name of the algorithm

semanticsText [1..1]
ParameterItem (ST){default= "MatchAlgorithm"}
MinimumDegreeMatch

This parameter conveys instructions to the patient demographics
supplier specifying minimum degree of match to use in filteringresultsvalue [1..1]
ParameterItem (INT)The numeric value of the degree of match

semanticsText [1..1]
ParameterItem (ST){default= "MatchAlgorithm"}
This query parameter is a code representing the administrative
gender of a person in a patient registry.

LivingSubjectAdministrativeGender
value [1..1]
ParameterItem (CE) {CWE:AdministrativeGender}
semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.administrativeGender"}LivingSubjectBirthTime

This query parameter is the birth date of a living subject.

value [1..1]
ParameterItem (IVL<TS>)

A date or date range. This parameter can convey an exact moment(e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g.,January 1960), or even a range of dates (e.g., December 1, 1959
through March 31, 1960).

semanticsText [1..1]
ParameterItem (ST){default="LivingSubject.birthTime"}
LivingSubjectId
value [1..1] (M)ParameterItem (II)A patient identifier, used to assist in finding a match for the query.

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.id"}
LivingSubjectName

This query parameter is the name of a person. If multiple instancesof LivingSubjectName are provided, the receiver must consider
them as possible alternatives, logically connected with an "or".

value [1..1]
ParameterItem (PN)

The name "use" attribute can convey that a name is to be matchedusing "fuzzy" matching, and does not require exact match. Onlysome of the name parts may be populated. If, for example, only afamily name part of a person's name is sent, then the query would
match all persons with that family name regardless of their given
names or initials.

semanticsText [1..1]
ParameterItem (ST){default= "LivingSubject.name"}
This query parameter is a postal address for corresponding with a

PatientAddress

Rev. 8.0 Final Text 2011-08-19

211

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201306IHE
Patient Registry Query by Demographics

This HMD extract defines the message used toquery a patient registry for records matching a setof demographics information.
Derived from Figure 3.47.4.1.2-1(PRPA_RM201306IHE)
patient

value [1..1]
ParameterItem (AD)semanticsText [1..1]
ParameterItem (ST){default= "Patient.addr"}
OtherIDsScopingOrganization

Optional parameter specifying the assigning authority of a Patient
Identity Domain

value [1..1]
ParameterItem (II)The identifier for a Patient Identity Domain's assigning authority.
IHE restriction:
The value.root attribute SHALL be a valid ISO OID
The value.extension attribute SHALL NOT be present

semanticsText [1..1]
ParameterItem (ST){default="OtherIDs.scopingOrganization.id"}5345

When Patient Demographics option is supported, the following sections may be included.
MothersMaidenName

Design Comments: This query parameter is the maiden name of a
focal person's mother. It is included as a parameter because it is acommon attribute for confirming the identity of persons in someregistries. This parameter does not map to a single RIM attribute,instead, in RIM terms Mother's maiden name is the person namepart of "family" with an EntityNamePartQualifier of "birth" for the
person who is the player in a PersonalRelationship of type of"mother" to the focal person.

value [1..1]

Design Comments: A person name. In this case it may consist of
only the given name part, the family name part, or both.

ParameterItem (PN)
semanticsText [1..1]
ParameterItem (ST){default="Person.MothersMaidenName"}
PatientTelecom

Design Comments: This query parameter is a telecommunications
address for communicating with a living subject in the context ofthe target patient registry. It could be a telephone number, fax
number or even an email address.

value [1..1]

Design Comments: A telecommunications address. The scheme
attribute specifies whether this is a telephone number, fax number,email address, etc.

ParameterItem (TEL)

3.47.4.1.2.3 Control Act and Transmission Wrappers
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.
5350

Table 3.47.4.1.2-7 Wrappers and Constraints
Transmission Wrapper

Rev. 8.0 Final Text 2011-08-19

Trigger Event Control Act Wrapper

212

Copyright © 2011 IHE International, Inc.

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

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

QUQI_MT021001UV01 – Query Control Act
Request: Query By Parameter

The value of interactionId SHALL be set to
PRPA_IN201305UV02

The value of ControlActProcess.moodCode SHALL
be set to EVN

The value of processingModeCode SHALL be set to T

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE201305UV02

The acceptAckCode SHALL be set to AL

If an authorOrPerformer participation is present, thevalue of authroOrPerformer.typeCode SHALL be set
to AUT

There SHALL be only one receiver Device

The composite message schemas which describe the full payload of this interaction, including
the wrappers, can be found online on the IHE FTP site, see ITI TF-2x: Appendix W (the schemas
from the HL7 V3 2008 Normative Edition can be found at
Edition2008/processable/multicacheschemas/PRPA_IN201305UV02.xsd)
5355

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.
The following WSDL naming conventions SHALL apply:
query message

5360

5365

5370

-> "PRPA_IN201305UV02_Message"

The following WSDL snippet describes the type for this message:…
<types><xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"><!-- Include the message schema --><xsd:import namespace="urn:hl7-org:v3"
schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201305UV02.xsd"/><xsd:element name="PRPA_IN201305UV02"/></xsd:schema></types>…

The message is described by the following snippet:
5375

5380

…
<message name="PRPA_IN201305UV02_Message"><part element="hl7:PRPA_IN201305UV02" name="Body"/></message>…

The port types for the WSDL describing the Patient Demographics Service are described
together with the expected actions of the actors which receive these messages in section ITI TF2b: 3.47.4.2.3.

Rev. 8.0 Final Text 2011-08-19

213

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.47.4.1.3 Expected Actions
3.47.4.1.3.1 Immediate Response
5385

The Patient Demographics Supplier shall immediately return a Find Candidates Response
message as specified below in ITI TF-2b: 3.47.4.2. The response message uses the Application
Acknowledgement transmission wrapper, as specified in ITI TF-2x: Appendix O.1.3, and noother acknowledgments are part of this transaction.
3.47.4.1.3.2 Query Parameter Processing

5390

The Patient Demographics Supplier shall be capable of accepting, searching on, and responding
with attributes in the Query Person by Demographics message.

5395

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

5400

Also, the Patient Demographics Supplier shall be able to interpret
QueryByParameter.initialQuantity to return successive responses of partial lists of records.
When processing incremental responses, the Patient Demographics Consumer shall request
additional responses using the Query Control Act Request Continue/Cancel message(QUQI_MT000001UV01), as described in ITI TF-2b: 3.47.4.3.

5405

3.47.4.1.3.4 Web Services Port Type and Binding Definitions
These definitions are part of the query response message. Please see ITI TF-2b: 3.47.4.2.3 formore information.
3.47.4.1.3.5 Message Examples
Message examples can be found online on the IHE FTP site, see ITI TF-2x: Appendix W.

5410

3.47.4.2 Patient Demographics Query Response
3.47.4.2.1 Trigger Events
The Patient Demographics Supplier’s response to the Find Candidates Query message istriggered by the following trigger:
Find Candidates Response (PRPA_TE201306UV02)

Rev. 8.0 Final Text 2011-08-19

214

Copyright © 2011 IHE International, Inc.

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

An application returns a Patient Registry Find Candidates Response message populated withinformation it holds for each person whose record matches the demographic information sent asparameters in a query-by-parameter message.
3.47.4.2.2 Message Semantics

5420

5425

The Patient Registry Find Candidates Response message (PRPA_MT201310UV02) is sent by
the Patient Demographics Supplier in direct response to the query (PRPA_MT201306UV02) or,
if the Continuation Option is supported, the query continuation (QUQI_MT000001UV01)
message previously received. The components of the message with cardinality greater than 0 (asshown below) are required, and the detailed description of the message is provided in ITI TF-2b:
3.47.4.2.2.1 to 3.47.4.2.2.4. All other attributes of the message are optional.
3.47.4.2.2.1 Major Components of the Patient Registry Find Candidates Response
Message
This message shares all the major components of the Patient Activate/Revise messages, as
described in ITI TF-2b: 3.44.4.1.2.1. The only additional component is theQueryMatchObservation class.

5430

Query Match Observation
The QueryMatchObservation class is used to convey information about the quality of the matchfor each record returned by the query response.
3.47.4.2.2.2 Message Information Model of the Patient Registry Find Candidates
Response Message

5435

5440

5445

5450

Below is the Message Information Model for the Patient Registry Find Candidates Response
message, as restricted for this transaction. The purpose of the model is to describe the data
elements relevant for this transaction. It is a strict common subset of the Patient Registry Find
Candidates Response (PRPA_RM201310UV02) RMIM.
The base RMIM can be found on the HL7 V3 2008 Edition CD at
Edition2008/domains/uvpa/editable/PRPA_RM201310UV.htm. The following restrictions weremade on the original RMIMs to arrive at the restricted model:• The focal entity choice is restricted to be only a person• The relationship holder of the personal relationship is restricted to be a person (using CMET
COCT_MT030207UV)• The following roles are omitted:• asPatientOfOtherProvider• birthPlace• guarantor• guardian• contactParty• asMember
Rev. 8.0 Final Text 2011-08-19

215

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________•
5455• careGiver• asStudent
The following participations are omitted:• subjectOf (administrativeObservation)• coveredPartyOf (coverage)

Figure 3.47.4.2.2-1

5460

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.47.4.2.2-8
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

Rev. 8.0 Final Text 2011-08-19

216

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

Patient

The primary record for the focal person in a Patient Demographics
SupplierclassCode [1..1] (M)Structural attribute; this is a "patient" role

Patient (CS) {CNE:PAT}
id [1..*] (M)Patient identifiers. Patient Identifiers from different Identity
Domains may be contained either here, or in the OtherIDs.id
attributes, but not in both places. At least one Patient Identifier shallbe present in this attribute

Patient (SET<II>)statusCode [1..1]

A value specifying the state of this record in a patient registry(based on the RIM role class state-machine). This record is active.

Patient (CS) {CNE:active, fixed value= "active"}
confidentialityCode [0..*]

Value(s) that control the disclosure of information about this living
subject as a patient

Patient (SET<CE>) {CWE:Confidentiality}
veryImportantPersonCode [0..1]
Patient (CE) {CWE:PatientImportance}

A code specifying the patient's special status granted by the scoperorganization, often resulting in preferred treatment and special
considerations. Examples include board member, diplomat.

PersonA subtype of LivingSubject representing a human being
Either Person.name or Patient.id must be non-nullclassCode [1..1] (M)Structural attribute; this is a "person" entity

Person (CS) {CNE:PSN, fixed value= "PSN"}
determinerCode [1..1] (M)Structural attribute; this is a specific person

Person (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
name [1..*]Name(s) for this person

Person (BAG<PN>)
telecom [0..*]

Telecommunication address(es) for communicating with this person

Person (BAG<TEL>)
administrativeGenderCode [0..1]

A value representing the gender (sex) of this person. Note: this
attribute does not include terms related to clinical gender which is acomplex physiological, genetic and sociological concept that
requires multiple observations in order to be comprehensively
described.

Person (CE) {CWE:AdministrativeGender}

birthTime [0..1]

The date and time this person was born

Person (TS)deceasedInd [0..1]

An indication that this person is dead

Person (BL)deceasedTime [0..1]

The date and time this person died

Person (TS)multipleBirthInd [0..1]

An indication that this person was part of a multiple birth

Person (BL)multipleBirthOrderNumber [0..1]

The order in which this person was born if part of a multiple birth

Person (INT)

Rev. 8.0 Final Text 2011-08-19

217

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

addr [0..*]Address(es) for corresponding with this person

Person (BAG<AD>)maritalStatusCode [0..1]

A value representing the domestic partnership status of this person

Person (CE) {CWE:MaritalStatus}
religiousAffiliationCode [0..1]

A value representing the primary religious preference of this person

Person (CE) {CWE:ReligiousAffiliation}
raceCode [0..*]A set of values representing the races of this person

Person (SET<CE>) {CWE:Race}ethnicGroupCode [0..*]A set of values representing the ethnic groups of this person

Person (SET<CE>) {CWE:Ethnicity}
OtherIDs

Used to capture additional identifiers for the person such as a
Drivers’ license or Social Security Number.

classCode [1..1] (M)Structural attribute. This can be any specialization of "role" except
for Citizen, or Employee.,

Role (CS) {CNE:ROL}
id [1..*] (M)One or more identifiers issued to the focal person by the associatedscopingOrganization (e.g., identifiers from a different Patient
Identity Domain).

Role (SET<II>)
PersonalRelationship

A personal relationship between the focal living subject and anotherliving subject

classCode [1..1] (M)Structural attribute; this is a "personal relationship" role

Role (CS) {CNE:PRS, fixed value= "PRS"}
id [0..*]

Identifier(s) for this personal relationshipRole (SET<II>)code [1..1] (M)Role (CE) {CWE:PersonalRelationshipRoleType}A required value specifying the type of personal relationshipbetween the relationshipHolder and the scoping living subject
drawn from the PersonalRelationshipRoleType domain, forexample, spouse, parent, unrelated friend

CitizenUsed to capture person information relating to citizenship.

classCode [1..1] (M)Structural attribute; this is a "citizen" role

Role (CS) {CNE:CIT, fixed value= "CIT"}
id [0..*]

Identifier(s) for the focal person as a citizen of a nationRole (SET<II>)
NationA politically organized body of people bonded by territory andknown as a nation.

classCode [1..1] (M)Structural attribute; this is a 'nation' type of entity

Organization (CS) {CNE:NAT, fixed value= "NAT"}
determinerCode [1..1] (M)Structural attribute; this is a specific entity

Organization (CS) {CNE:INSTANCE, fixed value="INSTANCE"}
code [1..1] (M)Rev. 8.0 Final Text 2011-08-19

A value that identifies a nation state

218

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
PRPA_HD201310IHE
Patient Registry Find Candidates
Response

This HMD extract defines the message used toreturn records from a patient registry in response
to a Find Candidates Query.
Derived from Figure 3.47.4.2.2-1(PRPA_RM201310IHE)

Organization (CD) {CWE:NationEntityType}name [0..1]

A non-unique textual identifier or moniker for this nation

Organization (ON)
Employee

A relationship of the focal person with an organization to receive
wages or salary. The purpose of this class is to identify the type of
relationship the employee has to the employer rather than the natureof the work actually performed. For example, it can be used tocapture whether the person is a Military Veteran or not..

classCode [1..1] (M)Structural attribute; this is an "employee" role

Employee (CS) {CNE:EMP}
statusCode [0..1]

A value specifying the state of this employment relationship (basedon the RIM Role class state-machine), for example, active,
suspended, terminated.

Employee (CS) {CNE:RoleStatus}
occupationCode [0..1]

A code qualifying the classification of kind-of-work based upon arecognized industry or jurisdictional standard. OccupationCode isused to convey the person's occupation as opposed to jobClassCode(not used in this transaction) which characterizes this particular job.
For example, it can be used to capture whether the person is a
Military Veteran or not.

Employee (CE) {CWE:EmployeeOccupationCode}

LanguageCommunication

A language communication capability of the focal person

languageCode [1..1] (M)A value representing a language for which the focal person has
some level of proficiency for written or spoken communication.
Examples: Spanish, Italian, German, English, American Sign

LanguageCommunication (CE){CWE:HumanLanguage}
preferenceInd [0..1]

An indicator specifying whether or not this language is preferred by
the focal person for the associated mode

LanguageCommunication (BL)QueryMatchObservation

Used to convey information about the quality of the match for eachrecord.

classCode [1..1] (M)Observation (CS) {CNE:, default= "OBS"}

Structural attribute – this is an observation

moodCode [1..1] (M)Observation (CS) {CNE:, default= "EVN"}

Structural attribute – this is an eventcode [1..1] (M)Observation (CD)
{CWE:QueryMatchObservationType}A code, identifying this observation as a query match observation.

value [1..1] (M)QueryMatchObservation (INT)

A numeric value indicating the quality of match for this record. It
shall correspond to the MinimumDegreeMatch.value attribute of theoriginal query, and it shall have the same meaning (e.g., percentage,
indicating confidence in the match).

3.47.4.2.2.3 Control Act and Transmission Wrappers
5465

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. 8.0 Final Text 2011-08-19

219

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
Table 3.47.4.4.2-9 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

MFMI_MT700711UV01 – Master File/Registry Query
Response Control Act (Role Subject)

The value of interactionId SHALL be set to
PRPA_IN201306UV02

The value of ControlActProcess.moodCode SHALL be set
to EVNThe value of processingModeCode SHALL be set
to T

The trigger event code in ControlActProcess.code SHALL
be set to PRPA_TE201306UV02

The acceptAckCode SHALL be set to NE

There SHALL be zero or more RegistrationEvents present
in this message.

There SHALL be only one receiver Device

For each matching record returned, there SHALL be exactly
one RegistrationEvent present in this message.
If a RegistrationEvent is part of the message, there SHALL
be exactly one Patient role present in the payload.
There SHALL be no replacementOf act-relationship present
in this message
There SHALL be a QueryByParameter copy of the original
query.
The QueryAck.resultTotalQuantity,
QueryAck.resultCurrentQuantity, andQueryAck.resultRemainingQuantity attributes SHALL havethe appropriate values populated.

5470

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.

5475

The following WSDL naming conventions SHALL apply:
response message-> "PRPA_IN201306UV02_Message"

The following WSDL snippet describes the type for these message:

5480

5485

5490

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

Rev. 8.0 Final Text 2011-08-19

220

Copyright © 2011 IHE International, Inc.

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

5495<message name="PRPA_IN201306UV02_Message"><part element="hl7:PRPA_IN201306UV02" name="Body"/></message>…

3.47.4.2.3 Expected Actions

5500

The Patient Demographics Supplier shall perform the matching of patient data based on thequery parameter values it receives. The information provided by the Patient Demographics
Supplier to Patient Demographics Consumers is a list of possible matching patients from thepatient information source associated with the value that the Consumer sent in the Device classof the transmission wrapper of the query message.
If OtherIDsScopingOrganization parameters were part of the query, and they were recognized by
the Patient Demographics Supplier as identifying known Patient Identity Domains, the response
will also, for each patient, contain any Patient ID values found in the specified domains.

5505

The mechanics of the matching algorithms used are internal to the Patient Demographics
Supplier and are outside of the scope of this framework.
The Patient Demographics Supplier shall respond to the query request as described by thefollowing 3 cases:

5510

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)

5515

5520

5525

5530

One RegistrationEvent (and the associated Patient role, subject of that event) is returned from thepatient information source for each patient record found. If the Patient Demographics Supplier
returns data for multiple patients, it shall return these data in successive occurrences of theRegistrationEvent class within the transmission wrapper.
For each patient, one or more identifiers from the Patient ID Domain associated with the target
patient information source identified by Receiver.Device are represented as Patient.id attributes.
If an incremental number of records are specified in QueryByParamter.initialQuantity (i.e., theConsumer supports the Continuation option), and the number of records to be sent exceeds that
incremental number, the Supplier shall return only up to the incremental number of records. If
the Supplier supports the Continuation option, it shall correctly populate the resultTotalQuantity,
resultCurrentQuantity, and resultRemainingQuantity attributes of the QueryAck class in thecontrol act wrapper. If the Supplier does not support the Continuation option, in addition to
returning only up to the incremental number of records requested, it shall return AE (application
error in the Acknowledgement.typeCode (transmission wrapper) and AE (application error) is
returned in QueryAck.queryResponseCode (control act wrapper).
The Consumer may then send a query continuation message as a subsequent query request for
the next increment of responses.

Rev. 8.0 Final Text 2011-08-19

221

Copyright © 2011 IHE International, Inc.

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

5535

Case 2: The Patient Demographics Supplier finds (in the patient information source associatedwith Receiver.Device in the query transmission wrapper) at least one patient record matching thecriteria sent in the query parameters. One or more OtherIDsScopingOrganization parameters arepresent in the query; the Supplier recognizes all the requested domains.
AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).
OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

5540

5545

5550

5555

5560

One RegistrationEvent (and the associated Patient role, subject of that event) is returned fromthe patient information source for each patient record found. If the Patient Demographics
Supplier returns data for multiple patients, it shall return these data in successive occurrences of
the RegistrationEvent class within the transmission wrapper.
For each patient, the identifiers from all the Patient ID Domains requested via the
OtherIDsScopingOrganization parameter are returned either as values of the Patient.id attribute,or as values of the OtherIDs.id attribute. The same patient identifier value shall not appear inboth the Patient.id and OtherIDs.id attributes. The Patient Demographics consumer shallconsider the identifiers from both places as equivalently valid. If the Patient Demographics
supplier cannot provide a patient ID for some of the requested Patient ID Domains, then an
OtherIDs.id attribute shall have an appropriate null value, and the ScopingOrganization classshall identify the corresponding domain.
If an incremental number of records are specified in QueryByParamter.initialQuantity, and thenumber of records to be sent exceeds that incremental number, and the Patient Demographics
Supplier supports the Continuation Option, the Supplier returns only the incremental number ofrecords, correctly populating the resultTotalQuantity, resultCurrentQuantity, andresultRemainingQuantity attributes of the QueryAck class in the control act wrapper. The
consumer will sent a query continuation message as a subsequent query request for the next
increment of responses. If the Supplier does not support the Continuation Option, then AE(application error) is returned in the Acknowledgement.typeCode (transmission wrapper) and AE(application error) is returned in QueryAck.queryResponseCode (control act wrapper).
Case 3: The Patient Demographics Supplier does not recognize one or more
OtherIDsScopingOrganization parameters as representing valid Patient Identity Domains.
AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in
QueryAck.queryResponseCode (control act wrapper).
No RegistrationEvent is returned.

5565

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

VALUE

typeCodeEcode

204 (Unknown Key Identifier)Rev. 8.0 Final Text 2011-08-19

222

Copyright © 2011 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
5570

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PDSupplier”.
The following WSDL naming conventions SHALL apply:

5575

5580

5585

wsdl:definitions/@name="PDSupplier":
patient demographics query-> "PRPA_IN201305UV02_Message"
patient demographics response -> "PRPA_IN201306UV02_Message"
continuation query-> "QUQI_IN000003UV01_Message"
accept acknowledgement-> "MCCI_IN000002UV01_Message"
portType-> "PDSupplier_PortType"get candidates operation-> "PDSupplier_PRPA_IN201305UV02"
continuation operation->"PDSupplier_PRPA_IN201305UV02_Continue"
cancel operation-> "PDSupplier_PRPA_IN201305UV02_Cancel"
SOAP 1.2 binding-> "PDSupplier_Binding_Soap12"
SOAP 1.2 port-> "PDSupplier_Port_Soap12"

The following WSDL snippets specify the Patient Demographics Query Port Type and Binding
definitions, according to the requirements specified in ITI TF-2x: Appendix V.
3.47.4.2.3.1.1 Port Type

5590

5595

5600

5605

<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>3.47.4.2.3.1.2 Bindings
5610

SOAP 1.2 binding:…

Rev. 8.0 Final Text 2011-08-19

223

Copyright © 2011 IHE International, Inc.

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

5615

5620

5625

5630

5635

5640

5645

<binding name="PDSupplier_Binding_Soap12" type="PDSupplier_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="PDSupplier_PRPA_IN201305UV02"><wsoap12:operation soapAction="urn:hl7-org:v3:PRPA_IN201305UV02"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Continue"><wsoap12:operation soapAction="urn:hl7org:v3:QUQI_IN000003UV01_Continue"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="PDSupplier_QUQI_IN000003UV01_Cancel"><wsoap12:operation soapAction="urn:hl7-org:v3:
QUQI_IN000003UV01_Cancel"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation></binding>…

An informative WSDL for the Patient Demographics Supplier implementing the PDQV3 profile
is available online on the IHE FTP site, see ITI TF-2x: Appendix W.
3.47.4.2.3.2 Message Examples
5650

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

5655

A Patient Demographics Consumer’s need to get another set of matching records to a previously
sent Patient Demographics query will trigger the Patient Demographics Query Continuation
based on the following HL7 trigger event:
Query General Activate Query Continuation (QUQI_TE000003UV01)

Rev. 8.0 Final Text 2011-08-19

224

Copyright © 2011 IHE International, Inc.

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

3.47.4.3.2 Message Semantics
The Query continuation is supported by the Query Control Act Request Continue / Cancel(QUQI_MT000001UV01) message. The Patient Demographics Consumer shall generate thecontinuation message whenever it needs to receive another set of matching records based on the
results of a previously sent query.

5665

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.

5670

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

5675

This message contains no domain payload, it is built from a transmission and control act
wrappers.
3.47.4.3.2.2 Message Information Model of the Query Continuation Message
Please see ITI TF-2x: Appendix O for the description of the transmission and control act
wrappers used by this message. The next section discusses the wrappers, and the specificconstraints relevant to this transaction.

5680

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.
Table 3.47.4.3.2-1 Wrappers and Constraints
Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000300UV01 – Send Application
Acknowledgement

QUQI_MT000001UV01 – Query Control Act
Request Continue / Cancel

The value of interactionId SHALL be set to
QUQI_IN000003UV01

The trigger event code in ControlActProcess.code
SHALL be set to PRPA_TE000003UV01

The value of processingModeCode SHALL be set to T

QueryContinuation.queryId SHALL be set to theoriginal query identifier

The acceptAckCode SHALL be set to AL
There SHALL be only one receiver Device
The Acknowledgement.typeCode SHALL be set to AA
The TargetMessage.id SHALL be the message ID ofRev. 8.0 Final Text 2011-08-19

225

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
the immediately preceding Query response message

5685

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)
3.47.4.3.2.4 Web Services Types and Messages

5690

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

5695

5700

5705

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

5710

5715

…
<message name="QUQI_IN000003UV01_Message"><part element="hl7:QUQI_IN000003UV01" name="Body"/></message>…

The port types for the WSDL describing the Patient Demographics Service are described
together with the expected actions of the actors which receive these messages in section ITI TF2b: 3.47.4.2.3.
3.47.4.3.3 Expected Actions

5720

5725

If a number of records is specified in the initialQuantity of the original quantity, and the Patient
Demographics Supplier supports the Continuation Option, the Patient Demographics Supplier
Actor shall return an incremental response of that number of records when the number ofmatching records it finds exceeds the number of records specified. In subsequent querycontinuation messages, the Patient Demographics Consumer may specify a different number ofrecords to be returned from now on for this query session by populating the continuationQuantity
attribute. In addition, the consumer may specify from which record the next set of matches
should start by populating the startResultNumber attribute. If the Patient Demographics Supplierdoes not support the Continuation Option and the number of matching records to the original

Rev. 8.0 Final Text 2011-08-19

226

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
query exceeds the number specified, then, in addition to returning up to that number of records,
the Supplier shall return AE (application error) in the Acknowledgement.typeCode (transmission
wrapper) and AE (application error) in QueryAck.queryResponseCode (control act wrapper).
5730

5735

5740

The Patient Demographics Supplier shall always populate the resultTotalQuantity,
resultCurrentQuantity, and resultRemainingQuantity in the QueryAck class. This information
will indicate to the Patient Demographics Consumer whether there are any remaining records tobe returned in subsequent continuations.
The Patient Demographics Consumer shall indicate a query session cancellation by sending acontinuation message, and setting the continuationQuantity attribute to 0, and setting thestatusCode to "aborted". In such case, the Patient Demographics Supplier shall respond with an
Accept Acknowledgement (as described in ITI TF-2x: Appendix O).
Sending a query cancellation message is optional. The Patient Demographics Supplier may
simply not send any continuation messages once a record has been selected. How long thePatient Demographic Supplier retains query results (for incremental response) is an
implementation decision and therefore beyond the scope of IHE.
3.47.4.3.3.1 Web Services Port Type and Binding Definitions
This information is part of the specification of the Patient Demographics Query response in ITI
TF-2b: 3.47.4.2.3.1.

5745

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
No transaction specific security considerations.

5750

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 table 3.20.6-1. The following tables show
items that are required to be part of the audit record for this transaction.

5755

3.47.5.1.1 Patient Demographics Consumer audit message:
Event

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

Rev. 8.0 Final Text 2011-08-19

227

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM

not specialized

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

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserIDM

identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointIDM

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

Audit Source

AuditSourceIDU

not specialized.

AuditMessage/
AuditSourceIdentification

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

Human
Requestor (ifknown)
AuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Patient

Rev. 8.0 Final Text 2011-08-19

228

Copyright © 2011 IHE International, Inc.

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

Query
Parameters(AudittMessage/
ParticipantObjectIdentifi
cation)M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivity

U

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”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectIDU

not specialized

ParticipantObjectNameU

not specialized

ParticipantObjectQueryM

the QueryByParameter segment of the query, base64 encoded

ParticipantObjectDetailUnot specialized

5760
3.47.5.1.2 Patient Demographics Source audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-47”, “IHE Transactions”, “Patient Demographics Query”)

UserIDM

the content of the <wsa:ReplyTo/> element

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM

not specialized

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointIDM

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

UserID

M

SOAP endpoint URI

Source (Patient Demographics Consumer) (1)Destination (Patient Demographics Supplier) (1)Audit Source (Patient Demographics Supplier) (1)Patient (0..n)Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

DestinationRev. 8.0 Final Text 2011-08-19

229

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10 Cross-Enterprise Document Sharing (XDS.b1)
The Cross-Enterprise Document Sharing (XDS.b) IHE Integration Profile facilitates theregistration, distribution and access across health enterprises of patient electronic health records.
2025

Cross-Enterprise Document Sharing is focused on providing a standards-based specification for
managing the sharing of documents between any healthcare enterprise, ranging from a private
physician office to a clinic to an acute care in-patient facility.
In the rest of the ITI Technical Framework the term XDS refers generically to any flavor of XDS,
currently only XDS.b¹.

2030

2035

2040

2045

2050

The XDS.b IHE Integration Profile assumes that these enterprises belong to one or more XDS
Affinity Domains. An XDS Affinity Domain is a group of healthcare enterprises that have agreed
to work together using a common set of policies and share a common infrastructure.
Examples of XDS Affinity Domains include:• Community of Care supported by a regional health information organization in order to serve all
patients in a given region.
• Nationwide EHR• Specialized or Disease-oriented Care
• Cardiology Specialists and an Acute Cardiology Center• Oncology network• Diabetes network• Federation of enterprises• A regional federation made up of several local hospitals and healthcare providers• Government sponsored facilities (e.g., VA or Military)• Insurance Provider Supported Communities
Within an XDS Affinity Domain, certain common policies and business rules must be defined.
They include how patients are identified, consent is obtained, and access is controlled, as well as theformat, content, structure, organization and representation of clinical information. This Integration
Profile does not define specific policies and business rules, however it has been designed toaccommodate a wide range of such policies to facilitate the deployment of standards-based
infrastructures for sharing patient clinical documents. This is managed through federated document
repositories and a document registry to create a longitudinal record of information about a patient
within a given XDS Affinity Domain. These are distinct entities with separate responsibilities:• A document repository is responsible for storing documents in a transparent, secure, reliable andpersistent manner and responding to document retrieval requests.

1

XDS.b is used because in prior versions of the Technical Framework there was an XDS.a. With TF Version 7.0
XDS.a has been deprecated.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

76

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2055

2060

2065

2070

________________________________________________________________________________• A document registry is responsible for storing information about those documents so that the
documents of interest for the care of a patient may be easily found, selected and retrieved
irrespective of the repository where they are actually stored.
The concept of a document in XDS is not limited to textual information. As XDS is document
content neutral, any type of clinical information without regard to content and representation is
supported. This makes the XDS IHE Integration Profile equally able to handle documents
containing simple text, formatted text (e.g., HL7 CDA Release 1), images (e.g., DICOM) or
structured and vocabulary coded clinical information (e.g., CDA Release 2, CCR, CEN ENV
13606, DICOM SR). In order to ensure the necessary interoperability between the document
sources and the document consumers, the XDS Affinity Domain must adopt policies concerning
document format, structure and content.
The XDS Integration Profile is not intended to address all cross-enterprise EHR communicationneeds. Some scenarios may require the use of other IHE Integration profiles, such as Patient
Identifier Cross-Referencing, Audit Trail and Node Authentication, Cross-Enterprise User
Authentication, and Retrieve Information for Display. Other scenarios may be only partially
supported, while still others may require future IHE Integration profiles, which will be defined by
IHE as soon as the necessary base standards are available. Specifically:1.

The management of dynamic information such as allergy lists, medication lists, problem
lists, etc. is not addressed by XDS. However, the Retrieve Information for Display
Integration Profile does provide some transactions (e.g., LIST-ALLERGIES, LISTMEDS) that may be used to provide an elementary support of such capabilities. A
complementary approach to managing updates and structured application access to such
dynamic clinical information may be expected as a separate Integration Profile in the
future.

2.

The placing and tracking of orders (e.g., drug prescriptions, radiology orders, etc.) is notsupported by XDS. This does not preclude the use of XDS to store and register orders andcorresponding results when such artifacts need to be recorded in the patient’s healthrecord. However, XDS provides no facilities for tracking progress of an order through its
workflow, and therefore is not intended for order management. A complementary
approach to cross-enterprise order workflow (ePrescription, eReferral) may be expected as
separate Integration Profiles in the future.

3.

The operation of any XDS Affinity Domain will require that a proper security model be
put in place. It is expected that a range of security models should be possible. Although
the XDS Integration Profile is not intended to include nor require any specific security
model, it is expected that XDS implementers will group XDS Actors with actors from theIHE Audit Trail and Node Authentication and will need an Access Control capability that
operates in such a cross-enterprise environment. Specific IHE Integration Profiles
complementary to XDS are available (e.g., Cross-Enterprise User Authentication,
Document Digital Signature, etc.).

4.

The establishment of independent XDS Affinity Domains will call for their federation, as
patients expect their records to follow them as they move from region to region, or country
to country. IHE foresees a need for transferring information from one XDS Affinity
Domain to another, or to allow access from one XDS Affinity Domain to documents

2075

2080

2085

2090

2095

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

77

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
managed in other XDS Affinity Domains. XDS has been designed with this extension inmind. The Cross-Community Access (XCA) Integration Profile that complements XDS
provides this function.
2100

5.

XDS does not address transactions for the management or configuration of an XDS
Affinity Domain. For example, the configuration of network addresses or the definition ofwhat type of clinical information is to be shared is specifically left up to the policies
established by the XDS Affinity Domain.

10.1 Actors/Transactions
Patient Identity Source

Patient Identity Feed [ITI-8]
Patient Identity Feed HL7v3 [ITI-44]↓
Registry Stored Query[ITI-18] ←Document Consumer

Document Registry↑ Register Document Set – b [ITI-42]

Document Source

Provide&Register
Document Set – b [ITI-41]→

Document Repository

Retrieve Document Set [ITI-43]←

Integrated Document Source/Repository

2105

Figure 10.1-1b Cross-Enterprise Document Sharing – b (XDS.b) Diagram
Table 10.1-1b XDS.b - Actors and Transactions
ActorsDocument Consumer

Transactions

Optionality

SectionRegistry Stored Query [ITI-18]

R

ITI TF-2a: 3.18

Retrieve Document Set [ITI-43]

R

ITI TF-2b: 3.43

Document Source

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

ITI TF-2b: 3.41

Document Repository

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

ITI TF-2b: 3.41

Register Document Set-b [ITI-42]

R

ITI TF-2b: 3.42

Retrieve Document Set [ITI-43]

R

ITI TF-2b: 3.43

Register Document Set-b [ITI-42]

R

ITI TF-2b: 3.42

Document Registry

Registry Stored Query [ITI-18]

R

ITI TF-2a: 3.18

Patient Identity Feed [ITI-8]

O (Note 2)

ITI TF-2a: 3.8

Patient Identity Feed HL7v3 [ITI-44]

O (Note 2)

ITI TF-2b: 3.44________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

78

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Integrated Document
Source/Repository
Patient Identity Source

2110

Register Document Set-b [ITI-42]

R

ITI TF-2b: 3.42

Retrieve Document Set [ITI-43]

R

ITI TF-2b: 3.43

Patient Identity Feed [ITI-8]

O (Note 1,2)

ITI TF-2a: 3.8

Patient Identity Feed HL7v3 [ITI-44]

O (Note 1,2)

ITI TF-2b :3.44

Note 1:

If Assigning Authority of Patient ID presents in the Patient Identity Feed or Patient Identity Feed HL7v3 transaction,
the Patient Identity Source is required to use an OID to identify the Assigning Authority. For technical details of theassigning authority information, see ITI TF-2a: 3.8.

Note 2:Document Registry and Patient Identify Source shall implement at least one of Patient Identity Feed or Patient
Identity Feed HL7v3.

10.1.1 Actors
2115

10.1.1.1 Document Source
The Document Source Actor is the producer and publisher of documents. It is responsible forsending documents to a Document Repository Actor. It also supplies metadata to the Document
Repository Actor for subsequent registration of the documents with the Document Registry Actor.
10.1.1.2 Document Consumer

2120

The Document Consumer Actor queries a Document Registry Actor for documents meeting certain
criteria, and retrieves selected documents from one or more Document Repository actors.
10.1.1.3 Document Registry2125

The Document Registry Actor maintains metadata about each registered document in a document
entry. This includes a link to the Document in the Repository where it is stored. The Document
Registry responds to queries from Document Consumer actors about documents meeting specificcriteria. It also enforces some healthcare specific technical policies at the time of document
registration.
10.1.1.4 Document Repository

2130

The Document Repository is responsible for both the persistent storage of these documents as well
as for their registration with the appropriate Document Registry. It assigns a uniqueId to documents
for subsequent retrieval by a Document Consumer.
10.1.1.5 Patient Identity Source

2135

The Patient Identity Source Actor is a provider of unique identifier for each patient and maintains acollection of identity traits. The Patient Identify Source facilitates the validation of patient
identifiers by the Registry Actor in its interactions with other actors.
10.1.1.6 Integrated Document Source/Repository
The Integrated Document Source/Repository combines the functionality of the Document Source
and Document Repository actors into a single actor that does not initiate nor accept the Provide ad________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

79

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2140________________________________________________________________________________
Register Document Set transaction. This actor may replace the Document Repository actor from theperspective of the Register Document Set or Retrieve Document transactions.
10.1.2 Transactions
10.1.2.1 Provide and Register Document Set

2145

A Document Source Actor initiates the Provide and Register Document Set Transaction. For eachdocument in the submitted set, the Document Source Actor provides both the documents as an
opaque octet stream and the corresponding metadata to the Document Repository. The Document
Repository is responsible to persistently store these documents, and to register them in theDocument Registry using the Register Documents transaction by forwarding the document metadata
received from the Document Source Actor.
10.1.2.2 Register Document Set

2150

2155

A Document Repository Actor initiates the Register Document Set transaction. This transaction
allows a Document Repository Actor to register one or more documents with a Document Registry,by supplying metadata about each document to be registered. This document metadata will be used
to create an XDS Document Entry in the registry. The Document Registry Actor ensures that
document metadata is valid before allowing documents to be registered. If one or more documents
fail the metadata validation, the Register Document Set transaction fails as a whole.
To support composite documents, an XDS Document may be a multipart document. The Document
Repository must handle multi-part data sets as an “opaque entity”. The Document Repository does
not need to analyze or process its multi-part structure nor the content of any parts in the context ofthe XDS Integration Profile.

2160

10.1.2.3 Intentional left blank
10.1.2.4 Registry Stored Query2165

The Registry Stored Query transaction is issued by the Document Consumer Actor on behalf of acare provider (EHR-CR) to a Document Registry. The Document Registry Actor searches theregistry to locate documents that meet the provider’s specified query criteria. It will return registry
metadata containing a list of document entries found to meet the specified criteria including thelocations and identifier of each corresponding document in one or more Document Repositories.
In a Stored Query, the definition of the query is stored on the Registry actor. To invoke the query,an identifier associated with the query is transmitted along with parameters defined by the query.
This has the following benefits:2170

1. Malicious SQL transactions cannot be introduced
2. Alternate database styles and schemas can be used to implement the Document Registry
actor. This is because the style of SQL query statements is directly related to the tablelayout in a relational database.

2175

This profile does not define how Stored Queries are loaded into or implemented in the Document
Registry actor.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

80

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
10.1.2.5 Intentionally left blank
10.1.2.6 Patient Identity Feed

2180

2185

2190

2195

The Patient Identity Feed Transaction conveys the patient identifier and corroborating demographic
data, captured when a patient’s identity is established, modified or merged or in cases where the key
corroborating demographic data has been modified. Its purpose in the XDS Integration Profile is topopulate the registry with patient identifiers that have been registered for the XDS Affinity
Domains.
The Patient Identify Feed Transaction defined in ITI TF-2a:3.8 for HL7v2 and in ITI TF-2b: 3.44
for HL7v3 uses standard HL7 encoding of Patient Identifiers. This is standard encoding for HL7
applications; receiving applications are expected to extract the required data for their use.
When combined with the other XDS transactions, Document Registry actors and other actors thatreceive HL7 data with Patient Identifiers are required to map the data received in the HL7 message
to the format specified in those other XDS transactions. In those transactions, the Patient ID istreated using ebXML encoding rules and not HL7 encoding rules. Specifically, the Patient ID willbe treated as a string, and extra components entered in that string shall cause those transactions to
fail. XDS actors are required to use the specified encoding for Patient ID values in othertransactions and not merely copy the value received in an HL7 transaction.
XDS.b implementations shall support either Patient Identity Feed (ITI TF-2a: 3.8) or Patient
Identity Feed HL7v3 (ITI TF-2b: 3.44) or both. It is important to note that the version of HL7
implemented by XDS.b and Patient Identity Feed in a single domain or community need to match inorder to allow interoperability. In the case of mixed scenarios, translation between Patient Identity
Feed (ITI TF-2a:3.8) and Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) will be required via abridge or interface engine.
10.1.2.7 Retrieve Document Set

2200

A Document Consumer Actor initiates the Retrieve Document Set transaction. The Document
Repository shall return the document set that was specified by the Document Consumer.
10.1.3 XDS Document Contents Support

2205

The following table lists a few of the document contents supported in other IHE Integration
Profiles, which specify concrete content types for sharing of clinical documents in various domains.
These profiles are built on the XDS profile, and may define additional constraints and semantics forcross-enterprise document sharing in their specific use cases.
Table 10.1-1: List of IHE Integration Profiles and Document Types They Support
IHE Technical
Framework
DomainIT Infrastructure

Integration Profile
Name

Document Content Supported

An example of an ITI
domain content profile
defining a document that
may be exchanged using
XDS is Cross-Enterprise

Scanned document, plain text or PDF/A, in HL7 CDA R2 format________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

81

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Sharing of Scanned
Documents (XDS-SD).
Refer to ITI TF-3:5 for other
ITI content specifications.

Patient Care
Coordination

An example of a PCC
domain content profile
defining a document that
may be exchanged using
XDS is Cross-Enterprise
Sharing of Medical
Summaries (XDS-MS).
Refer to PCC TF-1 for otherdocument content profiles.

Medical Summary in the HL7 CDA format

Radiology

Cross-Enterprise Document
Sharing for Imaging (XDSI)Radiology Diagnostic Report in the plain text or PDF formats
Reference to a collection of DICOM SOP Instances in a manifest
document in the DICOM Key Object Selection format

2210________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

82

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.2 Integration Profile Options
Options that may be selected for this Integration Profile are listed in Table 10.2-1-b along with theActors to which they apply. Dependencies between options when applicable are specified in notes.
2215
Table 10.2-1b XDS.b - Actors and Options
Actor
Document Source

Options

Vol & Section

Document Replacement

ITI TF-1: 10.2.1

Document Addendum

ITI TF-1: 10.2.2

Document Transformation

ITI TF-1: 10.2.3

Folder Management

ITI TF-1: 10.2.4

Basic Patient Privacy Enforcement

ITI TF-2b:3.41.4.1.3.1

Asynchronous Web Services Exchange

ITI TF-1: 10.2.5

Document Repository

Asynchronous Web Services Exchange

ITI TF-1: 10.2.5

Document Registry (Note 2)

Patient Identity Feed (Note 1)

ITI TF-2a: 3.8

Patient Identity Feed HL7v3 (Note 1)

ITI TF-2b: 3.44

Asynchronous Web Services Exchange

ITI TF-1: 10.2.5

Document Replacement

ITI TF-1: 10.2.1

Document Addendum

ITI TF-1: 10.2.2

Document Transformation

ITI TF-1: 10.2.3

Folder Management

ITI TF-1: 10.2.4

Basic Patient Privacy Enforcement

ITI TF-2b: 3.42.4.1.4.1

Asynchronous Web Services Exchange

ITI TF-1: 10.2.5

Integrated Document Source / Repository

Document Consumer

Basic Patient Privacy Enforcement

ITI TF-2a: 3.18.4.1.3.5
ITI TF-2b: 3.43.4.1.3.1

Patient Identity Source

2220

Basic Patient Privacy Proof

ITI TF-2a: 3.18.4.1.3.6

Asynchronous Web Services Exchange

ITI TF-1: 10.2.5

Patient Identity Feed (Note 1)

ITI TF-2a: 3.8

Patient Identity Feed HL7v3 (Note 1)

ITI TF-2b: 3.44

Note 1:Document Registry and Patient Identify Source shall implement at least one of Patient Identity Feed or Patient
Identity Feed HL7v3.

Note 2:

An XDS.b Document Registry has always been required to validate that documents that are registered do contain aconfidentialityCode from an XDS Affinity Domain vocabulary. The BPPC profile is giving some structure to thisXDS Affinity Domain defined vocabulary.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

83

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
10.2.1 Document Replacement Option.
2225

In this option the Document Source or Integrated Document Source/Repository shall offer theability to submit a document as a replacement for another document already in theregistry/repository. Grouping with Document Consumer can be used to obtain the most recent
metadata and ids to be used in the replace submission.
10.2.2 Document Addendum Option

2230

In this option the Document Source or Integrated Document Source/Repository shall offer theability to submit a document as an addendum to another document already in the registry/repository.
10.2.3 Document Transformation Option

2235

In this option the Document Source or Integrated Document Source/Repository shall offer theability to submit a document as a transformation of another document already in theregistry/repository.
10.2.4 Folder Management Option
In this option the Document Source offers the ability to perform the following operation:• Create a folder 2• Add one or more documents to a folder

2240

Note: In order to support document addition to an existing folder, grouping with the Document Consumer may be necessary inorder to Query the registry (e.g., for UUIDs of existing folder).

10.2.5 Asynchronous Web Services Exchange Option
Actors that support this option shall support the following:
2245•

Document Source Actor shall support Asynchronous Web Services Exchange for theProvide & Register Document Set – b [ITI-41] transaction•

Document Consumer Actor shall support Asynchronous Web Services Exchange for theRegistry Stored Query [ITI-18] and Retrieve Document Set [ITI-43] transactions•

Document Repository Actor shall support Asynchronous Web Services Exchange for theProvide & Register Document Set – b [ITI-41] and Register Document Set – b [ITI-42], andRetrieve Document Set [ITI-43] transactions•

Document Registry Actor shall support Asynchronous Web Services Exchange for theRegistry Stored Query [ITI-18] and Register Document Set – b [ITI-42] transactions

2250

Use of Synchronous or Asynchronous Web Services Exchange is dictated by the individual installenvironment and affinity domain policy. Refer to section ITI TF-2x: V.5 Synchronous and2

The term “folder” comes from the medical community which commonly places patient records in folders for
specific purposes. In computer science terminology this concept is most consistent with the UNIX directory format,
where a file can be simultaneously within multiple directories.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

84

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles
2255________________________________________________________________________________
Asynchronous Web Services Exchange for an explanation of Asynchronous Web Services
Exchange.

10.3 Integration Profile Process Flow
2260

2265

A typical patient goes through a sequence of encounters in different care settings. In each caresetting, the resulting patient information is created and managed by multiple care delivery
information systems (EHR-CRs). Through a sequence of care delivery activities, a number ofclinical documents are created. The EHR-LR provides the means to share the relevant subset ofthese documents, as they are contributed by the various EHR-CRs that are part of the same XDS
Affinity Domain.
Example: Cardiac Patient Management Scenario

Figure 10.3-1 Cardiac Patient Management Scenario Transaction Process Flow

2270

This scenario spans about 3 weeks of a patient’s cardiac episode. The patient presents to her
primary care provider (PCP) with complaints of shortness of breath, nausea, tiredness and chest
pains. This doctor works closely with a local hospital that has recently established a cardiac care
network that allows PCPs, cardiologists, laboratories and two local hospitals to share clinicaldocuments to improve patient care. This cardiac network is part of a local care data exchange________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

85

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2275________________________________________________________________________________
community that has been set-up in this community and to which the care plan to which this patient
belong has encouraged patients to subscribe. Our patient has been provided a health record accountnumber.
1.

2280

2285

2290

During the patient examination, the PCP records the complaint, and determines that heshould perform an ECG. He queries the cardiac care network to see if there are prior ECG
reports (step 1 in Figure 10.3-2), using a coded document class “report” and a coded
practice setting “cardiology” established by the cardiac care network for ECG reports.
Among the matching Documents, he locates a prior ECG report that is then retrieved (step2 in Figure 10.3-2). He compares the two results and determines that the patient should bereferred to a cardiologist. He searches for additional reports in the cardiac care network(step 3 in Figure 10.3-2) for this patient, but finds none.
Using the ambulatory EHR system, he creates a submission request onto the patients’
health record account number for a “PCP office visit” that includes a submission set
consisting of three new documents (visit note, referral letter, new ECG report) and of one
reference to the prior ECG report (step 4 in Figure 10.3-2). Following the Cardiology
Network XDS Affinity Domain policy, he creates a “cardiac assessment” Folder to containall four documents in order to facilitate collaboration with the cardiologist.
The repository used by the ambulatory EHR system will then register the documents thatare part of this submission request (step 5 in Figure 10.3-2).
Document Consumer:(PCP EHR-CR)

Document Source:(PCP EHR-CR)

Document Repository:(Cardiology Network)

Document Registry:(Cardiology Network)

1. Query Documents
2. Retrieve Document
3. Query Documents
4. Provide andRegister Document

5. Register Document
S t

Figure 10.3-2 PCP Query Transactions Process Flow

The PCP EHR system implements the Document Consumer and Document Source actors
to issue the Query, Retrieve and Provide & Register transactions as shown in Figure 10.32. The transactions are processed by the Document Repository and the Document
Registry provided by the cardiology care network.

2295

2.
2300

The patient appointment with the cardiologist is scheduled. The patient goes to the lab forthe lab tests required before appointment. The lab creates a submission set with a clinicalcode of “laboratory tests” containing the lab results. The lab is not aware of the“cardiology assessment” folder.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

86

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2305

2310

________________________________________________________________________________
3.
The cardiologist sees the patient. He queries the repository for any patient’s records in a“cardiac assessment” folder (step 1 in Figure 10.3-3). Available are the visit note from the
PCP, the ECG and prior ECG, and the referral letter, which he retrieves and reviews (steps
2-5 in Figure 10.3-3). He also queries for recent lab reports, and finds the lab results (step
6 in Figure 10.3-3). This is also retrieved and reviewed (step 7 in Figure 10.3-3).
The cardiologist performs an ultrasound, dictates a visit note, and orders a nuclear stresstest. The visit note and ultrasound images and report are registered as a “cardiologist
office visit” submission set and placed in the “cardiac assessment” Folder. In addition, thelab report is added to the “cardiac assessment” Folder (step 8 in Figure 10.3-3).
Document Consumer:(PCP EHR-CR)

Document Source:(PCP EHR-CR)

Document Repository:(Cardiology Network)

Document Registry:(Cardiology Network)

1. Query Documents
2. Retrieve Document
3. Retrieve Document
4. Retrieve Document
5. Retrieve Document
6. Query Documents
7. Retrieve Document
8. Provide andRegister Document

9. Register Document
S t

Figure 10.3-3 PCP Query Transactions Process Flow4.

The patient is seen at a radiology facility for the nuclear stress test. The test is performed,
and the radiologist dictates the report. The nuclear stress test report is registered in a“radiology examination” submission set and associated with the “cardiac assessment”
Folder5.

Although she has a scheduled appointment with her cardiologist in two days, she wakes up
with severe chest pain. On the way to work, she decides to go to the emergency room
(ER) of her local hospital. The ER doctor uses the hospital EHR system to query the
cardiac care network registry and repositories for documents related to the patient inreverse chronological order (step 1 in Figure 10.3-4). Available documents from latest
cardiology related Folder are the visit notes from the PCP and cardiologist, the recent andprior ECGs, the lab results, and the ultrasound images and report, and the nuclear stresstest images and report.
The ER doctor retrieves and reviews the two most relevant reports (step 2 and 3 in Figure10.3-4).
The ER doctor orders lab tests, ECG, and places the patient under monitoring. The lab
tests and ECG are placed in the hospital EHR that acts as a Document Repository Actor
for the cardiac network. Abnormal cardiac activity requires a catheterization, diagnostics
and possibly intervention. The ER doctor admits the patient to the cardiology service andcontacts the cardiologist.

2315

2320

2325

2330

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

87

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Document
Repository:(Hospital
EHR-CR)

Document
Consumer:(ER EHR-CR)

Document
Repository:(Cardiology
Network)Document
Registry:(Cardiology
Network)

1. Query Documents

2. Retrieve Document
2. Retrieve Document

Figure 10.3-4 ER Query Transactions Process Flow

2335

6.

While talking to the ER physician, the cardiologist accesses the cardiac care network fromhis home office. He queries for all documents related to the patient since the last visit in
his office. The nuclear stress test report that he did not previously review is available,
along with lab results and ECG results from the ER. The two physicians determine a planof care and the cardiologist makes arrangements to see the patient in the hospital.

2340

7.

As the patient is transferred from the ER, the ER visit notes are submitted as an“emergency department visit” submission set and placed in a newly created “cardiology
treatment” Folder along with the earlier lab and ECG results.

8.

The patient is transferred to an inpatient bed with the following sequence of events.
• The patient is scheduled for a catheterization procedure in cath lab.
• Additional lab tests are ordered and performed.
• A diagnostics procedure is performed in cath lab.
• An intervention with the placement of a stent is performed.
• A cath intervention report is dictated.
• Patient is returned to monitored care for recovery.
• Education given to patient and family.
• Discharge Summary dictated by cardiologist.
• Cardiologist orders lab tests to be completed prior to scheduled follow-up visit.
The admission assessment, lab results, cath intervention report and key images, anddischarge summary form a “cardiology intervention” submission set, which is registeredwith the cardiac care network registry in the “cardiac treatment” Folder started by the ER.

9.

The patient returns to the cardiologist for the post discharge follow-up visit. The resulting
visit note, cardiac rehab and summary letters are placed in a “cardiology office visit”
submission set and in the “cardiac treatment” Folder.

2345

2350

2355

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

88

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2360________________________________________________________________________________
10. The patient goes to rehab sessions as scheduled by the cardiologist. The patient recovers
and is seen by the PCP and cardiologist for routine visits.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

89

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

10.4 General Principles
10.4.1 EDR-CR Concept

2365

An EHR-CR or Care-delivery Record abstracts the information system or systems of a care deliveryorganization, which may support a broad variety of healthcare facilities: private practice, nursing
home, ambulatory clinic, acute care in-patient facility, etc.
Typically a patient goes through a sequence of encounters in different care settings as depicted in
the figure below.
Long-Term Care
Acute Care
(Inpatient)

Other Specialized Care(incl. Diagnostics Services)

PCPs and Clinics(Outpatient)

Encounters

2370

Figure 10.4.1-1 Sequence of encounters across care delivery organizations

It is out of the scope of this IHE Integration Profile to define or restrict the type of care provided,
nor the internal workflow of a care delivery organization. The EHR-CR system participates only tothe cross-enterprise clinical document sharing as Document Source and Document Consumer
Actors according to the following principles:
2375

2380

1. EHR-CR as Document Source contributes documents in any one of the document formats
that are supported by the XDS Affinity Domain (e.g., CDA Release 1, CDA Release 2 withspecific templates, DICOM Composite SOP Classes, ASTM-CCR, CEN ENV 13606 etc.).
2. This Profile does not require that the EHR-CR as Document Sources and Consumers store
and manage their internal information in the form of documents as they are sharedthroughout the XDS Affinity Domain.
3. By grouping a Document Source with a Document Repository, an EHR-CR may leverage
existing storage provide a unified access mechanism without needing to duplicate storage.

2385

4. EHR-CRs as Document Sources and Consumers are responsible to map their local codes
into the XDS Affinity Domain codes if necessary.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

90

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________The XDS Documents shared by the EHR-CR and tracked by the XDS Registry form a Longitudinal
Record for the patients that received care among the EHR-CRs of the XDS Affinity Domain.

2390

Figure 10.4.1-2 Contributing and sharing to a patients’ longitudinal health record

This shared clinical record is called an EHR-LR in this Integration Profile.
10.4.2 XDS Document Concept
An XDS Document is the smallest unit of information that may be provided to a Document
Repository Actor and be registered as an entry in the Document Registry Actor.
2395

2400

2405

An XDS Document is a composition of clinical information that contains observations and services
for the purpose of exchange with the following characteristics: Persistence, Stewardship, Potential
for Authentication, and Wholeness. These characteristics are defined in the HL7 Clinical Document
Architecture specification. An XDS Document may be human readable (with the appropriate
application). In any case, it should comply with a published standard defining its structure, content
and encoding. IHE intends to define content-oriented Integration Profiles relying on such content
standards to be used in conjunction with XDS.
The XDS Integration Profile manages XDS Documents as a single unit of information; it does notprovide mechanisms to access portions of an XDS Document. Only the Document Sources orDocument Consumers have access to the internal information of the XDS Document. Whensubmitted for sharing, an XDS Document is provided to the Document Repository Actor as an octet
stream. When retrieved through the Retrieve Document Set transaction, it shall be unchanged fromthe octet stream that was submitted.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

91

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2410________________________________________________________________________________The Document Source Actor is responsible for producing the metadata that will be submitted to theDocument Registry Actor to form the XDS Document Entry that will be used for query purposes by
XDS Consumer Actors. The Document Source maintains responsibilities over the XDS Documents
it has registered. It shall replace XDS Documents that may have been submitted in error. See ITI
TF-1: Appendix K for a more detailed discussion of the concept of XDS Document.
XDS Documents are required to be globally uniquely identified. See ITI TF-2x: Appendix B for adefinition of globally unique identifiers.

2415

10.4.3 Submission Request

2420

An XDS Submission Request is a means to share XDS Documents. It may be conveyed:• by a Document Source Actor in a Provide and Register Document Set Transaction to theDocument Repository Actor, or• by a Document Repository Actor in a Register Document Set Transaction to the Document
Registry Actor
An XDS Submission Request contains elements of information that will ensure the proper
registration of XDS Documents. These are:

2425

2430

1.

Metadata to be placed in Document Entries for new XDS Documents being submitted,

2.

A Submission Set that includes the list of all new XDS Documents and Folders being
submitted and optionally a list of previously submitted XDS Documents,

3.

If desired, Folders to be created with the list of included XDS Documents (new document
being submitted as well as previously submitted),4.

If desired, addition to previously created Folders of lists of XDS Documents (newdocument being submitted as well as previously submitted), and5.

Zero or more XDS Document octet streams for the new XDS Documents being submitted.

Following a successful Submission Request, new XDS Documents, Submission Set, and Folders
included in the Submission Request are available for sharing in an XDS Affinity Domain. In case of
failure to process a Submission Request, the Submission Set and any XDS Documents and Folders
shall not be registered.
2435

10.4.4 Submission Set Concept
An XDS Submission Set is related to care event(s) of a single patient provided by the care deliveryorganization EHR-CR performing the submission request. It creates a permanent record of new
XDS Documents as well as pre-existing (i.e. already registered) XDS Documents that have arelationship with the same care event(s). It also includes the record of new XDS Folders creation.

2440

An XDS Submission Set shall be created for each submission request. It is related to a single
Document Source Actor and is conveyed by a single Provide & Register Document Set Transaction
or a Register Document Set Transaction.
The Document Registry may be queried to find all documents registered in the same XDS
Submission Set.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

92

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles
2445________________________________________________________________________________The same XDS Document, initially registered as part of a Submission Set, may also be referenced
by later XDS Submission Set. This allows older documents relevant to the present care of a patient
to be associated with more recent Submission Sets.
XDS provides complete flexibility to EHR-CRs to relate Documents and Submission Sets to anencounter, a visit, an episode of care, or various workflow processes within EHR-CRs.

2450

10.4.5 Concept of Folder
The purpose of an XDS Folder is to provide a collaborative mechanism for several XDS Document
Sources to group XDS Documents for a variety of reasons (e.g., a period of care, a problem,
immunizations, etc.) and to offer the Document Consumers a means to find all Document Entries
placed in the same Folder. The following principles apply to an XDS Folder:

2455

2460

2465

1.

A Folder groups a set of XDS Documents related to the care of a single patient,2.

One or more Document Source Actors may submit documents in a given Folder,3.

A Folder may be created by a Document Source and/or predefined in an XDS Affinity
Domain,4.

The content of a Folder is qualified by a list of codes/meaning,

5.

Document Source Actors may find existing Folders by querying the Document Registry or
by means outside the scope of XDS (e.g., Cross-enterprise workflow, such ePrescription,eReferral, etc.),

6.

Once created a Folder is permanently known by the Document Registry,

7.

Placing previously existing Documents in Folders is not recorded as part of theSubmission Set,

8.

Folders in XDS may not be nested,

9.

The same documents can appear in more than one Folder, and

10.

Folders have a globally unique identifier.

10.4.6 Example of use of Submission Request, Submission Set and Folder
2470

2475

The sequence of figures below shows an example of a submission request that includes two new
documents, a reference to a pre-existing document and the use of two folders. The first figure
depicts the initial state of a Document Registry in which two Documents have been submitted
where one is associated with a Folder A. The second figure depicts a submission request that adds
two new documents, placing one of them into a pre-existing folder and the other one into a new
Folder B.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

93

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________

Figure 10.4.6-1 Example of a submission flow to an XDS Registry2480

From the above example, the contents of a Submission Set are shown by the figure below. The
Document Entries associated with the Submission Set are logical part of the Submission Set.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

94

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Submission
Set
2

Document
Entry

Document
Entry

New
Submission

Previous
Submission

Folder B

Document
Entry
New
Submission

Figure 10.4.6-2 The logical content of a Submission Set

10.4.7 XDS Registry Data Model and Attributes
2485

2490

The XDS Integration Profile provides a means to place documents in a repository chosen by theDocument Source, and also to place information about this document (or metadata) in an entry of
the Document Registry that manages the XDS Affinity Domain.
The term metadata reflects that this information is “about” the documents. The purpose of wellspecified document metadata is to enable a uniform mechanism for Document Consumers to locate
clinical documents of interest much in the way a card catalog in a library helps readers find thebook they want.
This section addresses the high-level data model in which the metadata is registered and against
which queries of the XDS Document Registry are performed. Then it presents the specificattributes that may be registered and used to filter the document entries of the registry.
10.4.7.1 XDS Document Registry Data Model

2495

The following entities are used in the XDS Document Registry Data Model:
XDS Document Entry: Information entity managed by a Document Registry Actor that contains a
set of metadata describing the major characteristics of an XDS Document along with a link to theDocument Repository Actor where the actual XDS Document may be retrieved.

2500

2505

XDS Document: A stream of bytes stored in a Document Repository Actor and pointed to by an
XDS Document Entry.
XDS Folder: A logical container that groups one or more XDS Document Entries in any way
required (e.g., by source care delivery activities, by episode, care team, clinical specialty or clinicalcondition). This kind of organizing structure is used variably: in some centers and systems the
Folder is treated as an informal compartmentalization of the overall health record; in others it might
represent a significant legal portion of the EHR relating to the originating enterprise or team. The
Folder is a means of providing organization of XDS Documents (or Composition in EHRCOM).
The same XDS Document Entry may belong to zero or more Folders.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

95

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2510

2515

________________________________________________________________________________XDS Submission Set: When XDS Documents are registered by a Document Source Actor, theyshall be included in one and exactly one Submission Set. An XDS Submission Set groups zero or
more new XDS Documents and references to already registered XDS Documents to ensure apersistent record of their submission.
XDS Submission Request: A Submission Request includes one and only one Submission Set, zeroor more new XDS Folders and assignment of XDS Documents into new or existing Folders. A
Submission Request is processed in an atomic manner by the Document Repository and theDocument Registry (i.e. all XDS Documents included or referenced in a Submission Set as well as
the Folders and inclusion of Folders references are registered or none will). This ensures that they
are all made available to Document Consumer Actors at the same time.
XDS Folder

10-n

Is associated with

Was initially submitted in

Clinical Affinity Domain[EHR LR] Patient1

1

1
Belongs to

XDS Submission Set
1

1

Was initially submitted in

References

Local [EHR-CR] Patient
At the time of submission
1

1

1

1-n

1

XDS Document Entry

Was submitted
for

1
1

References

2520

XDS Document in Repository

Figure 10.4.7-1 XDS Document Registry Data Model

10.4.7.2 Attributes of the XDS Document Entries
The specific attributes of each entity in the above registry data model have been selected fromdocument header attributes from several standards (see ITI TF-2x: Appendix L), including:
2525•

ANSI/HL7 CDA R1-2000•

HL7 CDA Release 2 (draft) Document header definition (Dec 2003 Committee Ballot)•

Composition attributes from EHR ENV 13606 (draft).

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

96

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________XDS defines a well focused set of primary attributes that support the most common use cases tosearch the most relevant documents. These include:
Patient Id
Service Start and Stop Time
Document Creation Time
Document Class Code and Display Name
Practice Setting Code and Display Name
Healthcare Facility Type Code and Display Name
Availability Status (Available, Deprecated)
Document Unique Id

2530

2535

The three codes (Document Class, Practice Setting and Healthcare facility Type) are code set thatare expected to generally include a limited number of values (between 10 and 100), thus ensuring areasonably easy search capability.
A number of additional query attributes or attributes used to perform a secondary selection in orderto decide to retrieve a specific document are also defined by this Integration Profile. At theDocument Level, these include a fine grained Document Type (e.g., LOINC classification), a list of
Event Code that can be used as key word, the document author and associated institution, thedocument relationship to manage replacement addendum and a variety of transformations, aconfidentiality code, language code, etc.
The complete list of attributes and their definition is documented in ITI TF-3: 4.1.

2540

10.4.8 Concept of an XDS Affinity Domain
An XDS Affinity Domain is an administrative structure made of a well-defined set of Document
Source Actors, set of Document Repositories, set of Document Consumers organized around asingle Document Registry Actor that have agreed to share clinical documents.

2545

2550

2555

Note:

Document Sources, Repositories and Consumers may belong to more than one XDS Affinity Domain and share thesame or different documents. This is an implementation strategy and will not be further described.

Note:

the XDS Integration Profile does not support the federation of XDS Affinity Domains directly, but the CrossCommunity Access (XCA) profile addresses the cooperation of multiple Document Registry Actors serving different
XDS Affinity Domains.

A number of policies will need to be established in an XDS Affinity Domain in order to ensure
effective interoperability between Document Sources and Consumers. Some of the key technicalpolicies include (A more extensive list of policy agreements that need to be made by XDS Affinity
Domains is discussed in ITI TF-1: Appendix L):
1.

The document formats that will be accepted for registration

2.

The various vocabulary value sets and coding schemes to be used for the submission of
metadata of document, submission set and folders registration.

3.

The Patient Identification Domain (Assigning Authority) used by the Document Registry.

See ITI TF-1: Appendix K for a detailed discussion of the concepts of XDS Affinity Domain.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

97

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
10.4.9 Patient Identification Management
2560

Since the central focus of the DS Integration Profile is “sharing documents”, it is critical that eachdocument be reliably associated with the corresponding patient (Patient Id).
The XDS Document Registry is not intended to be an authority for patient identification anddemographics information. This Integration Profile uses a Patient Identity Source Actor as theauthoritative source of Patient Identifiers (master patient ID) for the XDS Affinity Domain.
Note:

2565

This Integration Profile can be easily extended to support a scenario where no master patient ID is defined (i.e. no
Patient Identity Source for the XDS Affinity Domain). Such an option would require the use of federated patient
identities at the time of query of the XDS Document Registry.

The following principles are defined:
1.

The Patient Identifier Domain managed by the Patient Identity Source Actor in the XDS
Affinity Domain is the source of patient identifiers (and merge operations) used by the
XDS Document Registry to link Documents to a specific Patient. This Patient Identifier
Domain is called the XDS Affinity Domain Patient Identification Domain (XAD-Pid
Domain).

2.

Submission Requests for Documents related to Patients with IDs not registered in the XDS
Affinity Domain Patient Identifier Domain shall be rejected by the XDS Document
Registry.

3.

The XDS Document Registry will contain certain patient information (e.g., source patient
ID, Surname, Given Name, Sex, Birthdate) for the purpose of audits and potential
verification by Document Consumers. As this Integration Profile does not make any
assumptions about the referential integrity and update of this information, these fields 3
shall not be used as query matching keys.

4.

As XDS Document Sources and Consumers may belong to different Patient Identification
Domains, these systems need to cross-reference their own local Patient ID to thecorresponding patient ID in the XAD-Pid Domain of the Registry. Preferably, thesesystems may choose to use the IHE Patient Identifier Cross-referencing Integration Profile(See ITI TF-1: Appendix E.3) for this purpose.

5.

The XDS Document Registry is responsible for validating Document metadata inaccordance with the XDS Affinity Domain’s policies. The Document Registry should
reject submissions Requests that do not conform to these policies.

2570

2575

2580

2585

3

It is possible to submit a new document to replace a previously submitted one, with a new document entry
created in the registry to correct for errors in the submitted document in the original submission request. However thisis not a mechanism that updates only the metadata, as the replaced document is only deprecated and remains pointed by
the original metadata.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

98

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2590________________________________________________________________________________
The figure below depicts an example of an XDS Affinity Domain with its Patient Identifier Domain(called XAD) and two EHR-CRs where the cross-referencing is performed internally to theDocument Source and the Document Consumer Domains (Domain C and Domain D2 respectively).

Patient Identity
SourcePatient Identity Feed
Dm=XAD, Pid=Px

XDS Document
Registry

Dm=XAD
Pid=PxXDS Document
SourceXDS Doc Entry
Dm=XAD
Pid=PxXDS Doc Entry
Dm=XAD
Pid=Px
Dm=C
Pid=PcXDS Document
Consumer

Query

Provide &Register

XDSDoc

Dm=XAD
Pid=Px
Dm=D2
Pid=PdXDS Document
Repository

Patient
Identification
Domain D2

XDS Doc
Patient
Identification
Domain C
Patient
Identification
Domain XAD

Figure 10.4.9-1 XDS Affinity Domain with patient ID cross-referencing internal to the EHRCRs

2595
10.4.1010.4.10.1

Document Lifecycle
Document Availability Status

Each XDS Document contained in a XDS Document Registry will be assigned one of the following
Availability Status codes:
2600

Approved:

Available for patient care (assumes that it is authenticated, if applicable)

Deprecated:

Obsolete, but may still be queried and retrieved________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

99

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________The XDS Document availability status is set to “approved” after the XDS Document Repository
and the XDS Document Registry have successfully processed a submission request.
2605

2610

2615

Note:

ebXML Registry Services defines a Status of Submitted, which is used in a transient manner to provide an atomic
submission. It is not significant to make this specific status externally visible.

An “approved” XDS Document may be changed to “deprecated” under the primary responsibility of
its original Document Source with possible patient supervision. It is part of security policies thatare beyond the scope of the XDS Integration Profile to have the XDS Repository/Registry enforce
this ownership. The reason and responsible party for deprecating a document are tracked as part of
the XDS Document Registry audit trail, which is a required capability. A “deprecated” Document
remains available for Document Consumer queries. Except for the status change, a “deprecated”
Document Entry metadata remains the same as when it was in the “approved” status.
An “approved” or “deprecated” XDS Document Entry may be deleted. This change is associatedwith the decision to completely remove a Document from an XDS Document Repository and thecorresponding Document Entry from the XDS Document Registry. The XDS Affinity Domain
shall establish the security policies associated with Document deletion. There are no transactions
defined by this Integration Profile to support such operation.
See ITI TF-1: Appendix K for a detailed discussion of the concepts of XDS Document life cycle.
10.4.10.2

Document Relationships

2620

XDS Documents may be related to predecessor documents by one of three methods:• Replacement,• Addendum• Transformation• Transformation-Replacement

2625

2630

These relationships between XDS Documents are tracked in the XDS Document Registry. The
parent relationship attribute contained in the metadata of such Documents is a coded value that
describes the type of relationship. An original Document has no parent and consequently its parent
Id and parent relationship are absent. XDS Document Registry shall reject submissions that containrelationships to documents that are not registered or have been “deprecated”. Document stubs aresupported by XDS to allow for a valid relationship to a known but not registered Document.

2635

A replacement document is a new version of an existing document. The replacement document has
a new document Id; its parent Id attribute contains the document Id of the Document Entry
associated with the previous version of the XDS Document, and parent relationship contains thecode “RPLC”. The Document Entry for the previous version shall have its Availability Statuschanged to “deprecated”.

2640

An addendum is a separate XDS Document that references a prior document, and may extend oralter the observations in the prior document. It modifies the parent document, but the parent
document remains a valid component of the patient record and shall remain in the state “approved”
or available for care. The addendum XDS Document metadata contains the identifier of theprevious XDS Document version in parent Id, and its parent relationship contains the code
“APND”.
________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

100

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2645________________________________________________________________________________A transformed document is derived by a machine translation from some other format. Examples oftransformed documents could be CDA documents converted from DICOM Structured Reporting(SR) reports, or a rendering of a report into a presentation format such as PDF. The transform XDS
Document contains the document Id of the previous version in parentId, and its parent relationshipcontains the code “XFRM”. XDS Affinity Domains may define rules that determine whether or nota transformed XDS Document replaces the source, but typically this would not be the case. If it is,an additional parent relationship of type “RPLC” is to be used.
10.4.112650

Document Query

Query return info shall be either:• a list of Registry Objects Values (e.g., XDS Document Entries)• a list of Registry Objects UUIDs. This allows an XDS Document Consumer to receive apotentially long list of matching entries and to request them by subsets.

10.5 Implementation Strategies
2655

2660

2665

The XDS Integration profile addresses the requirements of three major implementation strategies
reflecting different groupings of actors within an EHR-CR as well as different configurations of the
EHR-LR. This range of implementation strategies reflects the need to accommodate a variety ofworkflows and configurations. These implementation strategies may coexist in some environments.
Other implementation strategies are possible.
• Strategy 1: Repository at the Source. A single information system acts as both the Document
Source and Document Repository for the documents it creates and registers with the Document
Registry• Upon completion of a phase of care, an EHR-CR will register a submission-set of documents in
a Document Repository Actor with which it is grouped (same system). Then it registers this setof documents (newly created and priors documents of interest) with the Document Registry
Actor [2].
• Any other Document Consumer Actor in the XDS Affinity Domain may query the Document
Registry Actor to find documents related to all phases of care for the patient [3]. It may choose
to retrieve some of these documents from any Document Repository Actor [4].
EHR-CR

EHR-CR
Document
Registry

2 Register
Document Source
Document
Repository

2670

3 Query

Document
Consumer

4 Retrieve

Figure 10.5-1 Implementation Strategy with Repository at the Source•

Strategy 2: Third Party Repository. The EHR-CR does not wish to be a Document Repository
Actor, but rather uses the services of a third party Document Repository Actor to which it________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

101

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2675

2680

________________________________________________________________________________
entrusts the documents it creates. First it provides both the metadata and the set of documents tothis Document Repository Actor [1], which in turn forwards the registration request for the setof documents (newly created and prior documents of interest) to the Document Registry Actor[2].
• Any other Document Consumer Actor may query the Document Registry Actor to find out
about documents related to all phases of care for the patient [3]. It may choose to retrieve someof these documents from any Document Repository Actor [4].
EHR-CR

EHR-CR
Document
Registry

3 Query

2 Register

Document Source

Document
Consumer

4 Retrieve

1 Provide &RegisterDocument
Repository

Figure 10.5-2 Implementation Strategy with 3rd party repository

EHR-CR

EHR-CR

Document
Registry

Document
ConsumerDocument
Repository

Document Source

1 Provide &Register

4 Retrieve

Figure 10.5-3 Implementation Strategy with 3rd party central repository and registry

2685
•
2690
•

2695

3 Query

Strategy 3: Direct Patient Transfer-Referral. The Document Source Actor completes a phase ofcare for a patient. It decides to directly provide and register [1] the set of documents (newly
created and prior documents of interest) with a Document Repository [2] that has been groupedalong with the Document Registry with the EHR-CR Document Consumer (Grouped Actors).
In this case the span of the XDS Affinity Domain may be quite limited as it could be defined tocover only the two EHR-CRs. However the same transaction [1] applies. Note that, in this
implementation strategy the other transactions, although supported by the actors, are not used by
the Document Consumer since the Document Registry and Document Repository reside within
the Document Consumer.

________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

102

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
EHR-CR
Document Source

EHR-CR

Document
ConsumerDocument
Registry

1 Provide & Register

Document
Repository

Figure 10.5-4 Direct patient referral with registry and repository at consumer

2700

Patient access to an EHR-LR may be supported by a specialized EHR-CR (i.e. a portal)
implementing the Document Source and Document Consumer Actors.

10.6 Patient Identifier Communication Requirements

2705

When using ITI Transaction 8 as the patient identity feed, ITI TF-2a: 3.8 defines the format
requirements for the patient identifier in PID-3. Specifically, the value for PID-3.4, Assigning
Authority can be omitted, expressed using the first subcomponent (namespace ID) or the second andthird subcomponents (universal ID and universal ID type). These rules shall apply in this profile:
1. If the Patient Identity Source does not include a value for PID-3.4, Assigning Authority,
thena. PID-3, Patient Identifier List, is constrained to include one entry referring to one
identifier.

2710

b. The Patient Identity Source and Document Registry shall agree that all messages
from this source shall refer to a single assigning authority.
2. If PID-3.4 does contain a value for PID-3.4, Assigning Authority, then

2715

2720

a. The Patient Identifier Source may send multiple patient identifiers with properly
formatted components. The Document Registry shall be responsible for selecting theone identifier from the Patient Identifier List (not necessarily in the first position)that is too used to register the selected patient.
b. As specified in ITI TF-2a: 3.8, the value for PID-3.4, Assigning Authority, can be
expressed using the first subcomponent (namespace ID) or the second and third
subcomponents (universal ID and universal ID type). Both methods shall be acceptedby the Document Registry and shall be considered as equivalent.
When using ITI Transaction 44 The Assigning Authority is required.

2725

ITI Transactions 18, 41 and 42 express patient ID as a string that is not parsed using typical HL7
parsing logic; please refer to requirements for Patient ID in those transactions. Document Registry
actors will have to map between the Patient ID feed provided in ITI-8 or ITI-44 as described above
and the PID provided by those transactions in this profile.
XDS.b implementations shall support either Patient Identity Feed (ITI TF-2a: 3.8) or Patient
Identity Feed HL7v3 (ITI TF-2b: 3.44) or both. It is important to note that the version of HL7________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

103

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2730________________________________________________________________________________
implemented by XDS.b and Patient Identity Feed in a single domain or community need to match inorder to allow interoperability. In the case of mixed scenarios, translation between Patient Identity
Feed (ITI TF-2a: 3.8) and Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) will be required via abridge or interface engine.

10.7 Security Considerations
2735

2740

Coordinating the security and privacy policies of all the care delivery organizations in an XDS
Affinity Domain may be a challenge. An agreement is needed on security procedures, goals,
auditing, record keeping, etc. This can result in changes to other enterprise policies, such as humanresources procedures. XDS Affinity Domain members are trusting to some extent the access of
their published data by other members of the XDS Affinity Domain. The level of control isdependent on Policies and application of other security and privacy profiles offered by IHE. This
relationship requires a close ongoing partnership that ensures ongoing maintenance of policies,
procedures, and activities. If laws change, relevant policies must be adjusted throughout the group.
Corporate changes to group members affect the policies. Security events must be managed as agroup. This must be managed as a long-term activity, not a one-time event.
Particular problem areas are likely to be:

2745

2750

2755

2760

•

Authorized access and modification policies. The details of access policies are likely tohave enterprise differences and conflicts that must be resolved. The XDS Affinity Domain
relationships also introduce new policy requirements. For example, changes to employment(e.g., employee hiring and firing) must now include suitably rapid notifications to other
XDS Affinity Domain members. (See ATNA and XUA)•

Changes to privacy restrictions (e.g., divorces) now require full XDS Affinity Domain
notifications, not merely enterprise notifications. (See BPPC)•

Audit trail and access record keeping are often quite sensitive internal enterprise activities
that must now be appropriately coordinated with the full XDS Affinity Domain. (See ATNA
and section 10.8.1)•

Changes to laws and regulations now affect not only the policies of the individual
enterprises; they also must be reflected in the XDS Affinity Domain relationship contracts,
policies, and procedures.

•Patient identity management. (See PIX/PDQ/XCPD)•

Patients may have access through an authorized Document Consumer or Document Source
implemented in an application such as a PHR.

•

Trans-border communication of Personal Health Information (PHI) often presents legal andregulatory issues.

ITI TF-2x: Appendix K goes into more detail listing many of the threats, objectives, policies, andmitigations that need to be coordinated among XDS Affinity Domain members.
2765

The XDS Integration Profile for two main reasons does not prescribe such Security and Privacy
policies. First, it is clear that the broad range of possible solutions to these policies that will dependon the legal framework and the types of healthcare system, calls for XDS to be offer such________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

104

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
flexibility. Decisions in this domain will have some impact on the implementations of XDS Actors,
but it is expected that these will be minimal.

2770

10.7.1 Use of ATNA to address Basic Security
The XDS profile requires all actors be grouped with a Secure Node Actor as defined in the IHE
Audit Trail and Node Authentication Integration profile. This use of the ATNA profile in an XDS
Affinity Domain does not require a centralized XDS Affinity Domain Audit Repository Actor.

2775

The use of ATNA along with XDS does require that each member of the XDS Affinity Domain
does have audit and security mechanisms in place. See ITI TF-2x: Appendix K.
The individual actors involved are often members of different secure domains, as illustrated in
Figure 3.14.5.1-2. The data transfers between different secure domains need different protection
than transfers within a secure domain. The transactions used between different secure domains
shall use the ATNA Encryption Option.

2780

2785

2790

Transfers within a single secure domain may choose to omit encryption if it is unnecessary, so it isrecommended 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.
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 to audit
records by other enterprises within the XDS Affinity Domain is managed and controlled by thebusiness relationship terms of the XDS Affinity Domain. There is no automatic IHE transaction forsuch access.
The audit records that shall be generated (references IHE ATNA Integration Profile) by normal
XDS activities are defined in the appropriate Security Considerations section of each transaction:________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

105

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles________________________________________________________________________________
Security Domain B
Repository
Registry
Encrypted,
S/MIME, Signed
if Offline
Encrypted,
TLS,
Authenticated if
OnlineSecurity Domain A
SourceSecurity Domain C
Comsumer

Repository

All Actors are part of the same Clinical Affinity Domain
Figure 10.7-1 - Example Security Domain Relationships

2795
Security and Privacy can be further addressed through the application of IHE-BPPC, IHE-XUA.
See these profiles for their impact and use.

10.8 Intentionally Left blank________________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

106

Copyright © 2011: IHE International, Inc.

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

3.18 Registry Stored Query
2205

2210

This section corresponds to Transaction 18 of the IHE Technical Framework. Transaction 18 isused by the Document Registry and Document Consumer actors.
Actors that support the Asynchronous Web Services Exchange option and implement theRegistry Stored Query transaction shall support the following:• Document Consumer Actor shall support Asynchronous Web Services Exchange for theRegistry Stored Query [ITI-18] and Retrieve Document Set [ITI-43] transactions• Document Registry Actor shall support Asynchronous Web Services Exchange for theRegistry Stored Query [ITI-18] and Register Document Set – b [ITI-42] transactions
Refer to section ITI TF-2x: V.5 Synchronous and Asynchronous Web Services Exchange for an
explanation of Asynchronous Web Services Exchange.

2215

3.18.1 Scope
The Registry Stored Query transaction supports a variety of types of queries. Examples include
the following:
Query by patient (Id) for a time interval, by document type(s), by practice setting(s), by author
person2220

Query by Document Source
Query for XDS Folders updated during a time interval
Query for all documents in a Folder or Submission Set
Query by time of submission

2225

The list of XDS registry entries attributes that can be the target of a query are defined in ITI TF3: 4.1.7 through 4.1.9. This transaction will document the basic syntax and semantics of XDS
Document Registry queries.
All queries return:• Metadata for one or more registry objects, or• Object references for one or more registry objects (registry UUIDs).

2230

3.18.2 Use Case Roles
Document
ConsumerDocument
Registry

Initiating
Gateway

Registry Stored
Query

Actor: Document Consumer___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

97

Copyright © 2011 IHE International, Inc.

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

2235

Role: Requests a query by identifier (UUID), and passes parameters to the query. A parameter
controlling the format of the returned data is passed, it selects either object references or fullobjects.
Actor: Document Registry
Role: Services the query using its stored definitions of the queries defined for XDS.
Actor: Initiating Gateway

2240

Role: Services the stored query by initiating transactions with a selected set of Responding
Gateways, Document Registries or other appropriate systems.
3.18.3 Referenced Standards
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.

2245
ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

3.18.4 Interaction Diagram
Document
ConsumerDocument
Registry
Registry Stored Query

Registry Stored Query
Acknowledgment2250

3.18.4.1 Registry Stored Query

2255

This is a query request to the Document Registry from a Document Consumer. The query request
contains:• A reference to a pre-defined query stored on the Document Registry actor.
• Parameters to the query. The query parameters are matched up with the query variables
defined in the query definition on the Document Registry actor.
3.18.4.1.1 Trigger Events
This message is initiated when the Document Consumer wants to query/retrieve document
metadata.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

98

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2 Message Semantics
2260

The semantics of Stored Query are defined in section 6.3. Stored Query Support of ebRS version
3.0. This transaction corresponds to section 6.3.2 Invoking a Stored Query and 6.3.3 Response toa Stored Query Invocation. This profile does not specify how the queries come to be stored in theRegistry actor nor how they are to be translated for other database architectures.
3.18.4.1.2.1 Version 3.0 ebXML Registry Standard

2265

2270

2275

2280

This transaction uses ebXML Registry version 3.0. The Invoke Stored Query message and the
Invoke Stored Query Acknowledgement message shall be in version 3.0 format and be consistent
with version 3.0 ebRIM and ebRS standards.
Version 3.0 ebXML Registry XML Schemas shall be used to validate the messages of thistransaction. The major differences between version 2.1 and 3.0 of the Schema are:• Different XML namespaces• LeafRegistryObjectList element becomes RegistryObjectList• ObjectType attribute changes format, changing from a text name to a UUID. For example,
RegistryPackage becomes urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:RegistryPackage• Status attribute value format changes from Approved to urn:oasis:names:tc:ebxmlregrep:StatusType:Approved• Order of elements changes – Name, Description, Slot, Classification, ExternalIdentifierordering becomes Slot, Name, Description, Classification, ExternalIdentifier.
• Id attribute is required for Classification, ExternalIdentifier, and Association• The registryObject attribute is required on the ExternalIdentifier element.
• Association Types must be namespace qualified. For details see ITI TF-3: 4.1.6.3
Association type formatting.
It is the responsibility of the Document Registry actor to translate between version 2.1 andversion 3.0 formats when returning v2.1 objects in v3.0 query responses.

2285

3.18.4.1.2.2 Sample Query Request
The sample query is included under the ITI TF-2a: 3.18.4.1.3 Expected Actions.
3.18.4.1.2.3 Query Request Parameters – Coding Style

2290

The ebXML Registry stored query facility (Invoke Stored Query transaction) accepts thefollowing parameters:• returnType – ‘LeafClass’ or ‘ObjectRef’• Query ID – a UUID from the Stored Query IDs section (ITI TF-2a: 3.18.4.1.2.4) below• Query Parameters – as defined in the Query Parameters section (ITI TF-2a: 3.18.4.1.2.3.7)
below___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19

99

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.3.1 Parameter returnType
2295

2300

2305

2310

Registry Stored Query supports the following values for the parameter returnType:• ObjectRef – a list of object UUIDs (references)• LeafClass – list of XML elements representing the leaf class of the object returned
The ‘LeafClass’ returnType is meant for returning a small amount of fully specified ebXML
objects (such as a list of ExtrinsicObject (XDSDocumentEntry) elements with full contents:
slots, external identifiers, classifications etc.). This type of query result is self-contained,
everything known about the object(s) is returned. The specific query documented in this section
describes which object types will be included. ObjectRef elements are also returned. These
represent objects not included in the returned object list that are referenced by objects in the
returned object list. These ObjectRefs are optional by the registry standard version 3.0.
The 'ObjectRef' returnType returns references to the registry objects that match the query. This
type query is recommended when the returned object list could be large. An initial query
returning ObjectRefs for all objects of interest followed by secondary queries requesting full
metadata (query type LeafClass) is an efficient way to query for large bodies of metadata. This
strategy is particularly easy to use when querying for a single object type (XDSDocumentEntry
or XDSSubmissionSet are examples) since only a single object type is involved.
An ObjectRef looks like:<ObjectRef id=”urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427”/>

3.18.4.1.2.3.2 Parameter Query ID
2315

This parameter holds the UUID assigned to the query to be invoked. UUIDs are assigned by thisprofile (see ITI TF-2a: 3.18.4.1.2.4) to each of the queries defined in ITI TF-2a: 3.18.4.1.2.3.7.
3.18.4.1.2.3.3 Date/Time Coding
All Date/time values are to be inclusive, interpreted as:$XDSDocumentEntryCreationTimeFrom <= XDSDocumentEntry.creationTime <$XDSDocumentEntryCreationTimeTo

2320

for example. The ‘From’ time or the ‘To’ time may be omitted.
3.18.4.1.2.3.4 Coding of Code/Code-Scheme

2325

When specifying a coded value parameter, an abbreviated form of the HL7 V2.5 CE format shallbe used. Only the first (identifier) and third (coding scheme) elements shall be specified. Bothare required. The second element shall be empty. The HL7 V2.5 length limits shall not apply.
The ebRIM limit on Slot Value size does apply. An example of this format is:code^^coding-scheme
This style parameter always accepts multiple values so example codings in context look like:<Value>('code1^^coding-scheme1')</Value>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

100

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
or
2330<Value>('code1^^coding-scheme1','code2^^coding-scheme2')</Value>
within the parameter Slot.
3.18.4.1.2.3.5 Coding of Single/Multiple Values

2335

2340

Single values are coded as• 123 - without quotes for numbers• ‘urn:oasis:names:tc:ebxml-regrep:StatusType:Approved’ - in single quotes for strings.
• ‘Children’’s Hospital’ – a single quote is inserted in a string by specifying two single quotes
Within the LIKE predicate• Underscore (‘_’) matches an arbitrary character• Percent (‘%’) matches an arbitrary string
Format for multiple values is• (value, value, value, …) OR• (value) if only one value is to be specified.
where each value is coded as described above for single values.

2345

2350

When coding multiple values there is a potential conflict between needing to code a long list ofvalues and the length restriction imposed by Schema on the size of the value of the <Value/>element. Slot values shall never exceed the Schema-enforced limit. Therefore, the use of multiple
Value elements within the Slot shall be acceptable. Splits may occur only between values, where
each Value element is surrounded by parentheses. The following example shows multiple values,
split across multiple Value elements:<Slot name="$uuid"><ValueList><Value>('urn:uuid:a96d7361-6617-488a-891c-ee3f37d1f218','urn:uuid: 5655a680-1b6a11dd-bd0b-0800200c9a66')</Value>

2355<Value>('urn:uuid:ae315e81-2056-4829-a5b4-cf9531941f96')</Value></ValueList></Slot>This example shall be treated as equivalent to:<Slot name="$uuid">

2360<ValueList>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

101

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________<Value>('urn:uuid:a96d7361-6617-488a-891c-ee3f37d1f218','urn:uuid: 5655a680-1b6a11dd-bd0b-0800200c9a66','urn:uuid:ae315e81-2056-4829-a5b4-cf9531941f96')</Value></ValueList></Slot>2365

Character comparisons shall be performed in accordance with the rules in 4.2.
And/or semantics for the coding of parameters shall be available only on parameters for multivalued metadata elements (such as $XDSDocumentEntryEventCodeList). Multi-valued
parameters shall be coded in two ways with different interpretations.

2370

2375

A parameter specified as a Slot with multiple values shall be interpreted as disjunction (ORsemantics). For example:<rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('a')</rim:Value><rim:Value>('b')</rim:Value></rim:ValueList></rim:Slot>

shall match an XDSDocumentEntry object with an eventCodeList attribute containing either 'a'
or 'b'. The following coding of the parameter shall yield the same results:
2380

2385

2390
2395

<rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('a','b')</rim:Value></rim:ValueList></rim:Slot>

A parameter specified as multiple Slots shall be interpreted as conjunction (AND semantics). For
example:<rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('a')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('b')</rim:Value></rim:ValueList></rim:Slot>

shall match an XDSDocumentEntry object with an eventCodeList attribute containing both 'a'and 'b'.
Furthermore, the following specification of the $XDSDocumentEntryEventCodeList parameter:
2400
2405

<rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('a','b')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryEventCodeList"><rim:ValueList><rim:Value>('c')</rim:Value></rim:ValueList></rim:Slot>

shall be interpreted as matching a document having eventCode (a OR b) AND c.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

102

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
2410

3.18.4.1.2.3.6 Valid Document Status Values
The Registry Object status values, in ebRIM v 3.0 format, used by XDS are:urn:oasis:names:tc:ebxml-regrep:StatusType:Submitted
urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated2415

If the Document Registry receives in a Registry Stored Query transaction a value for the$XDSDocumentEntryStatus parameter that it does not understand then the Document Registry
shall ignore the value and process the Registry Stored Query transaction as if the not understoodvalue were not specified. This means that if the only value present is one that is not understood
an error will be generated because the $XDSDocumentEntryStatus parameter is required.

2420

3.18.4.1.2.3.6.1 Valid AdhocQueryResponse Status Values
The status attribute of AdhocQueryResponse 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

2425

See ITI TF-3: 4.1.13 Error Reporting for the interpretation of these values.
3.18.4.1.2.3.7 Parameters for Required Queries

2430

The sections below document the queries defined in the Registry Stored Query transaction [ITI18]. These sections document a collection of Stored Queries. Document Registry actors
implementing this transaction shall support all queries in this collection and all parameters
defined for each query. Document Consumer actors implementing this transaction shall
implement one or more of these queries as needed to support the use cases it implements.
Note that dollar sign ($) prefix on query parameters is required by ebRS 3.0.

2435

In the query parameter tables below, each row represents a query parameter. Optional parameterswhich are not included in the query invocation have no effect on the query. Queries return
registry objects that match all the supplied parameters. When multiple values are included for aparameter, objects are returned that match any included value (within the context of the larger
query).
3.18.4.1.2.3.7.1 FindDocuments

2440

Find documents (XDSDocumentEntry objects) in the registry for a given patientID with amatching ‘status’ attribute. The other parameters can be used to restrict the set of
XDSDocumentEntry objects returned.
Returns: XDSDocumentEntry objects matching the query parameters
Parameter Name

Attribute

Opt

Mult

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

103

Copyright © 2011 IHE International,

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

Opt

Mult

XDSDocumentEntry. patientId

AttributeR--

XDSDocumentEntry. classCodeO

M$XDSDocumentEntryTypeCode

XDSDocumentEntry.typeCodeO

M$XDSDocumentEntryPracticeSettingCode1

XDSDocumentEntry.
practiceSettingCodeO

M$XDSDocumentEntryCreationTimeFrom

Lower value of
XDSDocumentEntry.
creationTimeO--$XDSDocumentEntryCreationTimeTo

Upper value of
XDSDocumentEntry.
creationTimeO--$XDSDocumentEntryServiceStartTimeFrom

Lower value of
XDSDocumentEntry.
serviceStartTimeO--$XDSDocumentEntryServiceStartTimeTo

Upper value of
XDSDocumentEntry.
serviceStartTimeO--$XDSDocumentEntryServiceStopTimeFrom

Lower value of
XDSDocumentEntry.
serviceStopTimeO--$XDSDocumentEntryServiceStopTimeTo

Upper value of
XDSDocumentEntry.
serviceStopTimeO--$XDSDocumentEntryHealthcareFacilityTypeCode1

XDSDocumentEntry.
healthcareFacilityTypeCodeO

M$XDSDocumentEntryEventCodeList1

XDSDocumentEntry.
eventCodeList3O

M$XDSDocumentEntryConfidentialityCode1

XDSDocumentEntry.
confidentialityCode3O

M$XDSDocumentEntryAuthorPerson4

XDSDocumentEntry. author

O

M$XDSDocumentEntryFormatCode

XDSDocumentEntry. formatCodeO

M$XDSDocumentEntryStatus

XDSDocumentEntry. statusR

M$XDSDocumentEntryPatientId$XDSDocumentEntryClassCode1
1

1

2445

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.

4

2450

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)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

104

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.3.7.2 FindSubmissionSets
2455

Find submission sets (XDSSubmissionSet objects) in the registry for a given patientID withmatching ‘status’ attribute. The other parameters can be used to restrict the collection of
XDSSubmissionSet objects returned.
Returns: XDSSubmissionSet objects matching the query parameters
Opt

Mult

$XDSSubmissionSetPatientId

Parameter NameXDSSubmissionSet. patientId

AttributeR--$XDSSubmissionSetSourceId

XDSSubmissionSet. sourceId

O

M$XDSSubmissionSetSubmissionTimeFrom

XDSSubmissionSet.
submissionTime Lower valueO--$XDSSubmissionSetSubmissionTimeTo

XDSSubmissionSet.
submissionTime Upper valueO--$XDSSubmissionSetAuthorPerson1

XDSSubmissionSet. authorPersonO--$XDSSubmissionSetContentType2

XDSSubmissionSet.
contentTypeCodeO

M$XDSSubmissionSetStatus

XDSSubmissionSet. status

R

M

1

2460

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

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.
3.18.4.1.2.3.7.3 FindFolders
2465

Find folders (XDSFolder objects) in the registry for a given patientID with matching ‘status’
attribute. The other parameters can be used to restrict the collection of XDSFolder objects
returned.
Returns: XDSFolder objects matching the query parameters
Parameter Name

Attribute

Opt

Mult

$XDSFolderPatientId

XDSFolder.patientId

R--$XDSFolderLastUpdateTimeFrom

XDSFolder. lastUpdateTime
lower valueO--$XDSFolderLastUpdateTimeTo

XDSFolder. lastUpdateTime
upper boundO--$XDSFolderCodeList1,3

XDSFolder. codeListO

M$XDSFolderStatus

XDSFolder.status

R

M

1

2470

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.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

105

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.3.7.4 GetAll
Get all registry content for a patient given the indicated status, format codes, and confidentiality
codes.
2475

Returns:• XDSSubmissionSet, XDSDocumentEntry, and XDSFolder objects with patientId attributematching $patientId parameter• Association objects with sourceObject or targetObject attribute matching one of the above
objects
Parameter Name

Attribute

Mult

R

--

$patientId

XDSFolder. patientId,
XDSSubmissionSet. patientId,
XDSDocumentEntry. patientId$XDSDocumentEntryStatus

XDSDocumentEntry. statusR

M$XDSSubmissionSetStatus

XDSSubmissionSet. statusR

M

XDSFolder. statusR

M$XDSDocumentEntryFormatCode

XDSDocumentEntry. formatCodeO

M$XDSDocumentEntryConfidentialityCode1, 2

XDSDocumentEntry.
confidentialityCode1O

M$XDSFolderStatus
2

2480

Opt

1

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

2

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme
3.18.4.1.2.3.7.5 GetDocuments
2485

Retrieve a collection of XDSDocumentEntry objects. XDSDocumentEntry objects are selected
either by their entryUUID or uniqueId attribute.
Returns: XDSDocumentEntry objects requested
Parameter Name$XDSDocumentEntryEntryUUID$XDSDocumentEntryUniqueId33$homeCommunityId

Attribute

Opt

XDSDocumentEntry. entryUUID

1

Mult

O

M

XDSDocumentEntry. uniqueId

1

O

M

None

O2

--

1

Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified.
This transaction shall return an error if both parameters are specified.
2

2490

2495

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this
attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of
Document metadata duplication for explanation.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

106

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested DocumentEntry objects to be returned will contain the same Patient ID.
If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata
shall be returned.
2500
3.18.4.1.2.3.7.6 GetFolders
Retrieve a collection of XDSFolder objects. XDSFolder objects are selected either by theirentryUUID or uniqueId attribute.
Returns: XDSFolder objects requested.
Parameter Name

Attribute

3$XDSFolderEntryUUID$XDSFolderUniqueId$homeCommunityId

2505

Mult

1

O

M

XDSFolder. uniqueId

1

O

M

None

O2

--

XDSFolder. entryUUID

3

Opt

1

Either $XDSFolderEntryUUID or $XDSFolderUniqueId shall be specified. This transaction
shall return an error if both parameters are specified.
22510

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this
attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
32515

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested DocumentEntry objects to be returned will contain the same Patient ID.
If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata
shall be returned.
3.18.4.1.2.3.7.7 GetAssociations
Retrieve Association objects whose sourceObject or targetObject attribute match $uuid.
Returns: Association objects
Parameter Name

Attribute

Opt

Mult

$uuid

None

R

M

$homeCommunityId

None

O1

-

1

2520

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” … >.
Document Consumer actors shall specify the homeCommunityId value if they received a value
for this attribute as part of the previous Registry Stored Query response entry which contained
the specified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

107

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.3.7.8 GetDocumentsAndAssociations
2525

2530

Retrieve a collection of XDSDocumentEntry objects and the Association objects surrounding
them. XDSDocumentEntry objects are selected either by their entryUUID or uniqueId attribute.
This is the GetDocuments query and GetAssociations query combined into a single query.
Returns:• XDSDocumentEntry objects• Association objects whose sourceObject or targetObject attribute matches one of the above
objects
Parameter Name$XDSDocumentEntryEntryUUID3$XDSDocumentEntryUniqueId3$homeCommunityId

Attribute

Opt

XDSDocumentEntry. entryUUID

1

O

M

XDSDocumentEntry. uniqueId

O1

M

2

--

None

O

Mult

1

Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified.
This transaction shall return an error if both parameters are specified.
22535

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this
attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
32540

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested DocumentEntry objects to be returned will contain the same Patient ID.
If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata
shall be returned.
3.18.4.1.2.3.7.9 GetSubmissionSets

2545

2550

Retrieve the XDSSubmissionSet objects used to submit a collection of XDSDocumentEntry and
XDSFolder objects. The XDSDocumentEntry and XDSFolder objects of interest are identified
by their UUIDs in the $uuid parameter.
Selection: XDSSubmissionSet objects are selected because Association objects exist that have:• Type HasMember• targetObject attribute containing one of the UUIDs provided in the $uuid parameter• sourceObject attribute referencing an XDSSubmissionSet object
Returns:• XDSSubmissionSet objects described above• Association objects described in the Selection section above
Parameter Name$uuid2Attribute

Opt

Mult

XDSDocumentEntry. entryUUID
and

R

M

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

108

Copyright © 2011 IHE International,

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

Attribute

Opt

Mult

O1

--

XDSFolder. entryUUID$homeCommunityId

None

1

2555

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” … >.
Document Consumer actors shall specify the homeCommunityId value if they received a value
for this attribute as part of the previous Registry Stored Query response entry which contained
the specified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
22560

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested Submission Set objects to be returned will contain the same Patient ID.
If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata
shall be returned.
3.18.4.1.2.3.7.10 GetSubmissionSetAndContents

2565

2570

2575

2580

Retrieve a SubmissionSet and its contents. SubmissionSet objects is selected either by its
entryUUID or uniqueId attribute. The DocumentEntry objects returned may be constrained bytheir formatCode and confidentialityCode attributes. More specifically, the DocumentEntries
returned shall be limited by the following rules:• If the $XDSDocumentEntryConfidentialityCode parameter is present in the query, thenDocumentEntries shall be returned only if they match this parameter.
• If the $XDSDocumentEntryFormatCode parameter is present in the query, thenDocumentEntries shall be returned only if they match this parameter
Returns:• SubmissionSet identified• DocumentEntries linked to the SubmissionSet by HasMember Associations(DocumentEntries shall pass the above rules)• The HasMember Associations identified in the previous rule
• Folders linked to the SubmissionSet by HasMember Associations• The HasMember Associations identified in the previous rule
• Associations linked to the SubmissionSet by HasMember Associations where the
Associations link two objects already in the return set• The HasMember Associations identified in the previous rule
In the above rules, Associations are only returned if both of the objects they connect are part of
the return set.

2585
Parameter Name

Attribute

5

Opt
1

Mult

$XDSSubmissionSetEntryUUIDXDSSubmissionSet. entryUUIDO--$XDSSubmissionSetUniqueId5

XDSSubmissionSet. uniqueId

O1--___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

109

Copyright © 2011 IHE International,

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

Opt

Mult

$XDSDocumentEntryFormatCode4

Parameter NameXDSDocumentEntry. formatCodeO

M$XDSDocumentEntryConfidentialityCode4

XDSDocumentEntry.
confidentialityCode2O

M$homeCommunityId

None

O3

--

1

Either $XDSSubmissionSetEntryUUID or $XDSSubmissionSetUniqueId shall be specified.
This transaction shall return an error if both parameters are specified.
2

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

3

2590

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this
attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
42595

Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.
5

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested Submission Set, Folder, and DocumentEntry objects to be returned willcontain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be
returned and no metadata shall be returned.

2600

2605

2610

2615

3.18.4.1.2.3.7.11 GetFolderAndContents
Retrieve a Folder and its contents. The Folder object is selected either by its entryUUID or
uniqueId attribute. The DocumentEntry objects returned may be constrained by their formatCodeand confidentialityCode attributes. More specifically, the DocumentEntries shall shall be limitedby the following rules:• If the $XDSDocumentEntryConfidentialityCode parameter is present in the query, thenDocumentEntries shall be returned only if they match this parameter.
• If the $XDSDocumentEntryFormatCode parameter is present in the query, thenDocumentEntries shall be returned only if they match this parameter
Returns:• Folder identified• DocumentEntries linked to the Folder by HasMember Associations (DocumentEntries shallpass the above rules)• The HasMember Associations identified in the previous rule
In the above rules, Associations are only returned if both of the objects they connect are part of
the return set.
Parameter Name

Attribute

5$XDSFolderEntryUUIDXDSFolder. entryUUID

Opt
1

O

Mult
--

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

110

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Opt

Mult

$XDSFolderUniqueId5

Parameter NameXDSFolder. uniqueId

Attribute

O1--$XDSDocumentEntryFormatCode4

XDSDocumentEntry. formatCodeO

M$XDSDocumentEntryConfidentialityCode4

XDSDocumentEntry.
confidentialityCode2O

M$homeCommunityId

None

O3

--

1

Either $XDSFolderEntryUUID or $XDSFolderUniqueId shall be specified. This transaction
shall return an error if both parameters are specified.
2

2620

3

2625

4

Supports AND/OR semantics as specified in ITI TF-2a: 3.18.4.1.2.3.5.

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” … >.
Document Consumer actors shall specify the homeCommunityId value if they received a value
for this attribute as part of the previous Registry Stored Query response entry which contained
the specified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
Shall be coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/CodeScheme.
52630

If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shallverify that all requested Folder, and DocumentEntry objects to be returned will contain the same
Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no
metadata shall be returned.
3.18.4.1.2.3.7.12 GetFoldersForDocument
Retrieve XDSFolder objects that contain the XDSDocumentEntry object provided with thequery. XDSDocumentEntry objects are selected either by their entryUUID or uniqueId attribute.

2635

Returns: XDSFolder objects that contain specified XDSDocumentEntry object. Morespecifically, for each Association object of type HasMember that has a targetObject attributereferencing the target XDSDocumentEntry object, return the object referenced by its
sourceObject if it is of type XDSFolder.
Parameter Name$XDSDocumentEntryEntryUUID

Attribute

Opt

XDSDocumentEntry. entryUUID

1

Mult

O

--

1

$XDSDocumentEntryUniqueId

XDSDocumentEntry. uniqueId

O--$homeCommunityId

None

O2

--

1

2640

Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified.
This transaction shall return an error if both parameters are specified.
2

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

111

Copyright © 2011 IHE International,

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

2645

attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of
Document metadata duplication for explanation.

3.18.4.1.2.3.7.13 GetRelatedDocuments
2650

2655

Retrieve XDSDocumentEntry objects that are related to the specified document via Association
objects. Also return the Association objects. The specified document is designated by UUID or
uniqueId. The query shall return• Association objects where:• The sourceObject attribute OR the targetObject attribute references the specified
document AND• Both sourceObject attribute and targetObject attribute reference documents AND• The associationType attribute matches a value included in the $AssociationTypes
parameter• XDSDocumentEntry objects referenced by the targetObject attribute OR the sourceObject
attribute of an Association object matched above.

2660

Note: A side effect of the query is that the specified document is returned in the results if at least one Association isreturned.
Note: A side effect of this query is that if the document specified by the $XDSDocumentEntryUUID or$XDSDocumentEntryUniqueId parameters has no associations linking it to other documents, then no documents
and no associations are returned.

2665

See ITI TF-3: 4.1.6 Document Relationships and Associations for background.
Returns: Association objects and related XDSDocumentEntry objects
Given : An XDSDocumentEntry object and a collection of association types.
Attribute

Opt

Mult

$XDSDocumentEntryEntryUUIDParameter NameXDSDocumentEntry. entryUUIDO1--$XDSDocumentEntryUniqueId

XDSDocumentEntry. uniqueId

O1--$AssociationTypes

Not a named attributeRM$homeCommunityId

None

O2

--

1

2670

Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified.
This transaction shall return an error if both parameters are specified.
2

2675

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” … >. Document
Consumer actors shall specify the homeCommunityId value if they received a value for this
attribute as part of the previous Registry Stored Query response entry which contained thespecified EntryUUID or UniqueID. See ITI TF-2a: 3.18.4.1.2.3.8 for more details.
Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of
Document metadata duplication for explanation.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

112

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.3.8 Use of homeCommunityId
2680

2685

2690

2695

2700

2705

The Registry Stored Query makes use of the homeCommunityId which is a globally unique
identifier for a community and is used to obtain the Web Services endpoint of services thatprovide access to data in that community. homeCommunityId is structured as an OID limited to
64 characters and specified in URI syntax, for example the homeCommunityId of 1.2.3 would beformatted as urn:oid:1.2.3.

Its use is as follows:• It is returned within the response to Registry Stored Query and Cross Gateway Query
transactions to indicate the association of a response element with a community. It is
specified as the ebRIM 'home' attribute within the ExtrinsicObject, RegistryPackage andObjectRef elements. Document Consumers process the value as an opaque unique identifier.
• It is an optional parameter to Registry Stored Query requests, not requiring a patient id
parameter, and Retrieve Document Set requests to indicate which community to direct therequest.

For stored queries which do not require the patient id as a parameter , meaning query by
EntryUUID or UniqueID:• If the Registry Stored Query is being addressed to an Initiating Gateway then the Document
Consumer may have previously sent a Registry Stored Query to the Initiating Gateway which
included a patient id and saved the homeCommunityId which was returned on the element
containing the EntryUUID or uniqueID. If this is not the case the Document Consumer shallhave access to the correct homeCommunityId through some other means.
• If the Document Consumer received the EntryUUID or uniqueID in a previous Registry
Stored Query response which contained a homeCommunityId, then the Document Consumer
shall specify the homeCommunityId parameter.
• The homeCommunityId value is specified as the home attribute on the AdhocQuery elementof the query request, as in:<AdhocQuery id=”…” home=”urn:oid:1.2.3” … >• Each query request can have at most one homeCommunityId value. If the Document
Consumer specifies multiple entryUUID or uniqueID values they must all be associated withthe same homeCommunityId value. Multiple individual query requests can be used toretrieve data associated with different homeCommunityIds.
3.18.4.1.2.4 Stored Query IDs

2710

2715

The standard XDS queries are assigned the following Query IDs. These IDs are used in the
AdhocQueryRequest to reference queries stored on the Document registry actor. Query IDs are
in UUID format (RFC4122). An error shall be returned when an unsupported stored query ID is
received.
Note: This query mechanism can be extended by adding a query by allocating a Query ID, defining query parameters, andimplementing the query in the Document Registry.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

113

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Query Name
FindDocuments
FindSubmissionSets
FindFolders
GetAllGetDocuments
GetFolders
GetAssociations
GetDocumentsAndAssociations
GetSubmissionSets
GetSubmissionSetAndContents
GetFolderAndContents
GetFoldersForDocument
GetRelatedDocuments

Query ID
urn:uuid:14d4debf-8f97-4251-9a74a90016b0af0d

urn:uuid:f26abbcb-ac74-4422-8a30edb644bbc1a9
urn:uuid:958f3006-baad-4929-a4deff1114824431
urn:uuid:10b545ea-725c-446d-9b958aeb444eddf3
urn:uuid:5c4f972b-d56b-40ac-a5fcc8ca9b40b9d4
urn:uuid:5737b14c-8a1a-4539-b659e03a34a5e1e4
urn:uuid:a7ae438b-4bc2-4642-93e9be891f7bb155

urn:uuid:bab9529a-4a10-40b3-a01ff68a615d247a
urn:uuid:51224314-5390-4169-9b91b1980040715a
urn:uuid:e8e3cb2c-e39c-46b9-99e4c12f57260b83
urn:uuid:b909a503-523d-4517-8acf8e5834dfc4c7
urn:uuid:10cae35a-c7f9-4cf5-b61efc3278ffb578
urn:uuid:d90e5407-b356-4d91-a89f873917b4b0e6

3.18.4.1.2.5 Intentionally Left Blank
3.18.4.1.2.6 Managing Large Query Responses
2720

EbXML version 3.0 supports query results pagination (ebRS version 3.0 chapter 6.2). Theinteractions between the stored query capability and the query results pagination capability
within the standard have never been reconciled and are not recommended for use together. It is
recommended instead that query pagination be implemented within the Document Consumer
actor.

2725

This can be accomplished by specifying returnType=”ObjectRef” on all large queries. This
returns a list of references (UUIDs) instead of full objects (large XML structures). This ispractical for queries returning thousands of objects. To construct a page for display, a small
number of objects can be retrieved through a second query. This is repeated for each page. As an
example, the following sequence of queries could be used to list a large number of documents:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

114

Copyright © 2011 IHE International,

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

•
•

FindDocuments query with returnType=”ObjectRef” which returns a large collections of
ObjectRefs (UUIDs)
GetDocuments query with returnType=”LeafClass” issued with a subset of the above
returned UUIDs which returns the details to construct one page of listing

OR
2735

GetDocumentsAndAssocations query with returnType=”LeafClass” issued with a subset of theabove returned UUIDs which returns the details to construct one page of listing. By retrieving
the Association objects, the existence of document replacement, transformation, and amendment
can be included into the display.
3.18.4.1.2.7 Web Services Transport

2740

2745

The query request and response will be transmitted using Web Services, according to therequirements specified in ITI TF-2x: Appendix V. The specific values for the WSDL describing
the Stored Query Service are described in this section.
The Document Registry actor shall accept a Registry Stored Query Request formatted as a
SIMPLE SOAP message and respond with a Registry Stored Query Response formatted as a
SIMPLE SOAP message. The Document Consumer actor shall generate the Registry Stored
Query Request formatted as a SIMPLE SOAP message and accept a Registry Stored Query
Response formatted as a SIMPLE SOAP message.
IHE-WSP201) The attribute /wsdl:definitions/@name shall be “DocumentRegistry”.

2750

2755

The following WSDL naming conventions shall apply:

wsdl:definitions/@name="DocumentRegistry":
query message-> "RegistryStoredQuery_Message"
query response-> "RegistryStoredQuery_Response_Message"
portType-> "DocumentRegistry_PortType"operation-> "RegistryStoredQuery"
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”
2760

2765

Document Registry: These are the requirements for the Registry Stored Query transaction
presented in the order in which they would appear in the Document Registry WSDL definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0",
schemaLocation="query.xsd"• The /definitions/message/part/@element attribute of the Registry Stored Query Request
message shall be defined as “query:AdhocQueryRequest”• The /definitions/message/part/@element attribute of the Registry Stored Query Response
message shall be defined as “query:AdhocQueryResponse”• Refer to Table 3.18.4.1.2.7.ba below for additional attribute requirements___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

115

Copyright © 2011 IHE International,

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

2770

•

To support the Asynchronous Web Services Exchange option on the Document Consumer,
the Document Registry shall support the use of a non-anonymous response EPR in the WSAddressing replyTo header.
Table 3.18.4.1.2.7.ba Additional Attribute Requirements

2775

2780
2785
2790
2795
2800
2805

2810

Attribute

Value/definitions/portType/operation@name

DocumentRegistry_ RegistryStoredQuery/definitions/portType/operation/input/@wsaw:Action

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

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

Urn:ihe:iti:2007: RegistryStoredQuery

The following WSDL fragment shows an example of Registry Stored Query transaction
definition:<?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"/>...
</xsd:schema></types><message name="RegistryStoredQuery_Message"><documentation>Registry Stored Query</documentation><part name="body" element="query:AdhocQueryRequest"/></message><message name="RegistryStoredQueryResponse_Message"><documentation>Registry Stored Query Response</documentation><part name="body" element="query:AdhocQueryResponse"/></message>...
<portType name="DocumentRegistry_PortType"><operation name="DocumentRegistry_RegistryStoredQuery"><input message="ihe:RegistryStoredQuery_Message"
wsaw:Action="urn:ihe:iti:2007:RegistryStoredQuery"/><output message="ihe:RegistryStoredQueryResponse_Message"
wsaw:Action="urn:ihe:iti:2007:RegistryStoredQueryResponse"/></operation>...
</portType>...
</definitions>

A full WSDL for the Document Repository and Document Registry actors is found in ITI TF-2x:
Appendix W.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

116

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.18.4.1.2.7.1 Sample SOAP Messages

2815

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

2820

3.18.4.1.2.7.1.1 Sample Registry Stored Query SOAP Request
3.18.4.1.2.7.1.1.1 Synchronous Web Services Exchange

2825
2830
2835
2840
2845
2850
2855
2860
2865

<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:RegistryStoredQuery</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/IHEXDSRegistry.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"/><rim:AdhocQuery id=" urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d "><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="$XDSDocumentEntryStatus"><rim:ValueList><rim:Value>('urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Approved')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeFrom"><rim:ValueList><rim:Value>200412252300</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeTo"><rim:ValueList><rim:Value>200501010800</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode"><rim:ValueList><rim:Value>(‘Emergency Department’)</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></query:AdhocQueryRequest>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

117

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________</s:Body></s:Envelope>

2870

3.18.4.1.2.7.1.1.2 Asynchronous Web Services Exchange<s:Envelope

2875
2880
2885
2890
2895
2900
2905
2910
2915
2920

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:RegistryStoredQuery</a:Action><a:MessageID>urn:uuid:a02ca8cd-86fa-4afc-a27c-616c183b2055</a:MessageID><a:ReplyTo><a:Address> http://192.168.2.4:9080/XDS/DocumentConsumerReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRegistryReceiver.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"/><rim:AdhocQuery id=" urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d "><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="$XDSDocumentEntryStatus"><rim:ValueList><rim:Value>('urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Approved')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeFrom"><rim:ValueList><rim:Value>200412252300</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeTo"><rim:ValueList><rim:Value>200501010800</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode"><rim:ValueList><rim:Value>(‘Emergency Department’)</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></query:AdhocQueryRequest></s:Body></s:Envelope>

3.18.4.1.2.7.1.2 Sample Registry Stored Query SOAP Response
2925

3.18.4.1.2.7.1.2.1 Synchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

118

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
2930
2935

<a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegistryStoredQueryResponse</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.18.4.1.2.7.1.2.2 Asynchronous Web Services Exchange
2940
2945
2950

<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:RegistryStoredQueryResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:a02ca8cd-86fa-4afc-a27c-616c183b2055</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentConsumerReceiver.svc</a:To></s:Header><s:Body><query:AdhocQueryResponse status="Success"xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><!—Rest of AdhocQueryResponse message goes here -->2955</query:AdhocQueryResponse></s:Body></s:Envelope>

3.18.4.1.3 Expected Actions
The Document Registry actor shall
2960

1.

Accept a parameterized query in an AdhocQueryRequest message

2.

Verify the required parameters are included in the request. Additionally, special rules
documented in the above section ‘Parameters for Required Queries’ shall be verified.

3.
2965

Errors shall be returned for the following conditions:• Unknown query ID (error code XDSUnknownStoredQuery)• Required parameter missing (error code XDSStoredQueryParamNumber)
See ITI TF-3: 4.1.13 Error Reporting for additional error codes and general
information on formatting error responses.

4.
2970

2975

Process the query as appropriate:• For Document Registry Actors: Retrieve the internal implementation template of thequery based on the Query ID supplied in the query request. Substitute appropriate
parameters as indicated in ITI TF-2a: 3.18.4.1.2.3.7 Parameters for Required Queries
and execute the query. The Document Registry shall accept the homeCommunityId
value if it is specified in a Registry Stored Query request. If a patient identifier
specified as a parameter to the query is unknown to the Document Registry it shallreturn a successful response with no elements.
• For Initiating Gateway Actors:___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

119

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
•
2980

2985

•

2990

2995

3000
5.

3005

3010

3015

Initiating Gateway receives a Registry Stored Query by patient id: It shall determinea) which Responding Gateways this request should be sent to and b) what patient id
to use in the Cross Gateway Query. Detailed specification of these steps is not in theintended scope of this profile. Combination of this profile with other existing profiles(e.g., PIX/PDQ), future profiles or configuration mechanisms is possible. Please refer
to ITI TF-1: E.7 XCA and Patient Identification Management for possible use ofexisting profiles PIX and PDQ. For each Responding Gateway identified, theInitiating Gateway shall update the query with the correct patient identifiercorresponding to the Responding Gateway’s community and initiates a Cross
Gateway Query transaction to the Responding Gateway. If the Initiating Gateway isgrouped with a Document Consumer it will also initiate a Registry Stored Query to
the local Document Registry.
Initiating Gateway receives a Registry Stored Query by entryUUID or uniqueID:
Verify homeCommunityId has been specified. If missing return Failure status with
XDSMissingHomeCommunityId error code. If homeCommunityId not recognized
return a Failure or PartialSuccess status with XDSUnknownCommunity error code.
Determine which Responding Gateway to contact by using the homeCommunityId toobtain the Web Services endpoint of the Responding Gateway. The process ofobtaining the Web Services endpoint is not further specified in this profile. If thehomeCommunityId represents the local community the Initiating Gateway shallinitiate a Registry Stored Query to the local Document Registry. The Initiating
Gateway shall specify the homeCommunityId in the Cross Gateway Query byentryUUID or uniqueID which identifies the community associated with the
Responding Gateway. For details regarding the homeCommunityId see ITI TF-2a:3.18.4.1.2.3.8 and ITI TF-2b: 3.38.4.1.2.1.

Return XML formatted metadata in an AdhocQueryResponse message.
• The Document Registry may specify the homeCommunityID attribute on any
appropriate elements• The Initiating Gateway shall specify the homeCommunityID attribute on all
appropriate elements. If the Initiating Gateway contacted a Document Registry, theDocument Registry response might not contain the homeCommunityId. In this case
the Initiating Gateway shall add the homeCommunityId of its local community to theDocument Registry response prior to including it in the consolidated response to theDocument Consumer. The homeCommunityId attribute corresponds to the ‘home’
attribute specified in the ebRIM standard. For more information on
homeCommunityId see ITI TF-2a: 3.18.4.1.2.3.8 and ITI TF-2b: 3.38.4.1.2.1. The
elements that shall include the home attribute are:• If returntype=”LeafClass” the ExtrinsicObject and RegistryPackage elements shallcontain the home attribute.
• If returnType=”ObjectRef” the ObjectRef element shall contain the home attribute• If the Initiating Gateway is unable to get an appropriate response from a selected
Responding Gateway it shall include in its response to the Document Consumer an___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

120

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________XDSUnavailableCommunity error code where the context identifies the unavailable
Responding Gateway. In this case, and any other error from a Responding Gateway,
the Initiating Gateway shall return to the Document Consumer either a Failure status(if no part was successful) or a PartialSuccess status.

3020

6.
3025

3030

When the Document Consumer receives the query response from the Initiating
Gateway it must account for two aspects of the response; namely that a) the
homeCommunityId attribute will be specified b) the Document Consumer may not beable to map the repository id value directly to the Document Repository. XCA assumes
a common coding/vocabulary scheme is used across all communities. For example, allcommunities shall have common privacy consent vocabularies. The Document
Consumer shall retain the values of the homeCommunityId attribute for futureinteraction with the Initiating Gateway.

This transaction may return both errors and results in an AdhocQueryResponse message. To dothis, the returned AdhocQueryResponse message would contain both a RegistryObjectList
element and a RegistryErrorList element. See ITI TF-3: 4.1.13 for additional details on
formatting of error responses.
3035

3040

3.18.4.1.3.1 Sample Query Request
This example query specifies:• The FindDocuments query (id attribute of AdhocQuery element)• patientID st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO• Return Approved documents only
• Time range (creation time) 200412252300 to 200501010800• Healthcare Facility Type Code of Emergency Department
Note that ebRS 3.0 specifies the use of Slot to specify name/value(s) pairs as parameters to a
Stored Query.
Note: query parameter names are highlighted for readability.

3045

3050
3055
3060

<query:AdhocQueryRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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"/><rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"><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="$XDSDocumentEntryStatus"><rim:ValueList><rim:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeFrom"><rim:ValueList>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

121

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3065
3070
3075

3080

3085

3090

3095

3100

<rim:Value>200412252300</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryCreationTimeTo"><rim:ValueList><rim:Value>200501010800</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode"><rim:ValueList><rim:Value>(‘Emergency Department’)</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></query:AdhocQueryRequest>

The following example shows a get documents query for XDSDocumentEntry objects for a
specified list of entryUUIDs (urn:uuid:aff99222-18e3-4812-bc71-c410b2860e18,
urn:uuid:aff99222-18e3-4812-bc71-c410b2860e19, urn:uuid:aff99222-18e3-4812-bc71c410b2860e20) and corresponding homeCommunityId value (urn:oid:1.2.3):<query:AdhocQueryRequest … ><query:ResponseOption returnComposedObjects="true"
returnType="LeafClass"/><rim:AdhocQuery id="urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4"
home=”urn:oid:1.2.3”><rim:Slot name="$XDSDocumentEntryEntryUUID"><rim:ValueList><rim:Value>(“urn:uuid:aff99222-18e3-4812-bc71-c410b2860e18”,“urn:uuid:aff99222-18e3-4812-bc71-c410b2860e19”,“urn:uuid:aff99222-18e3-4812-bc71-c410b2860e20”)</rim:Value></rim:ValueList></rim:Slot></rim:AdhocQuery></query:AdhocQueryRequest>

3.18.4.1.3.2 Intentionally Left Blank
3.18.4.1.3.3 Sample Query Response
3105

3110

This sample query response corresponds to the above query. Note that the query response
message is coded in version 3.0 ebRIM and ebRS. This sample response and the ebXML
Registry version 3.0 schema files are available online. The Implementation Guide found at
http://wiki.ihe.net/index.php?title=ITI_Implementation_Guide contains such supplemental
material.
<?xml version="1.0" encoding="UTF-8"?><AdhocQueryResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

122

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3115
3120
3125
3130
3135
3140
3145
3150
3155
3160
3165
3170
3175
3180

file:/Users/bill/RegSchema/V3.0/query.xsd"
xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"><rim:RegistryObjectList><rim:ExtrinsicObject
xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
id="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
isOpaque="false"
mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"><rim:Slot name="URI"><rim:ValueList><rim:Value>http://localhost:8080/XDS/Repository/08a15a6f-5b4a-42de-8f9589474f83abdf.xml</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="creationTime"><rim:ValueList><rim:Value>200412261119</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="hash"><rim:ValueList><rim:Value>4cf4f82d78b5e2aac35c31bca8cb79fe6bd6a41e</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="languageCode"><rim:ValueList><rim:Value>en-us</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="serviceStartTime"><rim:ValueList><rim:Value>200412230800</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="serviceStopTime"><rim:ValueList><rim:Value>200412230801</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="size"><rim:ValueList><rim:Value>54449</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="sourcePatientId"><rim:ValueList><rim:Value>jd12323^^^wsh</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="sourcePatientInfo"><rim:ValueList><rim:Value>PID-3|pid1^^^domain</rim:Value><rim:Value>PID-5|Doe^John^^^</rim:Value><rim:Value>PID-7|19560527</rim:Value><rim:Value>PID-8|M</rim:Value><rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value></rim:ValueList></rim:Slot>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

123

Copyright © 2011 IHE International,

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

3185
3190
3195
3200
3205
3210
3215
3220
3225
3230
3235
3240
3245

<rim:Name><rim:LocalizedString charset="UTF-8" value="Sample document 1" xml:lang="en-us"/></rim:Name><rim:Description/><rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:ac872fc0-1c6e-439f-84d1-f76770a0ccdf"
nodeRepresentation="Education"
objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon classCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString charset="UTF-8" value="Education" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification><rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:f1a8c8e4-3593-4777-b7e0-8b0773378705"
nodeRepresentation="C"objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon confidentialityCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString charset="UTF-8" value="Celebrity" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification><rim:Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:b6e49c73-96c8-4058-8c95-914d83bd262a"
nodeRepresentation="CDAR2/IHE 1.0"
objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon formatCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString charset="UTF-8" value="CDAR2/IHE 1.0" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification><rim:Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:61e2b376-d74a-4984-ac21-dcd0b8890f9d"
nodeRepresentation="Emergency Department"
objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon healthcareFacilityTypeCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString charset="UTF-8" value="Assisted Living" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

124

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3250
3255
3260
3265
3270
3275
3280
3285
3290
3295
3300
3305
3310
3315

<rim:Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:fb7677c5-c42f-485d-9010-dce0f3cd4ad5"
nodeRepresentation="Cardiology"
objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon practiceSettingCodes</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedString charset="UTF-8" value="Cardiology" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification><rim:Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
id="urn:uuid:0a8a8ed9-8be5-4a63-9b68-a511adee8ed5"
nodeRepresentation="34098-4"
objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>LOINC</rim:Value></rim:ValueList></rim:Slot><rim:Name><rim:LocalizedStringcharset="UTF-8"
value="Conference Evaluation Note" xml:lang="en-us"/></rim:Name><rim:Description/></rim:Classification><rim:ExternalIdentifier
id="urn:uuid:db9f4438-ffff-435f-9d34-d76190728637"
registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
objectType="ExternalIdentifier"value="st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"><rim:Name><rim:LocalizedStringcharset="UTF-8"
value="XDSDocumentEntry.patientId"
xml:lang="en-us"/></rim:Name><rim:Description/></rim:ExternalIdentifier><rim:ExternalIdentifier
id="urn:uuid:c3fcbf0e-9765-4f5b-abaa-b37ac8ff05a5"
registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
objectType="ExternalIdentifier"value="1.3.6.1.4.1.21367.2005.3.99.1.1010"><rim:Name><rim:LocalizedStringcharset="UTF-8"
value="XDSDocumentEntry.uniqueId"
xml:lang="en-us"/></rim:Name><rim:Description/></rim:ExternalIdentifier></rim:ExtrinsicObject><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:41a5887f-8865-4c09-adf7e362475b143a"/>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

125

Copyright © 2011 IHE International,

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

3320
3325
3330
3335

3340

3345

3350

3355

3360

3365

<rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:f4f85eac-e6cb-4883-b524f2705394840f"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:a09d5840-386c-46f2-b5ad9c3699a4309d"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:f33fb8ac-18af-42cc-ae0eed0b0bdb91e1"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:f0306f51-975f-434e-a61cc59651d33983"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:58a6f841-87b3-4a3e-92fda8ffeff98427"/><rim:ObjectRef xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab"/></rim:RegistryObjectList></AdhocQueryResponse>

The following query response is the same as above (repeated sections replaced with … ) with the
homeCommunityId attribute specified, in bold for readability. Subsequent requests specifying
entryUUID of urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf or uniqueID of
1.3.6.1.4.1.21367.2005.3.99.1.1010 shall include the homeCommunityId value of
urn:oid:1.2.3 in the query.
<?xml version="1.0" encoding="UTF-8"?><AdhocQueryResponse ... status="Success"><rim:RegistryObjectList><rim:ExtrinsicObject … id="urn:uuid:08a15a6f-5b4a-42de-8f9589474f83abdf" isOpaque="false" mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
home=”urn:oid:1.2.3”>…
<rim:ExternalIdentifier id="urn:uuid:c3fcbf0e-9765-4f5b-abaab37ac8ff05a5" registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
objectType="ExternalIdentifier" value="1.3.6.1.4.1.21367.2005.3.99.1.1010"><rim:Name><rim:LocalizedString charset="UTF-8"
value="XDSDocumentEntry.uniqueId" xml:lang="en-us"/></rim:Name><rim:Description/></rim:ExternalIdentifier></rim:ExtrinsicObject></rim:RegistryObjectList></AdhocQueryResponse>___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

126

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3370

3.18.4.1.3.4 Intentionally Left Blank
3.18.4.1.3.5 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:
1.

All Document Consumer Actors may provide a list of confidentialityCode in XDS
Registry Stored Query Transaction and the XDS Registry will return only documentthat have at least one matching confidentialityCode. In this way documents without atleast one of the requested codes will not be returned.

2.

The Document Consumer actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the XDS Affinity Domain Policy. The details of this areproduct specific and not specified by IHE.

3.

The Document Consumer shall not allow access to documents for which the Document
Consumer does not understand at least one of the confidentialityCode returned. Thisassures that a Document Consumer will not improperly handle documents withconfidentialityCode that may be more restrictive than the Document Consumer isconfigured to support.

4.

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

5.

Note: The Registry is already required to return only documents that match therequested confidentialityCode (filter) indicated in the Registry Stored Query.

6.

Note: Products implementing the Registry Actor may be able to further filter Registry
Stored Query results through looking at all the Patient Privacy Acknowledgement
Documents registered for the patient that have the availabilityStatus of Approved andfor which have not expired.

3375

3380

3385

3390

3395

3.18.4.1.3.6 Basic Patient Privacy Proof Option
3400

If the Basic Patient Privacy Consents Proof Option is implemented:
1.

3405

The Document Consumer actor shall be capable of querying for ‘Approved’ Patient
Privacy Acknowledgement Documents in the XDS Affinity Domain. This query should
be done by document class so as to catch both formats of document (Consent). The
Document Consumer actor shall be capable of recognizing the eventCodeList from theresulting XDS Metadata. There is no required handling of Patient Privacy Consent
Acknowledgement Document XDS Metadata. There is no requirement for the___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

127

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Document Consumer to retrieve the Patient Privacy Acknowledgement Document
content.
3.18.5 Security Considerations
3410

Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3.18.5.1 Audit Record Considerations
The Registry Stored Query Transaction is a Query Information event as defined in Table 3.20.61. The Actors involved shall record audit events according to the following:3415

3.18.5.1.1 Document Consumer audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)

EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-18”, “IHE Transactions”, “Registry Stored Query”)

UserIDM

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

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

Source (Document Consumer) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)Audit Source (Document Consumer) (1)Patient (0..1)
Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

Destination

SOAP endpoint URI.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

128

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
AlternativeUserID

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Query
Parameters(AudittMessage/
ParticipantObjectIdenti
fication)U

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

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-18”, “IHE Transactions”, “Registry Stored Query”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectID

M

Stored Query ID (UUID)

ParticipantObjectNameC

If known the value of <ihe:HomeCommunityId/>

ParticipantObjectQueryM

the AdhocQueryRequest, base64 encoded.
The ParticipantObjectDetail element may occur more than once.

ParticipantObjectDetailC

In one element, set “QueryEncoding”as the value of the attribute type,
Set the attribute value to the character encoding, such as “UTF-8”, used
to encode the ParticipantObjectQuery before base64 encoding.
In another element, set “urn:ihe:iti:xca:2010:homeCommunityId” as thevalue of the attribute type and the value of the homeCommunityID as
the value of the attribute value, if known.

3420

3.18.5.1.2 Document Registry audit message:
Event

Field Name

Opt

Value Constraints

EventID

M

EV(110112, DCM, “Query”)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

129

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
EventActionCodeM“E” (Execute)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-18”, “IHE Transactions”, “Registry Stored Query”)

UserIDM

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

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

Source (Document Consumer) (1)Destination (Document Registry) (1)Audit Source (Document Registry) (1)Patient (0..1)
Query Parameters(1)Where:
SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Query

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

SOAP endpoint URI.

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (system object)___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

130

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
ParticipantObjectTypeCodeRole

M“24” (query)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(“ITI-18”, “IHE Transactions”, “Registry Stored Query”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectID

M

Stored Query ID (UUID)

ParticipantObjectNameC

If known the value of <ihe:HomeCommunityId/>

ParticipantObjectQueryM

the AdhocQueryRequest, base64 encoded.
The ParticipantObjectDetail element may occur more than once.

ParticipantObjectDetailC

In one element, set “QueryEncoding”as the value of the attribute type,
Set the attribute value to the character encoding, such as “UTF-8”, used
to encode the ParticipantObjectQuery before base64 encoding.
In another element, set “urn:ihe:iti:xca:2010:homeCommunityId” as thevalue of the attribute type and the value of the homeCommunityID as
the value of the attribute value, if known.

3425___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

131

Copyright © 2011 IHE International,

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

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

3.40.4.3 Informative Material on WS-Trust
2730

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

3.41 Provide and Register Document Set-b
2735

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

2740

2745

2750

2755

2760

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

Rev. 8.0 Final Text 2011-08-19

112

Copyright © 2011 IHE International, Inc.

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

2765

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

Actors that support the Asynchronous Web Services Exchange option and implement the Provide
and Register Document Set-b [ITI-41] transaction shall support Asynchronous Web Services
Exchange on all XDS.b transactions they implement. Refer to section ITI TF-2x: V.5
Synchronous and Asynchronous Web Services Exchange for an explanation of Asynchronous
Web Services Exchange.
3.41.1 Scope

2770

The Provide and Register Document Set-b transaction passes a Repository Submission Request(see ITI TF-3: 4.1.3.1) from a Document Source to a Document Repository or Document
Recipient.

2775

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

Document Recipient

Document Repository

Provide and Register
Document Set – b

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

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

Rev. 8.0 Final Text 2011-08-19

113

Copyright © 2011 IHE International, Inc.

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

Actor: Document Repository2795

Role: A document storage system that receives documents and associated metadata and:• Stores the documents• Enhances submitted metadata with repository information to enable later retrieval of
documents• Forwards the enhanced metadata to the Document Registry.
Detailed requirements for this actor are discussed in ITI TF-2b: 3.41.6.2.
3.41.3 Referenced Standards
Implementors of this transaction shall comply with all requirements described in: ITI TF-2x:
Appendix V: Web Services for IHE Transactions.

2800
ebRIM

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

Appendix V

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

MTOM

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

XOP

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

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

Rev. 8.0 Final Text 2011-08-19

114

Copyright © 2011 IHE International, Inc.

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

Document
SourceDocument
Recipient
Provide and Register Document Set – b
RequestProvide and Register Document Set – b
Response2805
3.41.4.1 Provide and Register Document Set-b Request
A Document Source sends documents and associated metadata to a Document Recipient, or aDocument Repository that has an associated Document Registry.
2810

2815

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

2820

2825

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

A set of one or more documents to a Document Recipient.

3.41.4.1.2 Message Semantics

2830

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

Rev. 8.0 Final Text 2011-08-19

115

Copyright © 2011 IHE International, Inc.

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

A Document Recipient receives the metadata and the associated document(s). It shall be able tointerpret the submission without any context (e.g., a prior submission).

2840

The Document Source may include Folders in metadata. If the Document Recipient is not able toprocess the Folder specific content it shall return a PartialFolderContentNotProcessed warningwhich includes a textual description identifying that Folder Content was not processed. In thiscase the Document Recipient is expected to have processed the rest of the submission
successfully.

2845

In the case where the Document Source submits a replacement of documents, if the Document
Recipient is not able to process the replacement semantics in the submission it shall return aPartialReplaceContentNotProcessed warning which includes a textual description identifyingthat the replacement semantics were not processed. In this case the Document Recipient is
expected to have processed the rest of the submission successfully.
A Document Repository shall forward the metadata to the Document Registry using the Register
Document Set-b transaction [ITI-42].
The Document Repository receives this message. Each document within the message shall be
stored into the Document Repository as an octet stream with an associated MIME type.

2850

2855

2860

The Document Source shall supply all necessary document metadata attributes with the
exception of the ones below. The Document Repository shall modify the received document
metadata before initiating the Register Document Set-b transaction to the Document Registry byadding/replacing:• The repositoryUniqueId for this Document Repository to allow for the Document Consumer
to correctly identify the proper Document Repository for each document(XDSDocumentEntry.repositoryUniqueId).
• A hash value (XDSDocumentEntry.hash)• A size (XDSDocumentEntry.size).
A Register Document Set-b transaction with this modified metadata shall be issued to theDocument Registry.
The Document Repository shall ensure that when any Retrieve Document Set transaction isreceived requesting a specific document(s), it shall be provided to the Document Consumer
unchanged from the octet stream that was submitted (full fidelity repository) and shall match thesize and hash attributes of the XDSDocumentEntry object.

2865

If the Document Repository or Document Recipient detects a failure it shall return an error
message to the Document Source thus terminating this transaction. The conditions of failure andpossible error messages are given in the ebRS standard and detailed in ITI TF-3: 4.1.13 Error
Reporting.

Rev. 8.0 Final Text 2011-08-19

116

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.4.1.3.1 Basic Patient Privacy Enforcement Option
2870

If the Basic Patient Privacy Enforcement Option is implemented:
1. The Document Source actor shall populate the confidentialityCode in the document
metadata with the list of values that identify the sensitivity classifications that apply tothe associated document. The confidentiality codes for different documents in the same
submission may be different.

2875

2880

2885

2890

2895

2900

2. The Document Source actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the XDS Affinity Domain Policy. The details of this areproduct specific and not specified by IHE.
3. The Document Source actor may have user interface or business rule capabilities todetermine the appropriate confidentiality codes for each document. The details of this areproduct specific and not specified by IHE. However, the information about how
confidentiality codes are assigned must be part of the published policy for the XDS
Affinity Domain. Note: For example, when publishing a document, the Document
Source, might show a list of checkboxes where a user can select which of the available
consents a document is to be published.
4. The Document Recipient actor shall be able to be configured with the Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the policies. The meanings of the codes on the media must be
provided out of band, e.g., by telephone, fax, or email. The detail of how this is done isproduct specific and not specified by IHE. If the documents are transferred internallywithin the organization or to other members of the recipient's affinity domain, appropriate
internal confidentiality codes shall be applied.
5. The Document Recipient actor shall have the ability to coerce the confidentiality code in
the metadata associated with the document from the codes used by the Document Source
to the codes used by the Document Recipient.
6. The Document Recipient actor shall abide by the XDS Affinity Domain Policies
represented by the confidentialityCode in the metadata associated with the document. The
Document Recipient actor likely will have user access controls or business rulecapabilities to determine the details of how confidentiality codes apply to query results.
The details of this are product specific and not specified by IHE. These rules shall reduce
the query results to only those that are appropriate to the current situation for that actor
and user.
3.41.4.2 Provide and Register Document Set-b Response

2905

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

117

Copyright © 2011 IHE International, Inc.

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

2910

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

2915

2920

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

2925

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

2930

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

2935

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

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

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

lcm

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

query

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

Rev. 8.0 Final Text 2011-08-19

118

Copyright © 2011 IHE International, Inc.

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

2945

2950

2955

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

2960

2965

2970

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

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

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

urn:ihe:iti:2007:
ProvideAndRegisterDocumentSetbResponse

Rev. 8.0 Final Text 2011-08-19

119

Copyright © 2011 IHE International, Inc.

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

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

urn:ihe:iti:2007:CrossGatewayQuery

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

2980

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

2985
2990
2995
3000
3005
3010

3.41.5.1.1.1 Synchronous Web Services Exchange
POST /axis2/services/repository HTTP/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180;
type="application/xop+xml"; start="<0.urn:uuid76A2C3D9BCD3AECFF31217932910181@apache.org>";
start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"
User-Agent: Axis2
Host: localhost:4040
Content-Length: 4567--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:76A2C3D9BCD3AECFF31217932910181@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:To>http://localhost:4040/axis2/services/test11966a</wsa:To><wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetb</wsa:Action></soapenv:Header><soapenv:Body><xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007"><lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"><rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"><!-- Registry Metadata goes here -->

3015
3020

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

Rev. 8.0 Final Text 2011-08-19

120

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________</soapenv:Body></soapenv:Envelope>

3025--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:76A2C3D9BCD3AECFF31217932910229@apache.org>

3030

This is my document.
It is great!

3035--MIMEBoundaryurn_uuid_76A2C3D9BCD3AECFF31217932910180--

Rev. 8.0 Final Text 2011-08-19

121

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.5.1.1.2 Asynchronous Web Services Exchange
3040
3045
3050
3055
3060
3065

3070

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

3.41.5.1.2 Sample Provide and Register Document Set-b SOAP Response
3.41.5.1.2.1 Synchronous Web Services Exchange

3075
3080
3085

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

3.41.5.1.2.2 Asynchronous Web Services Exchange
3090
3095

<s:Envelope

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

Rev. 8.0 Final Text 2011-08-19

122

Copyright © 2011 IHE International, Inc.

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

3100
3105

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

3.41.6 Actor Requirements
This section summarizes the responsibilities of the actors relevant to this transaction.
3110

3.41.6.1 Document Source
An implementation of the Document Source actor shall be capable of the following operations:• Submit one or more documents. Whether a submission contains a single or multiple
documents depends on workflows, policies, and other external factors which are outside of
the scope of this transaction.

3115

3120

An implementation of the XDS Document Source actor may support one or more of thefollowing XDS.b options:• Document Replace Option: In this option the Document Source offers the ability to submit
a document as a replacement for another document already in the registry/repository.
• Document Addendum Option In this option the Document Source shall offer the ability tosubmit a document as an addendum to another document already in the registry/repository.
• Document Transformation Option In this option the Document Source shall offer theability to submit a document as a transformation of another document already in theregistry/repository.

3125

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

•

3130

Folder Management Option. In this option the Document Source offers the ability toperform the following operation:• Create a folder• Add one or more documents to a folder
Note: In order to support document addition to an existing folder, grouping with the Document Consumer may benecessary in order to Query the registry (e.g., for UUIDs of existing folder).

These operations are discussed in ITI TF-3: 4.1.3.4 Other Properties of Submission Requests.
3.41.6.2 Document Repository or Document Recipient
3135

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

Rev. 8.0 Final Text 2011-08-19

123

Copyright © 2011 IHE International, Inc.

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

3140

3145

3150

3155

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

3160

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

Rev. 8.0 Final Text 2011-08-19

124

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.41.7.1.1 Document Source audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

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

UserIDM

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

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

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

Where:

SourceAuditMessage/
ActiveParticipant

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

SOAP endpoint URI.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

Rev. 8.0 Final Text 2011-08-19

125

Copyright © 2011 IHE International, Inc.

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

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AudittMessage/
ParticipantObjectIdenti
fication)

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivity

U

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

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

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

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

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

Source (Document Source) (1)Destination (Document Repository or Document Recipient) (1)Audit Source (Document Repository or Document Recipient) (1)Patient (1)3170

SubmissionSet (1)Where:

SourceAuditMessage/
ActiveParticipant

UserIDM

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

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

Rev. 8.0 Final Text 2011-08-19

126

Copyright © 2011 IHE International, Inc.

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

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AudittMessage/
ParticipantObjectIdenti
fication)

3175

UserID

M

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The submissionSet unique ID
not specialized

ParticipantObjectName

U

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

3.42 Register Document Set-b
This section corresponds to transaction [ITI-42] of the IHE IT Infrastructure Technical
Framework. Transaction [ITI-42] is used by the Document Repository Actor to register a set of
documents with the Document Registry in XDS.b.
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)

Rev. 8.0 Final Text 2011-08-19

127

Copyright © 2011 IHE International, Inc.

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

3185

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

3190

3195

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

Document
Registry

RegisterDocument Set – b

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

Role: A document indexing system that receives and stores document metadata.
Note: Within this transaction, the Document Repository and Integrated Document Source/Repository actors can be usedinterchangeably

Rev. 8.0 Final Text 2011-08-19

128

Copyright © 2011 IHE International, Inc.

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

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

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

HL7V2

HL7 Version 2.5

Appendix V

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

3.42.4 Interaction Diagram

Document
Repository

Document
Registry
Register Document Set – b Request

Register Document Set – b Response

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

The Register Document Set-b Request message is triggered when:• A Document Repository wants to register metadata for a set of documents it holds. These
documents may have been stored in the Document Repository by a Document Consumer(using the Provide and Register Document Set-b transaction [ITI-41]) or generated internallyby an Integrated Document Source/Repository.
3.42.4.1.2 Message Semantics

3225

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

Rev. 8.0 Final Text 2011-08-19

129

Copyright © 2011 IHE International, Inc.

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

3230

The Registry actor shall store and later include in metadata returned in a query response the
XDSDocumentEntry.repositoryUniqueId attribute along with other metadata attributes received
in the Register Document Set-b [ITI-42] transaction as determined by profile and transaction
requirements.
3.42.4.1.4 Expected Actions

3235

3240

Upon receipt of a Register Document Set-b Request message, the Document Registry with theaid of the Registry Adaptor shall do the following:• Accept all valid SubmitObjectsRequests.
• Perform metadata validations• Update the registry with the contained metadata• Return a RegistryResponse message given the status of the operation.
If the registry rejects the metadata, then, the following shall occur:• An error is returned• The error status includes an error message• The request is rolled back3.42.4.1.4.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:

3245

3250

3255

3260

1. The Integrated Document Source / Repository actor shall populate theconfidentialityCode in the document metadata with the list of values that identify thesensitivity classifications that apply to the associated document. The confidentiality codesfor different documents in the same submission may be different.
2. The Integrated Document Source / Repository actor shall be able to be configured with
the Patient Privacy Policies, Patient Privacy Policy Identifiers (OIDs) and associatedinformation necessary to understand and enforce the XDS Affinity Domain Policy. The
details of this are product specific and not specified by IHE.
3. The Integrated Document Source / Repository actor may have a user interface or businessrule capabilities to determine the appropriate confidentiality codes for each document.
The details of this are product specific and not specified by IHE. However, theinformation about how confidentiality codes are assigned must be part of the publishedpolicy for the XDS Affinity Domain. For example, when publishing a document, theIntegrated Document Source / Repository might show a list of checkboxes where a user
can select which of the available consents a document is to be published.
3.42.4.1.5 Protocol Requirements
The Register Document Set-b transaction shall use SOAP12. Furthermore:

Rev. 8.0 Final Text 2011-08-19

130

Copyright © 2011 IHE International, Inc.

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

3265

•

The Document Registry actor shall accept the Register Document Set-b Request formatted asa SIMPLE SOAP message and respond with the Register Document Set-b Response
formatted as a SIMPLE SOAP message.
The Document Repository actor shall generate the Register Document Set-b Request
formatted as a SIMPLE SOAP message and accept the Register Document Set-b Response
formatted as a SIMPLE SOAP message.

See ITI TF-2x: Appendix V for details.
3.42.4.2 Register Document Set-b Response
3270

3.42.4.2.1 Trigger Events
The Document Registry finishes processing a Register Document Set-b Request Message andshall respond with:• Register Document Set-b Response
3.42.4.2.2 Message Semantics

3275

The Register Document Set-b Response message shall carry the status of the requested operation
and an error message if the requested operation failed. The conditions of failure and possible
error messages are given in the ebRS standard and detailed in ITI TF-3: 4.1.13 Error Reporting.
3.42.4.2.3 Expected Actions

3280

The Document Repository now knows that the transaction succeeded/failed and can continue.
The metadata added to the registry as a result of this transaction is now available for discovery.
3.42.5 Protocol Requirements
Implementors of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.

Rev. 8.0 Final Text 2011-08-19

131

Copyright © 2011 IHE International, Inc.

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

3290

3295

3300

ihe

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

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

lcm

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

query

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

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

3305

Value

/definitions/portType/operation@name

DocumentRepository_RegisterDocumentSet-b/definitions/portType/operation/input/@wsaw:Action

urn:ihe:iti:2007:RegisterDocumentSet-b/definitions/portType/operation/output/@wsaw:Action

urn:ihe:iti:2007:
ProvideAndRegisterDocumentSetbResponse/definitions/binding/operation/soap12:operation/@soap
Actionurn:ihe:iti:2007: RegisterDocumentSet-b

3.42.5.1 Sample SOAP Messages
The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to ITI
TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP message isRev. 8.0 Final Text 2011-08-19

132

Copyright © 2011 IHE International, Inc.

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

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.42.5.1.1 Sample Register Document Set-b SOAP Request

3315

3320
3325
3330

3.42.5.1.1.1 Synchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-b</a:Action><a:MessageID>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo s:mustUnderstand="1"><a:To >http://localhost:2647/XdsService/IHEXDSRegistry.svc</a:To></s:Header><s:Body><lcm:SubmitObjectsRequest
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><!—Rest of SubmitObjectsRequest message goes here -->

3335

3340
3345
3350
3355
3360

</lcm:SubmitObjectsRequest></s:Body></s:Envelope>

3.42.5.1.1.2 Asynchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-b</a:Action><a:MessageID>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:MessageID><a:ReplyTo><a:Address>
http://192.168.2.4:9080/XdsService/DocumentRepositoryReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRegistryReceiver.svc</a:To></s:Header><s:Body><lcm:SubmitObjectsRequest
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><!—Rest of SubmitObjectsRequest message goes here --></lcm:SubmitObjectsRequest></s:Body></s:Envelope>Rev. 8.0 Final Text 2011-08-19

133

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
3.42.5.1.2 Sample Register Document Set-b SOAP Response
3365

3370
3375

3380

3.42.5.1.2.1 Synchronous Web Services Exchange<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSet-bResponse</a:Action><a:RelatesTo>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:RelatesTo></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></s:Body></s:Envelope>

3.42.5.1.2.2 Asynchronous Web Services Exchange<s:Envelope

3385
3390
3395

3400

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegisterDocumentSetbResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:1ec52e14-4aad-4ba1-b7d3-fc9812a21340</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRepositoryReceiver.svc</a:To></s:Header><s:Body><rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></s:Body></s:Envelope>

3.42.6 Actor Requirements
The Document Repository actor shall:• Make (all) the new document(s) included in the XDS Submission Set available for retrieval
via the Retrieve Document Set transaction before it initiates the Register Document Set-b
Request message with the Registry actor.

3405

This is necessary because:• The Document Registry actor may choose to validate the successful storage of the
document(s) before acknowledging the Register Document Set-b Request transaction.
• The Document Consumer actor may retrieve the document(s) before the Register Document
Set-b Response is received by the Document Repository actor.

3410

3.42.7 Security Considerations
Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).

Rev. 8.0 Final Text 2011-08-19

134

Copyright © 2011 IHE International, Inc.

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

The Register Document Set-b Transaction is PHI-Export event, as defined in ITI TF-2a: Table
3.20.6-1. The Actors involved in the transaction shall create audit data in conformance with
DICOM (Supp 95) “Data Export”, with the following exceptions.
3.42.7.1.1 Document Repository or Integrated Document Source/Repository audit
message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-42”, “IHE Transactions”, “Register Document Set-b”)

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

SourceAuditMessage/
ActiveParticipant

UserIDU

When WS-Addressing is used: <ReplyTo/>

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

UserID

M

3420
DestinationRev. 8.0 Final Text 2011-08-19

135

SOAP endpoint URI.

Copyright © 2011 IHE International, Inc.

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

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AudittMessage/
ParticipantObjectIdenti
fication)U

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

3.42.7.1.2 Document Registry audit message:
Event
AuditMessage/
EventIdentification

Field Name

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-42”, “IHE Transactions”, “Register Document Set-b”)

Source (Document Repository or Integrated Document Source/Repository) (1)Destination (Document Registry ) (1)Audit Source (Document Registry) (1)Patient (1)SubmissionSet (1)Where:

Rev. 8.0 Final Text 2011-08-19

136

Copyright © 2011 IHE International, Inc.

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

UserIDU

When WS-Addressing is used this should be the value of the<ReplyTo/> element.

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserID

M

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

3425
Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(AudittMessage/
ParticipantObjectIdenti
fication)

Submission
Set(AudittMessage/
ParticipantObjectIdenti
fication)

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (person)

ParticipantObjectTypeCodeRole

M“1” (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectIDM

the patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRole

M“20” (job)ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The submissionSet unique ID

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

Rev. 8.0 Final Text 2011-08-19

137

Copyright © 2011 IHE International, Inc.

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

3.43 Retrieve Document Set
3430

This section corresponds to Transaction ITI-43 of the IHE Technical Framework. The Document
Consumer, Document Repository and Initiating Gateway actors use transaction ITI-43.
Integration Profiles using this Transaction
Cross-Enterprise Document Sharing-b (XDS.b)
Cross-Community Access (XCA)

3435

Actors that support the Asynchronous Web Services Exchange option shall support
Asynchronous Web Services Exchange on all XDS.b transactions they implement. Refer tosection ITI TF-2x: V.5 Synchronous and Asynchronous Web Services Exchange for an
explanation of Asynchronous Web Services Exchange.
3.43.1 Scope

3440

This transaction is used by the Document Consumer to retrieve a set of documents from theDocument Repository or Initiating Gateway. The Document Consumer has already obtained the
XDSDocumentEntry uniqueId and the Document Repository repositoryUniqueId from theDocument Registry/Initiating Gateway by means of the Registry Stored Query transaction.
3.43.2 Use Case Roles

Document
ConsumerDocument Repository
Or
Integrated Document
Source/Repository

Initiating Gateway

Retrieve
Document Set

3445
XDS Actors:
Actor: Document Consumer
Role: Obtains document.
Actor: Document Repository or Integrated Document Source/Repository
3450

Role: Provides documents.
XCA Actors:

Rev. 8.0 Final Text 2011-08-19

138

Copyright © 2011 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.

3455

Note: Within this transaction, the Document Repository and Integrated Document Source/Repository actors can be usedinterchangeably.

3.43.3 Referenced Standard
3460

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

OASIS/ebXML Registry Information Model v3.0

ebRS

OASIS/ebXML Registry Services Specifications v3.0

Appendix V

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

MTOM

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

XOP

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

3.43.4 Interaction Diagram
Document
Repository/
Initiating
Gateway

Document
Consumer
Retrieve Document Set Request

Retrieve Document Set Response

3465

3.43.4.1 Retrieve Document Set Request
3.43.4.1.1Trigger Events
3470

The Document Consumer obtains document(s) uniqueId via the Registry Stored Query
transaction. If the Registry Stored Query was sent to the Initiating Gateway the Document
Consumer shall address the Retrieve Document Set to the Initiating Gateway. In this case noRev. 8.0 Final Text 2011-08-19

139

Copyright © 2011 IHE International, Inc.

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

3475

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

3480

3485

The Retrieve Document Set Request shall carry the following information:• A required repositoryUniqueId that identifies the repository from which the document is tobe retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId.
• A required documentUniqueId that identifies the document within the repository. This value
corresponds to the XDSDocumentEntry.uniqueId.
• If available, the homeCommunityId element that identifies the community holding the
document. The homeCommunityId element shall be specified if the XDSDocumentEntry
containing the uniqueId of the document contains the homeCommunityId attribute. See ITI
TF-2a: 3.18.4.1.2 for details.
The repositoryUniqueId associated to each document requested can be different therefore
allowing a single request to identify multiple repositories.

3490

3.43.4.1.3 Expected Actions
When receiving a Retrieve Document Set Request, a Document Repository or an Initiating
Gateway shall generate a Retrieve Document Set Response containing the requested documents
or error codes if the documents could not be retrieved.

3495

3500

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 profile. The Initiating Gateway shall send
Cross Gateway Retrieves/Retrieve Document Set transactions to each appropriate Responding
Gateway/Document Repository, consolidate the results, and return them to the Document
Consumer.
3.43.4.1.3.1 Basic Patient Privacy Enforcement Option
If the Basic Patient Privacy Enforcement Option is implemented:

3505

1. The Document Consumer actor shall abide by the XDS Affinity Domain Policies
represented by the confidentialityCode in the metadata associated with the document. The
Document Consumer actor likely will have user access controls or business rulecapabilities to determine the details of how confidentiality codes apply to query results.
The details of this are product specific and not specified by IHE. These rules shall reduce

Rev. 8.0 Final Text 2011-08-19

140

Copyright © 2011 IHE International, Inc.

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

3510

the query results to only those that are appropriate to the current situation for that actor
and user.
2. The Document Consumer actor shall be able to be configured with Patient Privacy
Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary
to understand and enforce the XDS Affinity Domain Policy. The details of this areproduct specific and not specified by IHE.

3515

3.43.4.2 Retrieve Document Set Response
3.43.4.2.1 Trigger Events
This message will be triggered by a Retrieve Document Set Request Message
3.43.4.2.2 Message Semantics

3520

3525

3530

The Retrieve Document Set Response Message shall carry the following information, for each of
the returned documents:• A homeCommunityId. This value shall be the same as the homeCommunityId value in the
Retrieve Document Set Request Message. If the homeCommunityId value is not present in
the Retrieve Document Set Request Message, this shall not be present.
• A required repositoryUniqueId that identifies the repository from which the document is tobe retrieved. This value shall be the same as the value of the repositoryUniqueId in theoriginal Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required documentUniqueId that identifies the document within the repository. This value
shall be the same as the documentUniqueId in the original Retrieve Document Set Request
Message. This value corresponds to the XDSDocumentEntry.uniqueId.
• The retrieved document as a XOP Infoset• The MIME type of the retrieved document• Errors or warnings in case the document(s) could not be retrieved successfully
3.43.4.2.3 Expected Actions

3535

A Document Repository shall retrieve the document(s) indicated in the request.
The Document Repository shall return the document or an error code in case the document could
not be retrieved. The conditions of failure and possible error messages are given in the ebRS
standard and detailed in ITI TF-3: 4.1.13 Error Reporting.
3.43.5 Protocol Requirements

3540

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

Rev. 8.0 Final Text 2011-08-19

141

Copyright © 2011 IHE International, Inc.

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

3545

The Retrieve Document Set transaction shall use SOAP12 and MTOM with XOP encoding(labeled MTOM/XOP in this specification). See ITI TF-2x: Appendix V for details. The
Document Repository shall:• Accept the Retrieve Document Set Request message in MTOM/XOP format.
• Generate the Retrieve Document Set Response message in MTOM/XOP format
The Document Consumer shall:• Generate the Retrieve Document Set Request message in MTOM/XOP format.
• Accept the Retrieve Document Set Response message in MTOM/XOP format.

3550
WSDL Namespace Definitions

3555

3560

ihe

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

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

lcm

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

query

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

Document Repository: These are the requirements for the Retrieve Document Set transaction
presented in the order in which they would appear in the Document Repository WSDL
definition:• The following types shall be imported (xsd:import) in the /definitions/types section:• namespace="urn:ihe:iti:xds-b:2007", schema="IHEXDS.xsd"• The /definitions/message/part/@element attribute of the Retrieve Document Set Request
message shall be defined as “ihe:RetrieveDocumentSetRequest”• The /definitions/message/part/@element attribute of the Retrieve Document Set Response
message shall be defined as “ihe:RetrieveDocumentSetResponse”• Refer to Table 3.43.5.b below for additional attribute requirements
To support the Asynchronous Web Services Exchange option on the Document Consumer, theDocument Repository shall support the use of a non-anonymous response EPR in the WSAddressing replyTo header.

3565
Table 3.43.5.b Additional Attribute Requirements
Attribute

Value/definitions/portType/operation@name

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

urn:ihe:iti:2007:
RetrieveDocumentSetResp
onse/definitions/binding/operation/soap12:operati
on/@soapAction

urn:ihe:iti:2007:
RetrieveDocumentSet

Rev. 8.0 Final Text 2011-08-19

142

Copyright © 2011 IHE International, Inc.

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

3570

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

3575

3580

The <ihe:RetrieveDocumentSetRequest/> element is defined as:• One or more <ihe:DocumentRequest/> elements, each one representing an individual
document that the Document Consumer wants to retrieve from the Document Repository.
Each <ihe:DocumentRequest/> element contains:• A required <ihe:RepositoryUniqueId/> element that identifies the repository fromwhich the document is to be retrieved. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required <ihe:DocumentUniqueId/> that identifies the document within therepository. This value corresponds to the XDSDocumentEntry.uniqueId.
• An optional <ihe:HomeCommunityId/> element that corresponds to the homeattribute of the Identifiable class in ebRIM.
This allows the Document Consumer to specify one or more documents to retrieve from theDocument Repository.

3585

3590

3595

3600

3605

The <ihe:RetrieveDocumentResponse/> element is defined as:• A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element• An optional sequence of <ihe:DocumentResponse/> elements containing• A <ihe:HomeCommunityId/> element. The value of this element shall be the same as
the value of the/RetrieveDocumentSetRequest/DocumentRequest/HomeCommunityId element in the
Retrieve Document Set Request Message. If the <ihe:HomeCommunityId/> element
is not present in the Retrieve Document Set Request Message, this value shall not bepresent.
• A required <ihe:RepositoryUniqueId/> that identifies the repository from which the
document is to be retrieved. The value of this element shall be the same as the valueof the /RetrieveDocumentSetRequest/DocumentRequest/RepositoryUniqueId elementin the original Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
• A required <ihe:DocumentUniqueId/> that identifies the document within therepository. The value of this element shall be the same as the value of the/RetrieveDocumentSetRequest/DocumentRequest/DocumentUniqueId element in theoriginal Retrieve Document Set Request Message. This value corresponds to
XDSDocumentEntry.uniqueId.
• A required <ihe:Document/> element that contains the retrieved document inbase64binary encoded format• A required <ihe:mimeType/> element that indicates the MIME type of the retrieved
documentRev. 8.0 Final Text 2011-08-19

143

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall
status of the request: It shall contain one of the following values:3610

urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

See ITI TF-3: 4.1.13 Error Reporting for the interpretation of these values.
3615

3620

3625

3630

3635

3640

For each document requested in a /RetrieveDocumentSetRequest/DocumentRequest element:• If a warning is reported when retrieving the document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be returned with:• @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning• @errorCode is specified• @codeContext contains the warning message• @location contains the DocumentUniqueId of the document requested• The document shall be returned in an instance of/RetrieveDocumentSetResponse/DocumentResponse/Document as a XOP Infoset. The
returned document and warning are correlated via the DocumentUniqueId.
• If an error is reported when retrieving a document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be returned with:• @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error• @errorCode is specified• @codeContext contains the error message• @location contains the DocumentUniqueId of the document requested• No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned• If the document is successfully retrieved (without warning) then no/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be present and a/RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned
containing the document as a XOP Infoset.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not
used in this transaction.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in thistransaction.
A full XML Schema Document for the XDS.b types is available online on the IHE FTP site, see
ITI TF-2x: Appendix W.
Rev. 8.0 Final Text 2011-08-19

144

Copyright © 2011 IHE International, Inc.

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

3.43.5.1 Sample SOAP Messages
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.

3650

3.43.5.1.1 Sample Retrieve Document Set SOAP Request
3.43.5.1.1.1 Synchronous Web Services Exchange

3655
3660
3665
3670
3675
3680
3685

3690

POST /tf6/services/xdsrepositoryb HTTP/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517;
type="application/xop+xml";
start="<0.urn:uuid:3448B7F8EA6E8B9DFC1289514997518@apache.org>";
start-info="application/soap+xml"
User-Agent: Axis2
Host: ihexds.nist.gov:5000--MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:3448B7F8EA6E8B9DFC1289514997518@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:To soapenv:mustUnderstand="1">http://localhost:5000/tf6/services/xdsrepositoryb</wsa:To><wsa:MessageID soapenv:mustUnderstand="1">urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:MessageID><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSet</wsa:Action></soapenv:Header><soapenv:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId><DocumentUniqueId>1.42.20101110141555.15</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_3448B7F8EA6E8B9DFC1289514997517--

This request message is in MTOM/XOP format because request/response message pairs must
always be in the same format (MTOM/XOP vs. SIMPLE SOAP) and the response requires
MTOM/XOP: one part for descriptive metadata and a second part for document contents.
3.43.5.1.1.2 Asynchronous Web Services Exchange

3695
3700

<s:Envelope

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSet</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo>Rev. 8.0 Final Text 2011-08-19

145

Copyright © 2011 IHE International, Inc.

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

3705
3710
3715
3720

<a:Address>
http://192.168.2.4:9080/XdsService/DocumentConsumerReceiver.svc</a:Address></a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRepositoryReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"><DocumentRequest><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId></DocumentRequest><DocumentRequest><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId></DocumentRequest></RetrieveDocumentSetRequest></s:Body></s:Envelope>3.43.5.1.2 Sample Retrieve Document Set SOAP Response
3.43.5.1.2.1 Synchronous Web Services Exchange
3725

3730
3735
3740
3745
3750
3755
3760

In the following example, the HTTP header Transfer-Encoding: chunked and thecorresponding chunk annotations were removed for readability.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310;
type="application/xop+xml";
start="0.urn:uuid:E910375860336E2B8F1289514978311@apache.org";
start-info="application/soap+xml";
Date: Thu, 11 Nov 2010 22:36:15 GMT--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:E910375860336E2B8F1289514978311@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action><wsa:RelatesTo>urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:RelatesTo></soapenv:Header><soapenv:Body><xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007"><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><xdsb:DocumentResponse><xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId><xdsb:DocumentUniqueId>1.42.20101110141555.15</xdsb:DocumentUniqueId><xdsb:mimeType>text/plain</xdsb:mimeType><xdsb:Document><xop:Include

Rev. 8.0 Final Text 2011-08-19

146

Copyright © 2011 IHE International, Inc.

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

3765

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>

3770--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:E910375860336E2B8F1289514978312@apache.org>

3775

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

3780

This example shows the ‘wire format’ for MTOM/XOP. The Document element contains a<xop:Include> element that points to the document contents as a separate attachment.
Note:

3785

3790
3795
3800
3805
3810
3815
3820

In some systems, the ‘in memory’ format replaces the <xop:Include> with the Base64 encoded contents of the
document. This is done so the entire message contents fits into an XML parse tree.

A second form of the response is possible, an un-optimized MTOM/XOP message. In this form
the message is still formatted as a multipart but the document contents is not split out into aseparate part of the multipart. Some popular Web Service toolkits generate this form for verysmall documents. The same response in this form looks like:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related;boundary=MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310;
type="application/xop+xml";
start="0.urn:uuid:E910375860336E2B8F1289514978311@apache.org";
start-info="application/soap+xml";
Date: Thu, 11 Nov 2010 22:36:15 GMT--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310
Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:E910375860336E2B8F1289514978311@apache.org><?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:Action soapenv:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action><wsa:RelatesTo>urn:uuid:3448B7F8EA6E8B9DFC1289514997508</wsa:RelatesTo></soapenv:Header><soapenv:Body><xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007"><rs:RegistryResponse
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><xdsb:DocumentResponse><xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId><xdsb:DocumentUniqueId>1.42.20101110141555.15</xdsb:DocumentUniqueId><xdsb:mimeType>text/plain</xdsb:mimeType><xdsb:Document>

Rev. 8.0 Final Text 2011-08-19

147

Copyright © 2011 IHE International, Inc.

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

3825

3830

3835
3840
3845
3850
3855
3860
3865

Base64 encoded contents of document go here</xdsb:Document></xdsb:DocumentResponse></xdsb:RetrieveDocumentSetResponse></soapenv:Body></soapenv:Envelope>--MIMEBoundaryurn_uuid_E910375860336E2B8F1289514978310--

3.43.5.1.2.2 Asynchronous Web Services Exchange<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentConsumerReceiver.svc</a:To></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Success"/><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>text/xml</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>3.43.6 Security Considerations
Relevant XDS Affinity Domain Security background is discussed in the XDS Security
Considerations Section (see ITI TF-1: 10.7).
3870

3.43.6.1 Audit Record Considerations
The Retrieve Document Set Transaction is PHI-Export event, as defined in ITI TF-2a: Table
3.20.6-1. The Actors involved in the transaction shall create audit data in conformance with
DICOM (Supp 95) “Data Export”/”Data Import”, with the following exceptions.

3875

The Repository Actor shall generate an “Export” event. This may be an event for each Retrieve
Document Transaction, or multiple transactions for the same patient may be heuristicallycombined. The heuristics for this combination are not specified by IHE. It is intended to reduce

Rev. 8.0 Final Text 2011-08-19

148

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
the volume of audit records. Combination is permitted when the active participants and patient
are the same, and the time difference is considered insignificant.
3880

The Document Consumer Actor shall generate an “Import” event. This may be one event pertransaction, or multiple transactions may be reported as a single event using a heuristic for
combining transactions. Combination is permitted when the active participants and patient are
the same, and the time difference is considered insignificant.
3.43.6.1.1 Document Consumer audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110107, DCM, “Import”)

EventActionCodeM“C” (Create)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-43”, “IHE Transactions”, “Retrieve Document Set”)

Source (Document Repository) (1)Destination (Document Consumer) (1)
Human Requestor (0..n)
Audit Source (Document Consumer) (1)Patient (0..1)
Document (1..n) (see combining rules above)

3885

Where:

SourceAuditMessage/
ActiveParticipant

UserID

M

SOAP endpoint URI

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

Rev. 8.0 Final Text 2011-08-19

149

Copyright © 2011 IHE International, Inc.

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

UserIDM

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

AuditMessage/
ActiveParticipant

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“true”

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

Human
Requestor(if known)

UserID

M

Identity of the human that initiated the transaction.

AlternativeUserIDU

not specialized

UserNameUnot specialized

AuditMessage/
ActiveParticipant

UserIsRequestorM“true”

RoleIDCodeU

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

NetworkAccessPointTypeCode

NA

NetworkAccessPointID

NA

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“1” (Person)

ParticipantObjectTypeCodeRole

M“1” (Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

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

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The patient ID in HL7 CX format.

ParticipantObjectNameU

not specialized

ParticipantObjectQueryU

not specialized

ParticipantObjectDetailUnot specialized

ParticipantObjectTypeCodeM“2” (System)

ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(9, RFC-3881, “Report Number”)

ParticipantObjectSensitivityU

not specialized

ParticipantObjectID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

ParticipantObjectQueryU

not specialized

Audit Source
AuditMessage/
AuditSourceIdentification

Patient(if-known)(AudittMessage/
ParticipantObjectIdenti
fication)

Document(AudittMessage/
ParticipantObjectIdenti
fication)

Rev. 8.0 Final Text 2011-08-19

150

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________The ParticipantObjectDetail element may occur more than once.
ParticipantObjectDetailM

In one element, the value of <ihe:RepositoryUniqueId/> in value
attribute, “Repository Unique Id” in type attribute
In another element, the value of “ihe:homeCommunityID” as the valueof the attribute type and the value of the homeCommunityID as thevalue of the attribute value

3.43.6.1.2 Document Repository audit message:
Field Name
Event
AuditMessage/
EventIdentification

Opt

Value Constraints

EventID

M

EV(110106, DCM, “Export”)

EventActionCodeM“R” (Read)

EventDateTimeM

not specialized

EventOutcomeIndicatorM

not specialized

EventTypeCode

M

EV(“ITI-43”, “IHE Transactions”, “Retrieve Document Set”)

UserID

M

SOAP endpoint URI

AlternativeUserIDM

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

UserNameUnot specialized

UserIsRequestorM“false”

RoleIDCodeM

EV(110153, DCM, “Source”)

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

NetworkAccessPointID

M

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

UserIDM

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

AlternativeUserIDU

not specialized

UserNameUnot specialized

UserIsRequestorM“true”

Source (Document Repository) (1)Destination (Document Consumer) (1)Audit Source (Document Repository) (1)Document (1..n) (see combining rules above)

3890

Where:

SourceAuditMessage/
ActiveParticipant

Destination
AuditMessage/
ActiveParticipant

Audit Source
AuditMessage/
AuditSourceIdentification

Document

RoleIDCodeM

EV(110152, DCM, “Destination”)

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

NetworkAccessPointID

M

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

AuditSourceIDU

Not specialized.

AuditEnterpriseSiteIDU

not specialized

AuditSourceTypeCodeU

not specialized

ParticipantObjectTypeCodeM“2” (System)

Rev. 8.0 Final Text 2011-08-19

151

Copyright © 2011 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b): Transactions Part B______________________________________________________________________________
ParticipantObjectTypeCodeRoleM“3” (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV(9, RFC-3881, “Report Number”)
not specialized

ParticipantObjectSensitivity

U

ParticipantObjectID

M

The value of <ihe:DocumentUniqueId/>

ParticipantObjectNameC

not specialized

ParticipantObjectQueryU

not specialized
The ParticipantObjectDetail element may occur more than once.

ParticipantObjectDetail3895

In one element, the value of <ihe:RepositoryUniqueId/> in value
attribute, “Repository Unique Id” in type attribute

M

In another element, the value of “ihe:homeCommunityID” as the valueof the attribute type and the value of the homeCommunityID as thevalue of the attribute value

3.44 Patient Identity Feed HL7 V3This section corresponds to Transaction ITI-44 of the IHE IT Infrastructure Technical
Framework. Transaction ITI-44 is used by the Patient Identity Source, Patient Identifier Crossreference Manager and Document Registry Actors.
3.44.1 Scope

3900

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
3905

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

3910

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.

Rev. 8.0 Final Text 2011-08-19

152

Copyright © 2011 IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________

18 Cross-Enterprise Document Sharing for Imaging (XDS-I.b)
Integration Profile
IMPORTANT NOTE: The Cross-Enterprise Document Sharing for Imaging (XDS-I)
Integration Profile (originally found here) has been deprecated and is replaced by afunctionally equivalent profile called Cross-Enterprise Document Sharing for Imaging (XDSI.b), which is described in the remainder of this section.
The Cross-Enterprise Document Sharing (XDS.b) Profile in the IHE IT Infrastructure Domain
provides a solution for sharing (publishing, finding and retrieving) documents across a group ofaffiliated enterprises. The XDS for Imaging (XDS-I.b) Profile, defined here, extends andspecializes the mechanisms defined by XDS.b to support imaging “documents”, specifically
including the following:
Imaging studies that include images acquired on a broad range of different modalities, aswell as evidence documents (e.g., post-processing measurements/analysis outcome), andpresentation states.
• Diagnostic reports resulting from the interpretation of one or more related imaging
studies provided in a ready-for-display form
• A selection of diagnostically significant images associated with the report content.
These document types along with the actor capabilities required to share them are defined by thisprofile.
Since the XDS for Imaging (XDS-I.b) Profile depends on and extends the IT Infrastructure
XDS.b Profile including the use of terms defined in XDS.b (e.g., XDS Affinity Domain,
submission set, etc.) the reader of XDS-I.b is expected to have read and understood the XDS
Profiles (See ITI TF-1: 10). The XDS-I.b specification does not repeat requirements and text for
the XDS-defined Actors Document Repository, Document Registry, and Document Consumer,
and does not place any new requirements on these actors.
Both the XDS.b and XDS for Imaging (XDS-I.b) Integration Profiles are not intended to address
all cross-enterprise EHR communication needs. Many scenarios may require the use of other
IHE Integration profiles, such as Patient Identifier Cross-Referencing (PIX), Audit Trail andNode Authentication (ATNA), Enterprise User Authentication (EUA), Cross-Enterprise User
Authentication (XUA) and Retrieve Information for Display (RID). Other scenarios may be only
partially supported, while still others may require future IHE Integration profiles, which will bedefined by IHE as soon as the necessary base standards are available. Specifically:•1.

The operation of any XDS Affinity Domain will require that a proper security model be
put in place. It is expected that a range of security models should be possible. Although
the XDS-I.b Integration Profile is not intended to include nor require any specificsecurity model, it is required that XDS-I.b implementers shall group XDS-I.b Actors
with actors from the IHE Audit Trail and Node Authentication and will need an AccessControl capability that operates in such a cross-enterprise environment. New IHE
Integration Profiles have been identified as candidates (e.g., Public Key Infrastructure,
Access Control, etc.). There is a discussion of XDS-I.b security considerations in RAD
TF-1: Appendix H.

___________________________________________________________________________
190
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
2.

XDS and XDS-I.b do not address transactions for the management or configuration of
an XDS Affinity Domain. For example, the configuration of network addresses or thedefinition of what type of clinical information is to be shared is specifically left up to
the policies established by the XDS Affinity Domain.

3.

XDS and XDS-I.b do not specifically address the patient information reconciliation
process necessary between the XDS Affinity Domain and any other local patient
identity domains that Document Sources and Document Consumers may be membersof. For a discussion of some of these issues see RAD TF-1: Appendix G.

4.

XDS and XDS-I.b do not directly address the rendering and display of the documents
retrieved by the Document and Imaging Document Consumers. Users wishing toachieve a well-defined level of display/ rendering capability simply need to request
systems that combine the XDS-I.b Imaging Document Consumer Actor with an Image
Display Actor from the appropriate Profile (e.g., Mammography Image, NM Image,
Basic Image Review, etc.).

5.

XDS and XDS-I.b do not directly address the rendering and display of the documents
retrieved by the Document and Imaging Document Consumers. Users wishing toachieve a well-defined level of display/ rendering capability simply need to request
systems that combine the XDS-I.b Imaging Document Consumer Actor with an Image
Display Actor from the appropriate Profile (e.g., Mammography Image, NM Image,
Basic Image Review, etc.).

18.1 Actors/ Transactions
Figure 18.1-1 shows the actors directly involved in this profile and the transactions between
actors. The shaded XDS actors are NOT actually included in this profile but are included to show
the other endpoint of transactions that ARE part of the profile (e.g., the Document Repository
Actor that is the endpoint for the Provide and Register Imaging Document Set – MTOM/XOPTransaction). As a result, the shaded actors are not listed in Table 18.1-1. The XDS-I.b Profile
does not place any additional requirements on any of these actors above and beyond what it
required of them by the ITI XDS.b Profile.

___________________________________________________________________________
191
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________

Registry Stored Query [ITI-18]←

Document Registry(XDS.b)Imaging Document
Consumer↑ Register
Document Set – b [ITI-42]
Provide & Register Imaging
Document Set – MTOM/XOP [RAD-68]→

Imaging Document
SourceDocument Repository(XDS.b)Document Consumer(XDS.b)Retrieve Document
Set [ITI-43]←

WADO Retrieve [RAD-55] ←Retrieve Imaging Document Set [RAD-69] ←Retrieve Images [RAD-16] ←Retrieve Presentation States [RAD-17] ←Retrieve Reports [RAD-27] ←Retrieve Key Image Note [RAD-31] ←Retrieve Evidence Documents [RAD-45] ←Figure 18.1-1: Cross-Enterprise Document Sharing for Imaging Diagram

Table 18.1-1 lists the transactions for each actor directly involved in the Cross-Enterprise
Document Sharing for Imaging (XDS-I.b) Profile. In order to claim support of this Integration
Profile, an implementation shall perform the required transactions (labeled “R”). Transactions
labeled “O” are optional. A complete list of options defined by this Integration Profile is listed
in RAD TF-1: 18.2. Note the grouping of actors described in RAD TF-1: 2.4.

___________________________________________________________________________
192
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Table 18.1-1: Cross-enterprise Document Sharing for Imaging Integration Profile - Actors
and Transactions
ActorsTransactions

Imaging Document Consumer

Optionality

Retrieve Images [RAD-16]

O (note 1)

4.16

Retrieve Presentation States[RAD-17]

O

4.17

Retrieve Reports [RAD-27]

O (note 1)

4.27

O

4.31

Retrieve Evidence Documents[RAD-45]O (note 1)

4.45

WADO Retrieve [RAD-55]

O (note 1)

4.55

Retrieve Imaging Document Set[RAD-69]

O (note 1)

4.69

Provide and Register Imaging
Document Set – MTOM/XOP [RAD68]

R (note 2)

4.68

Retrieve Images [RAD-16]

R (note 3)

4.16

Retrieve Presentation States[RAD-17]

R (note 3)

4.17

Retrieve Reports [RAD-27]

R (note 3)

4.27

Retrieve Key Image Note [RAD-31],

R (note 3)

4.31

Retrieve Evidence Documents[RAD-45]

R (note 3)

4.45

WADO Retrieve [RAD-55]

R (note 3)

4.55

Retrieve Imaging Document Set[RAD-69]

R (note 3)

4.69

Retrieve Key Image Note [RAD-31]

Imaging Document Source

Section in
Vol. 2

Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to section 18.4 for additional
requirements on the Imaging Document Consumer.
Note 2: Support of at least one of the three document types described by the options in section 18.2 is required.
Note 3: These transactions are only required if the Imaging Document Source supports the ‘Set of DICOM Instances’
option as described in Table 18.2-1.

18.2 Integration Profile Options
Options that may be selected for this Integration Profile are listed in table 18.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified innotes.
Table 18.2-1: Cross-enterprise Document Sharing for Imaging - Actors and Options
Actor

Options

Vol &SectionImaging Document Source

Set of DICOM Instances(Note 1)

RAD TF-1:
18.2.1___________________________________________________________________________
193
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Table 18.1-1: Cross-enterprise Document Sharing for Imaging Integration Profile - Actors
and Transactions
ActorsTransactions

Imaging Document Consumer

Optionality

Retrieve Images [RAD-16]

O (note 1)

4.16

Retrieve Presentation States[RAD-17]

O

4.17

Retrieve Reports [RAD-27]

O (note 1)

4.27

O

4.31

Retrieve Evidence Documents[RAD-45]O (note 1)

4.45

WADO Retrieve [RAD-55]

O (note 1)

4.55

Retrieve Imaging Document Set[RAD-69]

O (note 1)

4.69

Provide and Register Imaging
Document Set – MTOM/XOP [RAD68]

R (note 2)

4.68

Retrieve Images [RAD-16]

R (note 3)

4.16

Retrieve Presentation States[RAD-17]

R (note 3)

4.17

Retrieve Reports [RAD-27]

R (note 3)

4.27

Retrieve Key Image Note [RAD-31],

R (note 3)

4.31

Retrieve Evidence Documents[RAD-45]

R (note 3)

4.45

WADO Retrieve [RAD-55]

R (note 3)

4.55

Retrieve Imaging Document Set[RAD-69]

R (note 3)

4.69

Retrieve Key Image Note [RAD-31]

Imaging Document Source

Section in
Vol. 2

Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to section 18.4 for additional
requirements on the Imaging Document Consumer.
Note 2: Support of at least one of the three document types described by the options in section 18.2 is required.
Note 3: These transactions are only required if the Imaging Document Source supports the ‘Set of DICOM Instances’
option as described in Table 18.2-1.

18.2 Integration Profile Options
Options that may be selected for this Integration Profile are listed in table 18.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified innotes.
Table 18.2-1: Cross-enterprise Document Sharing for Imaging - Actors and Options
Actor

Options

Vol &SectionImaging Document Source

Set of DICOM Instances(Note 1)

RAD TF-1:
18.2.1___________________________________________________________________________
193
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Actor

Options

Vol &SectionPDF Report (Note 1)

RAD TF-1:
18.2.2

Text Report [CDA](Note 1)

RAD TF-1:
18.2.3

No options defined-

Imaging Document Consumer
Note 1: At least one of these three options is required

18.2.1 Set of DICOM Instances Option
This option requires the Imaging Document Source to create a DICOM manifest that references
DICOM instances, and to provide and register this document to the Document Repository. The
Imaging Document Source is required to ensure that the referenced images from within apublished manifest are available to be retrieved. For details of the transaction affected by thisoption, refer to RAD TF-2: 4.68.4.1.2.1.
18.2.2 PDF Report Option
This option requires the Imaging Document Source to provide and register an Imaging Report ina PDF format to the Document Repository. The published report may contain embedded images
or pre-computed links that reference images in a non-DICOM format. The Imaging Document
Source is required to ensure that image references are valid links. For details of the transaction
affected by this option, refer to RAD TF-2: 4.68.4.1.2.2.
18.2.3 CDA Wrapped Text Report Option
This option requires the Imaging Document Source to provide and register an Imaging Report ina Text wrapped into a CDA Document to the Document Repository. For details of the transaction
affected by this option, refer to RAD TF-2: 4.68.4.1.2.2.

18.3 Image Information Sharing Process Flow
The sharing of imaging related information among different health professionals and facilities,
even across administrative and geographic boundaries can lead to a large variety of information
flows. Typical imaging information sets used in healthcare settings are well known, but thechallenge is to distill the “exchange” scenarios to drive the sharing of imaging information acrossenterprises distributed over a community, region or nation.
18.3.1 Overview of Imaging Information Sharing Use Cases
The following use case scenarios express the core imaging information sharing common to mostclinical settings. They cover:
1. Routine imaging referral. The referring physician in his office requests that a patient
have an examination done at an imaging facility. The physician expects to have___________________________________________________________________________
194
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
electronic access to the imaging report and to the images if needed after the examination
has been performed on his patient. This use case is further analyzed in this profile.
2. Course of Treatment Consult. An emergency physician orders an imaging examination
for a patient at his hospital. After reviewing the preliminary report the ER physician
decides to consult a surgical specialist at the regional hospital for advice on a course ofaction. For this, the surgical specialist accesses the images and preliminary report andreviews them in order to propose, on the phone, a course of action for the patient. Thisuse case is further analyzed in this profile.
3. Clinical Consult. A general practitioner performs a routine imaging referral, reviews theshared imaging report and chooses to send the patient for evaluation by a specialist (e.g.,an oncologist). The specialist needs access to the imaging report and full image set
produced at the imaging facility where the patient had been sent by his generalpractitioner to perform the examination. This use case is further analyzed in this profile.
4. General imaging record access. A patient relocates or decides to change her physician.
The new physician needs to retrieve relevant information from the patient record, review
its content, including recent labs and imaging studies. A similar situation occurs when apatient is admitted for an emergency and timely access to the patient’s past information isrequired, including prior imaging studies. This use case is further analyzed in this profile.
This profile describes the information sharing transactions for care-delivering systems to publish
patient’s imaging diagnostic documents (EHR-CR) for sharing across enterprises as longitudinalpatient care records (HER-LR). The policies or administrative details regarding the sharing ofimaging information are for the most part not explicitly discussed so as not to obscure clinicalneeds. Administrative variations between countries and regions are expected, and can be added
or modified without losing the clinical information-sharing context.
Since the focus is on the sharing and access to patients imaging records rather than the entire
workflow in which such information sharing takes place, other activities are described as though
they are being done by telephone, paper mail, fax, etc. In an integrated electronic environment
these other activities may be more automated, but those details are separate from the records
access/sharing and are to be addressed by separate Integration Profiles.
18.3.2 Assumptions
The imaging information needs to be shared between multiple care delivery organizations(information sources and consumers), each (typically) with its own RIS and PACS. The point ofservice (“POS”) for physicians may be supported by a variety of systems: hospital EMR,
physician practice system, PACS viewers, EHR web application, etc.
The concept of sharing information across enterprises that have agreed to join in such a healthinformation network is based on basic design principles that can be summarized in the following
points:___________________________________________________________________________
195
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
1. A group of healthcare enterprises have agreed to work together using a common set ofpolicies and to share a common infrastructure of repositories and a registry for an affinity
domain.
2. Information sources (e.g., EHR, lab system, PACS) select the “documents” they wish toshare.
3. Documents may include any information in an agreed format (e.g., a PDF document, a
DICOM manifest, etc.). Documents are stored in multiple document repositories.
4. Shared documents are registered with a central service called a document registry thattracks only indexing information and the location from which documents may be
retrieved.
5. Information consumers may query this well-defined unique/singular indexing service(document registry) to find the document index information for any patient and thelocation from which documents may be retrieved (document repositories).
6. Information sources remain the owner of the documents shared in repositories and,
thereby, remain responsible for replacing or deprecating its documents if necessary.
In each one of the use cases, it is assumed that the people and the information systems thatparticipate in a single “Affinity Domain” have agreed upon mechanisms to address:
•
•
•
•
•

Governance: operational structure, data stewardship, etc.
Privacy: consent management and data masking controls
Security: Authorization and authentication, network security, audit trails, etc.
Normalized patient ID schemes: MPI (Master Patient Index), unique information IDs, etc.
Coded Vocabularies used for registry information

18.3.3 Use cases
18.3.3.1 Routine Imaging Referral Use Case
This scenario describes imaging information sharing in a typical patient referral and reportinguse case where:••

An examination is performed upon the request of a referring physician:The referring physician accesses the regional health information network and reviews thereport along with the key images and may optionally access the full image set that madethe study.

This scenario is characterized by all the information being provided for sharing at one time, as asingle logical unit, when the imaging study is completed by the radiology enterprise (i.e., a single“document submission set”).

___________________________________________________________________________
196
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
18.3.3.1.1

Process Flow

Figure 18.3.3-1 highlights the people and systems participating in this regional healthinformation network, including:••••Physician Office: A referring physician working out of a private office with a physician
practice system for access to information
RIS/PACS Enterprise A: A radiology enterprise with modality equipment and a
RIS/PACS to manage report and imaging information: Radiology Enterprise A
RIS/PACS Enterprise B: Another radiology enterprise with a RIS/PACS to manage reportand imaging information: Radiology Enterprise B
Document Registry: A document registry that serves as the information index for theregional health information network

In the process flow description, steps that pertain to information sharing are shown in bold (andnumbered). In contrast, the steps that do not pertain to the focus of information sharing areshown in italic (and not numbered). These steps are expressed to ensure a more complete
context.
Figure 18.3.3-2 shows the transaction diagram for this process flow.
Exam is ordered
The Referring Physician orders the examination and the patient goes to the Imaging Department:
Radiology Enterprise A.
This is well-understood workflow that may be executed using any combination of paper, faxes,
telephone, and electronic communications. It may or may not be addressed using the IHE
Scheduled Workflow Integration Profile.
Although this step is part of the use case, it is peripheral to the specific steps for sharing ofimaging of information.
Step 1: Obtain Relevant Prior Imaging Information••

The PACS at Radiology Enterprise A, where the acquisition and reporting is performed,
does a query of the Document Registry to identify relevant prior images and reports. It
should be noted that the determination of what is relevant is the responsibility of theconsumer and not the registry.
The PACS at Radiology Enterprise A retrieves prior imaging information from a
repository in another radiology enterprise within the regional health network: Radiology
Enterprise B, in preparation for study acquisition and subsequent reporting___________________________________________________________________________
197
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Radiology Enterprise B

Prior imaging studies

Querydocument

Prior imaging studies

Registry
Querydocument
Provide Imaging
Information for sharing

Query document

Imaging Study

Radiology Enterprise A

Affinity Domain

Physician Office

Figure 18.3.3-1: Data Flow within the Regional Health Network for a Routine Imaging
ReferralExam is Acquired and Reported
Images are sent from the modality to the PACS. This is well-understood workflow described in
IHE SWF.
The study is reported. This is well understood workflow that is managed by systems withinRadiology Enterprise A
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain)•

The PACS at Radiology Enterprise A, serving as a “Imaging Document Source”,
provides imaging information to the document repository, which register the document in
the registry, for sharing, including:•••Acquired DICOM study
Final report
Key images along with annotations___________________________________________________________________________
198
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Step 3: Obtain and Display Study Results
•

•
•
•

A physician practice system in the Physician’s office, serving as a document consumer,
queries the Document Registry in the regional health network. This query may betriggered by the patient’s next appointment, a call from the patient to the physician’ssecretary, an electronic notification that the examination’s result is available (using theIHE ITI Notification for Document Availability profile), etc.
The physician practice system presents a list of imaging information available for thepatient
The referring physician selects the study results and relevant prior studies and reports
The physician practice system in the Physician’s office, serving as an Imaging Document
Consumer, retrieves the selected documents from the RIS/PACS Document Repositories
in the regional health network and displays them to the referring physician.

Referring Physician reviews the results
The Referring Physician reviews the results of the examination: the report and images from the
RIS/PACS in Radiology Enterprise A, and the results of prior examinations: reports and images
from the RIS/PACS in Radiology Enterprise B
Radiology Enterprise A(Document Consumer)

Radiology Enterprise A(Document Source)Radiology Enterprise A(Document Repository)

Radiology Enterprise B(Document Repository)

Document Registry

Document Consumer(Physician Office)Step 1 - Query for relevant priors
Step 1 - Retrieve relevant prior images and reports

Step 2 - Share Images
and Final Report

Step 2 - Register Images and Final Report
Step 3 - Queryfor Exam

Step 3 - Retrieve Final Report and Images, Relevant
prior images and reports

Figure 18.3.3-2: Process Flow – Routine Imaging Referral Use Case

18.3.3.2 Course of Treatment Consult Use Case
This scenario is a variation on the routine imaging referral use case in that an addendum isgenerated after completion of the final report. As such, this scenario is characterized byinformation being provided for sharing at two separate times while ensuring that the initial
information is supplemented by the addendum report.
The use of addendum reports is commonly encountered in a course of treatment consultation
where:___________________________________________________________________________
199
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
•
•
•

•

An ER physician orders an exam, and the study is acquired in the affiliated radiology
department.
A department radiologist creates and shares a report as well as identifies key images andannotations.
A remotely located surgical specialist, at the request of the ER physician, reviews thereport along with key images and the full study, and provides a consult to the ER
physician (this use case does not constrain the method for communicating the results ofthe consult, e.g., phone, fax, etc.).
The radiologist identifies additional information and completes an addendum to the initialreport.

Note that the scenario where the radiologist seeks an opinion from a more senior radiologist issimilar to this use case.
18.3.3.2.1

Process Flow

The process flow description and steps are as for the routine imaging referral, but with thefollowing variations (shown in bold):Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting
Step 2:Share Imaging Information within the Regional Health Network (Affinity Domain)•

The PACS at Enterprise A, serving as a “Imaging Document Source”, provides imaging
information to the document repository, which register the document in the registry, forsharing, including:•••Acquired DICOM study
ReportKey images along with annotations

Step 3: Obtain and Display Study Results
ER Physician reviews the results
Step 4:Share Addendum to Report within the Regional Health Network (Affinity Domain)•••

Sometime later on, the radiologist creates an addendum to the initial report. Thisaddendum is transcribed into the RIS at Enterprise A and signed off by the radiologist.
This addendum must now supplement the initial report.
The RIS at Enterprise A performs a document query of the document registry for the firstsubmission set
The RIS at Enterprise A, serving as a “Imaging Document Source”, provides theaddendum for sharing to the document registry including the content of the firstsubmission set and declaring the new document as an addendum to the initial report___________________________________________________________________________
200
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
Figure 18.3.3-3 shows the transaction diagram for this process flow.

Rad. Enterprise A
Rad. Enterprise A: PACS
(Document Consumer)(Document Source)

Rad. Enterprise A: RIS(Document Source)

Rad. Enterprise A(Document Repository)

Rad. Enterprise B(Document Repository)

Document Registry

Orthopaedic Centre(Document Consumer)

Step 1 - Query or relevant prior exams
Step 1 - Retrieve relevant prior images and reports

Step 2 - Share images and Initial Report(Submission Set 1)

Step 2 - Register images and report

Step 3 - Query for
exam

Step 3 - Retrieve images and report for new exam

Step 4 - Query for new exam (associated submission set)

Step 4 - Register Addendum
Step 4 - Share
Addendum(Submission Set 2)

Figure 18.3.3-3: Process Flow – Course of Treatment Consult Use Case

18.3.3.3 Clinical Consult Use Case
This scenario is an extension of the routine imaging referral use case in that a consult report isgenerated based from the original imaging exam and radiologist report. As such, this scenario ischaracterized by information being provided for sharing at two separate times by two separate
source systems.
The reports shared in this use case are based on the same initial imaging exam. However thereports are generated by different people and registered by different systems.
The generation of consult reports is commonly encountered in cancer treatment. As such, thefollowing clinical consult use case is used to describe the scenario:
•
•
•
•
•

A general practitioner performs a routine imaging referral (as per Use Case 1).
In reviewing the imaging exam report from the radiologist, the practitioner chooses tosend the patient to an oncologist for a consultation.
The oncologist, located at a Cancer Center, reviews the report along with key images, thefull study, and past imaging information records for the patient
The oncologist generates an additional report that is made available to the generalpractitioner
The general practitioner reviews the oncologists report and takes appropriate treatment
action___________________________________________________________________________
201
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
18.3.3.3.1

Process Flow

Figure 18.3.3-4 highlights the people and systems participating in this regional healthinformation network. These are the same as for the routine imaging referral but with one
additional participant:
•
•
•
•
•

Physician Office
RIS/PACS Enterprise A
RIS/PACS Enterprise B
Document Registry
Oncologist: An oncologist working out of a cancer center: Cancer Center. This center has
an Electronic Health Record (EHR) application that serves as the POS application forreviewing imaging information within the regional health network. The EHR application
has DICOM Viewing capabilities
Radiology Enterprise B

Physician’s OfficePrior imaging studies

Prior imaging
studiesQuerydocument

New Exam

Querydocument

Registry

Prior imaging studies

Querydocument
Provide Imaging
Information for sharing

Provide Imaging
Information forsharing
Query document

Imaging Study

Radiology Enterprise A

Affinity Domain

Cancer Center

Figure 18.3.3-4: Data Flow within the Regional Health Network for a Clinical Consult

The process flow description and steps are as for the routine imaging referral, but with certain
variations. The variations that pertain to information sharing are shown in bold (and numbered).
___________________________________________________________________________
202
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________
In contrast, the variations that do not pertain to the focus of information sharing are shown initalic (and not numbered).
Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain)
Step 3: Obtain and Display Study Results (General Practitioner)••

This is identical to Step 3 in the routine imaging referral use case
Based on the radiology report, the general practitioner determines that a consult with anoncologist is required

Step 4: Obtain and Display Study Results (Oncologist)
•

•
•
•

The EHR application in the oncologist’s office, serving as a document consumer, queries
the document registry in the regional health network. This query is triggered by a consult
request from the general practitioner via paper, fax, phone, and/or electronic notification.
The EHR application presents a list of imaging information available for the patient,including the most recent exam completed at Radiology Enterprise A
The oncologist selects the exam reported by the radiologist as well as a number of
relevant prior exams
The EHR application in the oncologist’s office, serving as an Imaging Document
Consumer, retrieves the documents selected from the RIS/PACS document repositories in
the regional health network and displays them to the oncologist
The oncologist reviews the images using image manipulation tools such as window level,
zoom, pan, invert, measurement, etc. The oncologist may also apply 3D rendering such as
multi-planar reformatting

Oncologist Generates Consult Report••

The oncologist reviews the results of the examination along with prior exams
The oncologist generates a consult report

Step 5:Share Consult Report within the Regional Health Network (Affinity Domain)•

The EHR application in the oncologist’s office, serving as an “Imaging Document
Source”, provides the consult report to the document registry for sharing. This hasreference to the original imaging exam, which was used during the consult.

Figure 18.3.3-5 shows the transaction diagram for this process flow.

___________________________________________________________________________
203
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________

Rad. Enterprise A
Rad. Enterprise A
Rad. Enterprise A
Cancer Centre
Cancer Centre
Rad. Enterprise B(Document Consumer) (Document Source) (Document Repository) (Document Repository) (Document Consumer)(Document Source)

Document Registry

GP Office(Document Consumer)

Step 1 - Query for relevant priors
Step 1 - Retrieve relevant prior images and reports

Step 2 - Register images and report
Step 2 - Share
Images andFInal Report

Step 3 - Queryfor new exam
Step 3 - Retrieve new exam

Step 4 - Retrieve new exam & relevant
priorsStep 4 - Query for new exam andrelevant priors

Step 5 - Query
new exam(associatedsubmission set)

Step 5 - Share Consult Report
Step 5 - Register consult report

Figure 18.3.3-5: Process Flow – Clinical Consult Use Case

18.3.4 Queries
As presented in the use cases, human or machine users may query the Registry in order toretrieve documents in a subsequent step, based on the query result. The type of query attributes
may vary between users or query scenarios, depending on the intent of the query. For instance,
human users often wish to query specifically, restricting the search by several query attributesand values.
The following query attributes are relevant (but not exhaustive):••

Patient Identity – The patient is expected to be identified by Patient ID
Exam Identity – The physician is looking for a specific exam. The attributes used to
identify the exam may include one or more of the following:
•
•
•
•
•

Date
Modality
Body part/anatomical region
Document type – images, diagnosis, progress report, preliminary report, etc.
Author – in the case of reports, the physician may well identify the report by its
author i.e., the radiologist and / or specialist

The metadata in the query response needs to be sufficient to allow the system consumer to parsethe response and identify relevant priors. Relevant metadata includes (but is not limited to):••••Exam date
Modality
Body part/anatomical region
Procedure code___________________________________________________________________________
204
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1: Integration Profiles______________________________________________________________________________

18.4 Consumer Processing
18.4.1 Consumer Processing – Set of DICOM Instances
When the Imaging Document Consumer retrieves a manifest from the Document Repository, it isexpected to decode the Key Object Selection Document Instance in order to find the references
to DICOM objects. The Imaging Document Consumer is also expected to retrieve the referenced
DICOM objects using DICOM retrieve or WADO. It should not make any assumptions about
whether one or more studies are referenced within the Key Object Selection Document.

18.5 Patient Information Reconciliation
These considerations can be found in appendix G.

18.6 Security considerations
All XDS-I.b actors shall be grouped with either a Secure Node or Secure Application actor fromthe ATNA Profile. These actors shall also support the Radiology Audit Trail Option.
This grouping is required to provide the capability for security auditing, for establishing a trust
relationship between systems exchanging information, and to enable secure data exchange.
Some care sites may use alternate mechanisms for providing equivalent security.
Other security considerations can be found in Appendix H.

___________________________________________________________________________
205
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4.16 Retrieve Images
4110

This section corresponds to Transaction RAD-16 of the IHE Technical Framework. Transaction
RAD-16 is used by an Image Display actor to request and retrieve images from an Image
Archive and the Imaging Document Consumer to request and retrieve documents from an
Imaging Document Source actor.
4.16.1 Scope

4115

After the Image Display or Imaging Document Consumer request for image retrieval, therequested DICOM Images are transferred from the Image Archive to the Image Display or fromthe Imaging Document Source to the Imaging Document Consumer for viewing.
4.16.2 Use Case Roles
Image
Archive

ImagingDocument
SourceImage
Display

ImagingDocument
Consumer
Retrieve
Images

4120

Actor: Image Archive:
Role: Sends requested images to the Image Display Actor.
Actor: Imaging Document Source:
Role: Sends requested images to the Imaging Document Consumer Actor.
Actor: Image Display

4125

Role: Receives requested images from the Image Archive Actor.
Actor: Imaging Document Consumer
Role: Receives requested images from the Imaging Document Source Actor.
4.16.3 Referenced Standards

4130

DICOM 2011 PS 3.4: Storage Service ClassDICOM 2011 PS 3.4: Query/Retrieve Service Class_____________________________________________________________________________
186
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.16.4 Interaction Diagram
Image
Display

Image Archive

Retrieve Images (C-MOVE)Store Images (C-STORE)

View Images

ImagigDocument
SourceImagingDocument
Consumer

Retrieve Images (C-MOVE)Store Images (C-STORE)

View Images

4135
4.16.4.1 Retrieve Images

4140

The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes shall besupported. The DICOM Image Storage SOP Classes will be supported by the Image Archive or
Imaging Document Source as an SCU. Refer to DICOM 2011 PS 3.4, Annex C, for detailed
descriptive semantics.

4145

In the case of retrieving images in a Cross-Enterprise, imaging document sharing (XDS-I)
network environment, a configuration of mapping the AE Titles to DICOM AE Network
Addresses (IP Address and Port number) are needed to be exchanged between the Imaging
Document Source and the Imaging Document Consumer. RAD TF-3: Appendix G describes indetails the AE Title mapping to the DICOM AE Network Addresses.

_____________________________________________________________________________
187
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.16.4.1.1

Trigger Events

Images are selected for viewing at the Image Display or Imaging Document Consumer.
4.16.4.1.2
4150

Message Semantics

The message semantics are defined by the DICOM Query/Retrieve SOP Classes and the DICOM
Image Storage SOP Classes.
A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model – MOVE
SOP Class or the DICOM Patient Root Query/Retrieve Information Model – MOVE SOP Class
shall be sent from the Image Display to the Image Archive or from the Imaging Document
Consumer to the Imaging Document Source.

4155

4160

4.16.4.1.3

Expected Actions

The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a
DICOM association with the Image Display or Imaging Document Consumer, respectively, anduses the appropriate DICOM Image Storage SOP Classes to transfer the requested images. The
Image Display or Imaging Document Consumer is expected to support at least one of the SOPClasses specified in table 4.8-1. It is assumed that support of retrieval for a SOP Class alsomeans support for display.
4.16.4.1.3.1 NM Image Profile

4165

Image Manager/Image Archive, Imaging Document Source, Image Displays and Imaging
Document Consumer actors that claim the NM Image Profile shall support all the SOP Classes
specified in Table 4.8-3 in section 4.8.
4.16.4.1.3.2 Mammography Image Profile
Image Manager/Image Archive actors supporting the Mammography Image Profile shall support
all the SOP Classes specified in Table 4.16.4.1.3.2-1.

4170

Image Display actor supporting the Mammography Image Profile shall support all the SOPClasses specified in Table 4.16.4.1.3.2-1.
Table 4.16.4.1.3.2-1: Mammography SOP Classes for Display
SOP Class UID
1.2.840.10008.5.1.4.1.1.1.2

SOP Class Name
Digital Mammography Image Storage – For Presentation

Note that Image Displays are not required to support “For Processing” images.
4175

4.16.4.2 View Images
This transaction relates to the “View Images” event of the above interaction diagram.
_____________________________________________________________________________
188
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.16.4.2.1

Trigger EventsThe Image Display or Imaging Document Consumer is requested to be capable to display theimages.
4180

4.16.4.2.2

Invocation Semantics

This is a local invocation of functions at the Image Display or Imaging Document Consumer.
4.16.4.2.2.1 Display of Digital X-Ray, Mammo and Intra-Oral Images

4185

4190

4195

For the “For Presentation” variant of the Digital X-Ray Image, the Digital Mammography
Image, and the Digital Intra-oral X-Ray Image, the Image Display or Imaging Document
Consumer actor shall have both the capability to apply all the transformations specified by the
VOI LUT Sequence (0028,3010) and the capability to apply all the transformations specified by
the Window Width (0028,1051)/Window Center (0028,1050)/VOI LUT Function (0028,1056)
attributes in the DX Image Module as selected by the user from the choices available (e.g.,guided by Window Center/Width Explanation (0028,1055) or LUT Explanation(0028,3003).
If VOI LUT Function (0028,1056) is absent, then Window Width (0028,1051)/Window Center(0028,1050) shall be assumed to be the parameters of a linear window operation. VOI LUT
Function (0028,1056) values of “SIGMOID” and “LINEAR” shall be supported.
The Image Display or Imaging Document Consumer shall support the application of LUT Data
(0028,3006) in items of the VOI LUT Sequence (0028,3010) regardless of the Value
Representation (i.e., the DICOM standard allows either OW or US Value Representation).
The Image Display or Imaging Document Consumer actor must also support pixel rendering
according to the Grayscale Standard Display Function (GSDF) defined in DICOM 2011 PS 3.14,
because the output values of these images are always P-Values.

4200

If the DICOM image is referenced by other DICOM composite objects, such as Grayscale
Softcopy Presentation States, it is optional for the Image Display or Imaging Document
Consumer to actually retrieve and display/apply these objects.
4.16.4.2.2.1.1 Display of Digital Mammography Images
The contents of this section are required for Image Display claiming the Mammography Image
Profile.

4205

4210

The following requirements are intended to establish a baseline level of capabilities. Providing
more intelligent and advanced capabilities is both allowed and encouraged and the profile is notintended to be limiting in any way with respect to capabilities. The intention is not to dictate
implementation details.
All mammography Image Display actors shall support the Retrieve Images transaction for “For
Presentation” images.

_____________________________________________________________________________
189
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________The Image Display shall be capable of displaying simultaneously a set of current and priorconventional four view screening mammogram images (left and right CC and MLO views),
regardless of whether these images are in one or multiple DICOM Series.
4215

4220

An Image Display that supports the Mammography Image Profile shall support calibration as
described in the DICOM Grayscale Standard Display Function (GSDF). The minimum andmaximum luminance of the display shall be configurable by the site, within the gamut of thedevice, for the purpose of conforming to local, regional or national regulatory and otherrequirements for luminance settings throughout the organization. For example, a site may requirethat all Image Displays used for primary interpretation be calibrated to the same minimum andmaximum luminance.
4.16.4.2.2.1.1.1 Background Air Suppression

4225

Image Display actors shall be capable of recognizing pixels that have the value specified in Pixel
Padding Value (0028,0120) when present alone, and between Pixel Padding Value (0028,0120)
and Pixel Padding Range Limit (0028,0121) inclusive when both elements are present, andsetting them to a minimum display value that is not affected by image contrast adjustments,
including inversion of the image contrast.
4.16.4.2.2.1.1.2 Image Orientation and Justification
Image Display actors shall not assume that the pixel data is encoded with an orientation that issuitable for direct display to the user without flipping or rotating into the correct orientation.

4230

4235

4240

4245

The Image Display actor shall use the values of Image Laterality (0020,0062), View Code
Sequence (0054,0220), View Modifier Code Sequence (0054,0222) and Patient Orientation(0020,0020) to display images according to the preferred hanging protocol of the current user,
rather than depend on descriptive attributes such as Series Description (0008,103E).
The Image Display shall allow the user to select or configure hanging protocols such that given a
set of images containing these attributes, the placement of images relative to one another, therequired orientation of the images, the display of current and prior images, and the sequence oflayouts displayed can be defined.
Note that images are normally displayed such that the axilla is towards the top of the viewport,
except for cleavage views (which contain two axillas). The location of the axilla can be
determined from the direction of the head encoded in Patient Orientation (0020,0020) in the caseof lateral and oblique views, and the Image Laterality (0020,0062) in the case of cranio-caudal or
caudo-cranial views. For cleavage views, indicated by the presence of a View Modifier Code
Sequence (0054,0222) Item containing (R-102D2, SNM3, “Cleavage”), either axilla may be at
the top of the view port.
The Image Display shall be able to distinguish and display separately images with one or more
Items in a View Modifier Code Sequence (0054,0222) from each other and those without a View
Modifier Code Sequence (0054,0222) Item.

_____________________________________________________________________________
190
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4250

The Image Display shall be capable of horizontally justifying the image to the left or right side of
the viewport rather than centering it, when the aspect ratio (ratio of the number of rows andcolumns) of the viewport does not match aspect ratio of the image, in order to avoid displaying
any unnecessary padding between the adjacent chest walls of back to back images; excessive
window decoration (such as scroll bars) shall not be displayed between back to back viewports.
4.16.4.2.2.1.1.3 Image Size

4255

The physical size of the pixels in an image for the purposes of the display modes defined in thissection shall be approximated by using the values of Imager Pixel Spacing (0018,1164).
The physical size of the pixels in an image for the purposes of distance measurements and thedisplay of a distance caliper shall be approximated by using the values of Imager Pixel Spacing(0018,1164) divided by Estimated Radiographic Magnification Factor (0018,1114).

4260

4265

4270

For contact (unmagnified) views, the value of Estimated Radiographic Magnification Factor(0018,1114) is typically 1, or close to 1, depending on the distance between the detector side of
the compressed breast and the front of the detector housing (the latter being the plane in which
Imager Pixel Spacing (0018,1164) is defined), and what depth the nominal location of the object
plane is within the compressed breast.
For magnification views, the spacing between the detector side of the compressed breast and thedetector is increased substantially relative to the distance to the x-ray source to obtain geometricmagnification, and Estimated Radiographic Magnification Factor (0018,1114) will have a value
substantially greater than 1.
Pixel Spacing (0028,0030) shall not be used to determine size for the purpose of sizing for
display or distance measurements. DICOM CP 586, which clarifies the meaning of Pixel Spacing(0028,0030) values that differ from Imager Pixel Spacing (0018,1164) values when an image has
been calibrated by use of a fiducial of known size within the image, is not relevant tomammography applications.
Note that the use of Imager Pixel Spacing (0018,1164) is sufficient regardless of the physicalsize of the detector used.

4275

4.16.4.2.2.1.1.3.1 Same Size
The Image Display shall be capable of displaying multiple images such that all images are at thesame relative physical size, regardless of whether they have the same values of Imager Pixel
Spacing (0018,1164) or not.

4280

4285

For example, a user reviewing a four-view screening mammogram together with a four-view
prior mammogram might want to display eight viewports, each showing one view, such that theeach view is at the same relative physical size, even if the images were obtained on detectors
with different sized pixels. This allows the user to compare features in the prior and current
images to visually assess whether or not they have changed in size.
Note that it is not expected that the Image Display attempt to compensate for the location of theobject within the compressed breast of finite thickness along the x-ray beam, since the_____________________________________________________________________________
191
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
convention for measurement from film-screen practice assumes that all objects are located at thecassette (detector) side of the breast.

4290

This mode of display is not intended for comparison of geometrically magnified views at thesame time as non-magnified views, since the geometrically magnified view would then be
displayed too small.
4.16.4.2.2.1.1.3.2 True Size
The Image Display shall be capable of displaying multiple images such that all images are true
size, regardless of whether they have the same values of Imager Pixel Spacing (0018,1164) or
not.

4295

True size is defined as the display of an image such that an object in the image when measured
with a hand-held ruler on the surface of the display measures as closely as possible to the true
physical size of the object if located on the front face of the detector housing.
This mode of display is not intended for geometrically magnified views, since the geometricallymagnified view would then be displayed too small.

4300

4.16.4.2.2.1.1.3.3 View Actual Pixels
The Image Display shall be capable of displaying multiple images such that each encoded pixel
occupies one display pixel in the viewport.

4305

If the size of the pixel data exceeds the size of the viewport, it may not be possible to display allof the encoded pixels at once, in which case some form of pan or quadrant navigation
functionality shall be provided.
Since there is no minification or magnification, images with different pixel physical size will be
displayed in this mode such that the physical size in the patient will appear different.
4.16.4.2.2.1.1.4 Image Contrast Adjustment

4310

As described in 4.16.4.2.2.1 Display of Digital X-Ray, Mammography and Intra-Oral Images,
the Image Display shall provide the user with the ability to select amongst the available window
and VOI LUT choices available in the image object.
Subsequent to the initial application of the chosen contrast transformation, the Image Display
actor shall allow the user to adjust the contrast without reverting to a purely linear
transformation:

4315

4320

•

If the chosen contrast transformation is a lookup table, then the Image Display shall allow
the input value of the lookup table to be stretched and translated so as to give the affect ofadjusting contrast and brightness whilst applying the same general shape as the curve
encoded in the lookup table. To provide feedback to the user, the “window width” can bereported as the adjusted range of input values to the LUT, and the “window center” canbe reported as the center value of that range.

_____________________________________________________________________________
192
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
•

4325

4330

If the chosen contrast transformation is a sigmoid shaped VOI LUT Function
parameterized by the window center and width, then the Image Display shall allow thewindow center and width values to be adjusted and a sigmoid function reapplied.

If a Pixel Padding Value (0028,0120) only is present in the image then image contrast
manipulations shall be not be applied to those pixels with the value specified in Pixel Padding
Value (0028,0120).
If both Pixel Padding Value (0028,0120) and Pixel Padding Range Limit (0028,0121) are present
in the image then image contrast manipulations shall not be applied to those pixels with values in
the range between the values of Pixel Padding Value (0028,0120) and Pixel Padding Range
Limit (0028,0121), inclusive.
4.16.4.2.2.1.1.5 Annotation of Image Information
Quite apart from good practice, there are nationally-specific requirements for information to be
displayed (or displayable) to the user in order to ensure correct identification of the patient andstudy during reporting and review as well as the resolution of quality issues.

4335This profile defines the union of currently known and anticipated nationally-specificrequirements with respect to annotation.
It is desirable that the subset of attributes displayed be configurable by the user or the site.

4340

If annotations are overlayed on the displayed image, the Image Display shall not annotate theedge that contains the chest wall, as determined from (0020,0020) Patient Orientation, so as to
avoid covering breast tissue.
4.16.4.2.2.1.1.5.1 Annotation of Identification Information
The Image Display shall be capable of displaying the information contained in the attributes
listed in Table 4.16.4.2.2.1.1.5.1-1. The required information is defined in two categories:

4345

4350

•
•

Clinical - Those attributes that are useful during interpretation and review of the images
for clinical purposes, and which under normal circumstances should be displayed
Investigative - Those attributes that are useful for investigative purposes, such as to trace
a quality problem, and which under normal circumstances are a distraction and should not
be displayed until requested by the user
Table 4.16.4.2.2.1.1.5.1-1: Identification Attributes for Display
Tag

Requirement

Patient’s Name

Attribute(0010,0010)

ClinicalPatient ID(0010,0020)

ClinicalPatient’s Birth Date

(0010,0030)

ClinicalPatient’s Age(0010,1010)

ClinicalAcquisition Date

(0008,0022)

ClinicalAcquisition Time

(0008,0032)

Clinical_____________________________________________________________________________
193
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Tag

Requirement

Operator’s Name

Attribute(0008,1070)

ClinicalManufacturer(0008,0070)

Investigative

Institution Name

(0008,0080)

ClinicalInstitution Address(0008,0081)

Investigative

Manufacturer’s Model
Name(0008,1090)

Investigative

Device Serial Number(0018,1000)

Investigative

Detector ID(0018,700A)

Investigative

Software Versions(0018,1020)

Investigative

Station Name

(0008,1010)

ClinicalGantry ID(0018,1008)

Clinical (for CR
overrides Station
Name, which isplate reader)

Date of Last Detector
Calibration(0018,700C)

Investigative

Note that it is common practice to use the Operator’s Name (0008,1070) to encode the initials
rather than the full name of the operator, and this is sufficient to meet known regulatory
requirements.
4355

4360

Note also that Station Name (0008,1010) (or Gantry ID (0018,1008) for CR) are typically short,human-recognizable strings meaningful to the users, and are preferred for satisfying any
regulatory requirement for “mammography unit identification” over the more cryptic but precise
attributes like Device Serial Number (0018,1000).
The Image Display shall make the investigative set of values available to the ordinary user, butthese need not necessarily be annotated directly on the image, e.g., they might be displayed in a
separate pop-up window.
It shall be possible to turn on or off either set of annotations at the user’s discretion.
4.16.4.2.2.1.1.5.2 Annotation of Technical Factor Information

4365

Good practice dictates that certain technical factors be displayed (or displayable) to the user inorder to detect and resolve quality issues.

4370

In addition, there are technical factors that are unique to the digital realm. One such factor isrelated to the adjustment of the sensitivity and/or dynamic range of the sensor or processing,corresponding to the amount of radiation reaching the detector. These are variously referred toby manufacturers as ADU, exposure index, or sensitivity. Note that interpretation of this value isvendor-specific, though may be standardized in the future by AAPM.
The Image Display shall be capable of displaying the information contained in the attributes
listed in Table 4.16.4.2.2.1.1.5.2-1.
_____________________________________________________________________________
194
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Table 4.16.4.2.2.1.1.5.2-1: Technique Attributes for Display
Attribute

4375

Tag

KVP

(0018,0060)

Exposure(0018,1152)

Exposure Time

(0018,1150)

Filter Material(0018,7050)

Anode Target Material(0018,1191)

Compression Force(0018,11A2)

Body Part Thickness(0018,11A0)

Positioner Primary Angle(0018,1510)

Relative X-ray Exposure(0018,1405)

Entrance Dose in mGy(0040,8302)

Organ Dose(0040,0316)

It shall be possible to turn on or off the annotations at the user’s discretion.
4.16.4.2.2.1.1.5.3 Annotation of View Information
Traditional film-screen practice requires the use of lead markers consisting of letters encoding
the type of view, located in the corner of the film that is opposite the chest wall and towards theaxilla.

4380

4385

Image Displays shall mimic this practice by annotating the viewport with abbreviations derived
from the value of Image Laterality (0020,0062), View Code Sequence (0054,0220) and any
values of View Modifier Code Sequence (0054,0222) Items that are present.
Unless otherwise overridden by nationally specific extensions, the specific abbreviations to be
displayed are as defined in the View Modifier Abbreviations Column of CID 4014 and CID 4015
of DICOM PS 3.16, which is derived from ACR MQCM 1999, with the following clarifications:
•
•

4390
•
4395

•
•

The Image Laterality shall be prepended to the abbreviation, e.g., a right CC view shallbe displayed as “RCC”
A CC view with a cleavage modifier shall be annotated as only “CV” if Image Laterality
has a value of “B”, i.e., the “CC” shall not be displayed, and the laterality shall beomitted (in which case the left and right breast can be determined from the value ofPatient Orientation (0020,0020)); otherwise “LCV” or “RCV” shall be used
A right MLO view with the axillary tail modifier shall be annotated only as “RAT”, i.e.,the “MLO” shall not be displayed
The implant displaced modifier shall be appended as a suffix to the view, as if it were
defined as “…ID”, e.g., a right implant displaced CC view would be annotated as“RCCID”
A spot compression modifier shall be prepended as a prefix to the view, as if it were
defined as “S…”, e.g., a left spot compression CC view would be annotated as “LSCC”_____________________________________________________________________________
195
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4400

•
•

A tangential modifier shall be annotated as only “TAN”, i.e., the “CC” or whatever elseis encoded as the view, shall not be displayed
When multiple prefix or suffix modifiers are present, they shall be sorted alphabetically,e.g., a right magnified, spot compression, implant displaced, rolled lateral CC view would
be annotated as “RMSCCIDRL”

Spaces and other delimiters are permitted between components of the abbreviations.
4405

4410

Prior to any flip or rotation for display, the location of the corner opposite the chest wall andtowards the axilla can be determined from the direction of the chest wall encoding in Patient
Orientation (0020,0020), regardless of view, and the direction of the head encoded in Patient
Orientation (0020,0020) in the case of lateral and oblique views, and the Image Laterality(0020,0062) in the case of cranio-caudal or caudo-cranial views. For cleavage views, the axilla at
the top of the viewport shall be annotated. See also 4.16.4.2.2.1.1.2 Image Orientation andJustification.
It shall be possible to turn on or off the annotations at the user’s discretion.
4.16.4.2.2.1.1.6 Annotation of Size Information

4415

For the purpose of this section, physical pixel size is as defined in Section 4.16.4.2.2.1.1.3 ImageSize.
The user needs to be aware when the displayed image does not reflect a 1:1 rendition of an
encoded image pixel to a displayed pixel, i.e., that some magnification or minification has takenplace. Anything other than 1:1 rendition may result in loss or distortion of information.

4420

Further, the user needs to be aware of whether or not the image is displayed at true size, andwhether or not different images are at the same relative physical size.
Therefore, the Image Display shall be capable of annotating the displayed images with thefollowing:
•

4425

4430

•

Pixel Size Magnification - Number of displayed pixels relative to the number of encoded
image pixels, such that a factor of 1.0 (or 100%) means 1:1 rendition, a factor of less than
1.0 means that one pixel on the display represents more than one pixel in the encoded
image (minification), and a factor of greater than 1.0 means that pixels in the encoded
image have been replicated or interpolated to span multiple displayed pixels(magnification)
True Size Magnification - Size of the displayed pixels relative to true size, such that afactor of 1.0 (or 100%) means true size, a factor of less than 1.0 means smaller than true
size, and a factor of greater than 1.0 means larger than true size

The exact form of these two relative pixel size indications is left to the discretion of theimplementer.
4435

The Image Display shall be capable of displaying a ruler or caliper indicating the physical size ofthe displayed image, for the purpose of providing a visual cue to the user of the general size ofthe features in the image. It shall be possible to turn on or off the ruler at the user’s discretion.
_____________________________________________________________________________
196
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________The Image Display shall provide a means of accurately measuring distance between two points
based on the physical size of the image pixels.
4.16.4.2.2.1.1.7 Partial View Option
4440

If the Image Display supports the Partial View Option, it shall additionally annotate thedisplayed image in the view port to indicate:
•

4445

•

when the image is a partial view, as defined by the presence of Attribute Partial View
(0028,1350) with a value of YES
which region of the mosaic the image represents, as encoded in Partial View Code
Sequence (0028,1352), if present

Whether or not this annotation is textual or in the form of some iconic graphic representation,
and whether or not any navigational or layout assistance is provided for the entire mosaic is at
the discretion of the implementer.
4.16.4.2.2.1.1.8 Display of CAD Marks
4450

4455

4460

Image Displays shall be able to apply marks on the displayed image corresponding to all findings
encoded in Mammography CAD SR objects with a (111056, DCM, “Rendering Intent”) value of(111150, DCM, “Presentation Required”). They may be able to display additional findings thathave a (111056, DCM, “Rendering Intent”) value of (111151, DCM, “Presentation Optional”).
The Image Display shall make the user aware that CAD marks are available for display, andindicate whether or not CAD marks are currently activated. More than one set of CAD objects
could be available that are applicable to the same image (e.g., CAD was run more than once on
the same images). If this is the case then all CAD SRs shall be made available for display on thereview workstation with the most recent CAD SR (by Content Date/Time) being displayed bydefault. The user shall be able to choose which CAD SR object is to be displayed.
Only a single CAD SR object at a time shall be applied to a displayed image.
The Image Display shall be able to apply the marks to “For Presentation” images that arereferenced by the Mammography CAD SR SOP Instance.

4465

4470

The Image Display shall also be able to apply the marks to “For Presentation” images whose
Source Image Sequence references the SOP Instance UID of the “For Processing” images thatare referenced by the Mammography CAD SR SOP Instance, unless the Spatial Locations
Preserved (0028,135A) is present in the Source Image Sequence Item and has a value of NO.
The Patient Orientation of the images referenced in the Source Image Sequence encoded in(111044, DCM, “Patient Orientation Row”) and (111043, DCM, “Patient Orientation Column”)
of the Mammography CAD SR SOP Instance shall be used to transform (flip or rotate) the
coordinates of the CAD marks if it differs from the Patient Orientation (0020,0020) of thecorresponding “For Presentation” image.
The form in which the CAD marks are displayed may influence observer performance, andhence it may be necessary to display them in a manner prescribed by the CAD device vendor,_____________________________________________________________________________
197
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4475

which is not encoded in the DICOM object. The form of the CAD mark rendering is out of thescope of this profile to define.
The Image Display shall make available for display the following information about each CAD
finding, if encoded in the CAD object:

4480

4485

•
•
•
•

Manufacturer (0008,0070)
Algorithm as defined in (111001, DCM, “Algorithm Name”) and (111003, DCM,
“Algorithm Version”)
Operating point as defined in (111071, DCM, “CAD Operating Point”)
Content Date (0008,0023) and Content Time (0008,0033) of the CAD SR instance, if
more than one exists and applies to the displayed image

The Image Display shall indicate when CAD was not attempted or has failed, either entirely, or ifsome algorithms have succeeded and others failed, as distinct from when CAD has succeeded
but there are no findings. This information shall be obtained from the status values of (111064,
DCM, “Summary of Detections”) and (111065, DCM, “Summary of Analyses”).
4.16.4.2.2.1.1.9 Post-Processing of For Presentation Images

4490

This profile does not constrain the ability of the Image Display to further post-process “For
Presentation” images, for example with edge enhancement or noise reduction.
However, there shall be a mode in which actual pixels of “For Presentation” images are
displayed not only with 1:1 display to encoded pixel size, but with no further processing orinterpolation other than application of point grayscale transformations.
4.16.4.2.2.1.1.10 Accidental reading of prior studies

4495

4500

There is a significant risk that during primary interpretation the most recently available priorstudy on the Image Display will be interpreted by the user as the current study, if for somereason the current study is not available.
Accordingly, it is required that an Image Display explicitly warn the user if none of the studies
being displayed are within a user configurable period from the current real time, as determinedby Acquisition Date (0008,0022).
4.16.4.2.2.2 Display of Localizer Lines
Image Display or Imaging Document Consumer actors that want to show the localizer lines, if
visible, will be able to calculate the position of these lines of intersection based on theinformation recorded in the images by the Acquisition Modality actor (See 4.8.4.1.2.1).

4505

4.16.4.2.2.3 Display of NM Images
The contents of this section are required for Image Displays claiming the NM Image Profile.
The following requirements are intended to establish a baseline level of capabilities. Providing
more intelligent and advanced capabilities is both allowed and encouraged. The intention is tofocus on display capabilities, not to dictate implementation details.
_____________________________________________________________________________
198
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4510

Note that the NM Image profile is undergoing revision, and vendors considering implementation
are advised to include the modifications contained in the trial implementation version “NMImage Profile with Cardiac Option”. For additional information please contact the IHE
Radiology Technical Committee at IHE-Rad-Tech@googlegroups.com.
Some examples of display behaviors typical to NM are described in RAD TF-1, Appendix E.5.3.

4515

The NM Image IOD is a multi-frame image indexed by vectors as described in Section
4.8.4.1.2.2.1. “Image” will be used here to strictly refer to the IOD, while frame will be used torefer to the usual two-dimensional array of pixels.
The Image Display shall be able to display the frames in the order they are stored in the image.

4520

The Image Display shall be able to perform the frame selections shown for each Image Type in
the Table 4.16-1 and as described below in 4.16.4.2.2.3.1 Frame Selection Support. The resultof a frame selection will be referred to as a “frameset” in this document. Note that a frameset
only references frames from a single Image.
The Image Display shall be able to display simultaneously multiple framesets. These may befrom the same Image, different Images, different Series, or different Studies.

4525

The Image Display is not required to display simultaneously multiple framesets with different
Image Types. (Note that two exceptions to this are identified in 4.16.4.2.2.3.5 Review Option).
The Image Display shall be able to display simultaneously at least the number of framesets
indicated in table 4.16-1.

4530

All frames in the displayed frameset(s) are not required to be on the screen at once; if there are
more frames than fit on the screen based on the current frame display size (see Section
4.16.4.2.2.3.4 Image Zoom), the ability to scroll through the frames is required.
The Image Display shall be able to display, if present, the View Code Sequence (0054,0220),
Acquisition Context Sequence (0040,0555), Series Description (0008,103E) and Acquisition
Time (0008,0032) values for a given frameset.

4535

The Image Display is required to support the display capabilities for each Image Type shown intable 4.16-1.
Table 4.16-1: Selection, Sorting and Viewing Requirements for NM Images
Image Type
(0008,0008)
Value 3

STATIC

WHOLE BODY

Frame
Increment Pointer(0028,0009)[i.e., vectors]

RequiredFrame
1
Selection
E = single
E = all

Display
Capabilities(See 4.16.4.2.2.3.2)# ofSimultaneous
Framesets

Energy Window(0054,0010)
Detector (0054,0020)

ED
ED
ED*

Grid Display

1

1

Fit Display

12

12

Cine

-

1
(optional))

Energy Window(0054,0010)

ED

Whole body Display

2

42

Review
Basic Option_____________________________________________________________________________
199
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Image Type
(0008,0008)
Value 3

DYNAMIC

GATED

TOMO

GATED TOMORECON TOMO

GATED
RECON
TOMO

4540

4545

Frame
Increment Pointer(0028,0009)[i.e., vectors]

RequiredFrame
1
Selection
E = single
E = all

Display
Capabilities(See 4.16.4.2.2.3.2)# ofSimultaneous
Framesets
Review
Basic Option

Detector(0054,0020)

ED
ED*

Energy Window(0054,0010)
Detector (0054,0020)
Phase (0054,0100)
Time Slice (0054,0030)

EDPT
EDPT
EDPT

Grid Display

1

1

Comparison Display

1

2

Cine

1

2

Energy Window(0054,0010)
Detector (0054,0020)
R-R Interval (0054,0060)
Time Slot(0054,0070)

EDIT

Grid Display

1

1

Energy Window(0054,0010)
Detector (0054,0020)
Rotation (0054,0050)
Angular View (0054,0090)

EDRA

Energy Window(0054,0010)
Detector (0054,0020)
Rotation (0054,0050)
R-R Interval (0054,0060)
Time Slot (0054,0070)
Angular View (0054,0090)

EDRITAEDRITAEDRITA- any one ofabove three

Slice(0054,0080)

S

R-R Interval (0054,0060)
Time Slot(0054,0070)
Slice (0054,0080)

ITS
ITS
ITS*

Comparison Display

3

6

Cine

3

6

Grid Display

1

1

Comparison Display

3

3

Cine

3

3

Grid Display

1

1

Cine

1

1

Grid Display

1

1

Comparison Display

3

6

Cine

3

3

MPR Display-

1

Grid Display

1

1

Comparison Display

1

2

Cine

-

2

MPR Display-

1

Note 1: The Frame Selection column refers to the Frame Increment Pointer vectors by their first letter (except for R-R
Interval which uses “I” for Interval). A letter shown underlined and bold (e.g., E) indicates that all values for that
vector are selected. A letter shown in plain text (e.g., E) indicates that a single value for that vector has been
selected. So in the case of the TOMO Image Type, E R D A means that all frames of the image are selected; while E
R D A means that the selected frames represent all Angular Views for a specific Energy Window, a specific Detector
and a specific Rotation. An asterisk (*) indicates that it is required under the review option only, and not required
under the basic NM Image profile.
Note 2: The requirement for 4 framesets is to handle the case where the 4 frames are in separate framesets due to theanterior and posterior views being in separate images. It is not required to support 4 framesets with 2 frames each.

_____________________________________________________________________________
200
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.16.4.2.2.3.1 Frame Selection Support
4550

4555

4560

A Frame Selection consists of either a single value, or “all values” being identified for each
vector in the Image. In fact (except for the case of selecting “all frames” and the case of
selecting all phases and time slices in a Dynamic Image) a single value will be identified for all
but one of the available vectors.
It is not necessary to require the user to specify a value for single valued vectors, such as when,for example, only a single detector value is present. It is desirable for the application to provide
a way to make a selection when a vector that is typically single valued unexpectedly has
additional values.
When selecting values for certain vectors, the user shall be presented with meaningful terms, if
available, rather than the underlying integer values from the DICOM vector. For example, in thecase of the detector vector, if the View Code Sequence it present, the terms contained there (e.g.,“Anterior”, “Posterior”) shall be used instead of the Detector Number from the vector.
The sources of selection terms in priority order (i.e., the first, if present shall be used, otherwise
consider the next) are shown in the following table:
Table 4.16-2: Sources of Value Selection Terms for Vectors

4565

Vector

Source of Selection Terms

Energy Window

1. Energy Window Name (0054,0018)
2. Energy Window Lower Limit (0054,0014) &Energy Window Upper Limit (0054,0015)
3. Energy Window Number

Detector

1. View Code Sequence (0054,0220)
2. Detector Number

Phase

1. Phase Description (0054,0039)
2. Phase Number

Rotation

1. Rotation Number

R-R Interval

1. R-R Interval NumberTime Slot

1. Time Slot Number

Angular View

1. Angular View Number

Slice

1. Slice Number

One method of allowing the user to select a frameset by vectors might be to display a multivectored image to the user as if it were broken down into its components by vector. For
example, a 2-phase dual-detector GI bleed study might be shown to the user as
GI-bleed Phase-1 Anterior
GI-bleed Phase-1 Posterior

4570

GI-bleed Phase-2 Anterior
GI-bleed Phase-2 Posterior_____________________________________________________________________________
201
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4575

This is acceptable as a means of frame selection support, provided the user has the option of
selecting all the parts of the image for display as at the same time, should the user desire to do so,and provided that the multi-vectored image remains as a single image if it is sent via DICOM toanother system.
4.16.4.2.2.3.2 Display Capabilities
Image Displays are required to support the following display formats as indicated above in Table
4.16-14580

Practical examples of the usage and appearance of these display capabilities can be found in
RAD TF-1 Appendix E.5 NM Display and in particular in RAD TF-1, Appendix E.5.3 NM
Display Examples.
4.16.4.2.2.1.1.1

Grid Display

For Grid Display, the Image Display shall display a single frameset arranged in a 2D grid offrames.
4585

4.16.4.2.2.1.1.2

Fit Display

For Fit Display, the Image Display shall display several framesets simultaneously. Efficient useof screen space is encouraged. The Image Display is free to organize the frames any way that
seems sensible. In the absence of other useful information, it is common to display them in orderof acquisition time.
4590

4.16.4.2.2.1.1.3

Comparison Display

For Comparison Display, the Image Display shall display several framesets simultaneously in a
fashion such that frames in the two framesets can be compared. For example, each frameset
could be placed on an adjacent row.
4595

Display of each frameset in a single row (i.e., the number of rows equals the number offramesets) is required. Support for more than one row per frameset is optional.
Comparison requires that the relationship between frames in the two framesets be maintained
when navigating, and to be adjusted separately/established.
4.16.4.2.2.1.1.4

4600

Whole Body Display

For Whole body Display, the Image Display shall simultaneously display of both the anterior andposterior frames of an NM whole body image.
These images will typically be rectangular in shape (taller than wide) and are typically 256 x
1024 or 512 x 1024 in size. The display system should display them as rectangular frames (andnot pad them to make them square).

_____________________________________________________________________________
202
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.16.4.2.2.1.1.5
4605

4610

4615

MPR (Multi-Planar Reconstruction) Display

For MPR Display, the Image Display shall provide MPR capabilities for slice stack data.
Typically, MPR involves displaying three orthogonal plane views at the same time along with amethod of navigating the volume (i.e., controlling the specific sagittal, coronal and transaxial
images shown).
The Image Display is not required to generate oblique slices from slice data, but is required togenerate orthogonal slices even if the slice data is obliquely oriented.
In the NM Image Profile, MPR Display shall be supported when claiming the Review Option(See section 4.16.4.2.2.3.5). When displaying NM Data, the Image Display shall be specificallycapable of taking a frameset of slice data from a RECON TOMO or GATED RECON TOMO
image and displaying all three orthogonal plane views (transaxial, saggital and coronal). PETtransaxial data in the MPR display is strongly encouraged, but not required under the NM
Profile.
Refer to DICOM documentation for details on how orientation and spatial information is
encoded in the NM Image IOD.
4.16.4.2.2.1.1.6

4620

Cine Display

The Image Display shall be able to display a cine of the selected frames as indicated by the order
they are stored in the Image.
The Image Display shall be capable of displaying cines of multiple framesets simultaneously as
indicated above in Table 4.16-1.

4625

When the framesets have the same number of frames, the Image Display shall be capable ofdisplaying the cines in synchronization (i.e., the first frame of each frameset should display
simultaneously, the second frame of each frameset should display simultaneously, etc.).
The Image Display shall provide the ability to adjust intensity (as described below in Section
4.16.4.2.2.3.3) for each frameset independently. The ability to adjust intensity while a cine isrunning is useful but not required.

4630

4.16.4.2.2.3.3 Intensity and Color
NM clinical practice requires the ability to adjust the Upper and Lower Window Levels rather
than the Window Center and Window Width. Refer to RAD TF-1, Appendix E.5.1 for details on
NM usage of intensity and color attributes.

4635

For all images with a modality type of NM, the Image Display shall provide direct control over
the Upper Window Level and the Lower Window Level display parameters independently fromeach other for both grayscale and pseudocolor display.
This control shall be available for all frames as a group and for each frameset individually.
Optionally is it also useful to support adjustment of individual frames.

4640

Window Level values shall be translated into equivalent Window Width and Center values whenstored in the image attributes.
_____________________________________________________________________________
203
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________The Image Display shall be capable of effectively “inverting” the image (in the sense ofswitching between a MONOCHROME1 and MONOCHROME2 interpretation). The method isundefined. This requirement applies to grayscale image display only; it is not required forpseudo-color lookup tables.
4645

If the Image Display supports a color screen, the following shall be supported:
The Image Display shall support display of frames of grayscale Images using a pseudo-color
lookup table.

4650

The Image Display shall allow the user to select from a configured set of pseudo-color lookup
tables. Simultaneous display of both grayscale and pseudo-color presentations is not required.
Thus, selecting a color lookup table may change all displayed frames on the screen.
The Image Display shall provide a method of adding new pseudo-color lookup tables. It is
acceptable if this is only available to service engineers.
4.16.4.2.2.3.4 Image Zoom

4655

The Image Display shall be capable of “zooming” the frames where zooming consists ofresampling and displaying the frame at a larger or smaller matrix size. For example re-samplinga 128x128 frame to create a 256x256 frame is referred to as a 2X zoom in this document.
All zooming of NM images shall preserve the aspect ratio (that is, the same zoom factor shall beapplied in both the x and y dimensions). The Image Display is free to use pixel replication orinterpolation to perform image zooming.

4660

Some guidelines on appropriate default display sizes and desirable zoom behaviors are provided
in RAD TF-1, Appendix E.5.2 NM Image Resizing.
4.16.4.2.2.3.5 Review Option
Image Displays claiming the Review Option shall support the following display capabilities andthose indicated in Table 4.16-1.

4665

The Image Display shall be capable of displaying both a Dynamic Image frameset and Static
Image frameset(s) at the same time.
The Image Display shall be capable of displaying both a Whole body Image frameset and a
Static Image frameset at the same time (i.e., anterior & posterior whole body and several static
spot images).

4670

The Image Display shall be capable of displaying the pixel value of a selected pixel.
4.16.4.2.2.4 Display of Result Screens
The contents of this section are required for Image Displays claiming the NM Image Profile.
Refer to Table 4.18-2 for the specific SOP Class UIDs of the IODs referenced here for use as
Result Screens.

_____________________________________________________________________________
204
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4675

The Image Display shall be able to display DICOM Secondary Capture images (including
specifically 8 and 16 bit monochrome and 24 bit RGB).
The Image Display shall be able to display DICOM Multi-Frame Secondary Capture images(including specifically 8-bit monochrome and 24-bit True Color)

4680

4685

The Image Display shall be able to display result screens at their original pixel resolution. If thedisplay size is equal to or greater than the size of the result screen, this should be done as thedefault. If the display size is less than the size of the result screen, this will require some sort ofpanning capability.
The Image Display shall be able to scale result screens using a fixed aspect ratio. If the display
size is smaller than the size of the result screen, this should be done to fit the result screen onto
the display as the default.
For Multi-Frame Secondary Capture images which contain a Cine module, the Image Display
shall be able to cine the frames. The default cine rate shall be the value in the Cine module, or
the maximum rate of the Image Display, whichever is slower.
4.16.4.2.3

4690

4695

Expected Actions

The Image Display or Imaging Document Consumer presents to the user a DICOM Image.
The Image Display or Imaging Document Consumer may receive patient data inconsistent withthose received from a previously issued query or retrieve operation. For example, in the eventthat a patient has been renamed, the Image Display or Imaging Document Consumer will receive
images with the same Study Instance UID, Series Instance UID and SOP Instance UIDs, but witha different patient name. The Image Display or Imaging Document Consumer shall use the justqueried information or the most recently received instances to ensure that the most recent patient
data from the Image Manger/Archive or Imaging Document Source is displayed.
The Image Display or Imaging Document Consumer shall be able to display the Series
Description for each series displayed.

4700

4.16.4.2.3.1 NM Image Specifics

4705

Actors claiming the NM Image Profile which have applications that accept re-sliced(reconstructed tomographic) cardiac data for viewing or further processing shall make use of theView Code Sequence (0054,0220), Slice Progression Direction (0054,0500) and Acquisition
Context Sequence (0040,0555) attributes to aid in the selection of input data. However, themeans by which these attributes are used to identify and/or process the data is unspecified.
Note: a means for identifying and processing cardiac input data that does not include the above
mentioned attributes will likely be useful due to the existence of Images without those attributes.
Series Description may be useful in such cases.

4710

Matching related studies or series (such as stress and rest images) is an important part of NM
processing and display. When Image Displays are trying to do this they shall look for the PatientState (0038,0500) to identify such things as stress and rest images and in the NM Acquisition
Context Module, the Image Orientation in the Detector Sequence, and the View Code Sequence_____________________________________________________________________________
205
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________(0054,0220) to identify images with desired orientations. Since images may exist without those
fields present, the Series Description may also be examined for relevant details by the software.
4715_____________________________________________________________________________
206
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4.17 Retrieve Presentation States
4720

This section corresponds to Transaction RAD-17 of the IHE Technical Framework. Transaction
RAD-17 is used by the Image Display or Imaging Document Consumer to request and retrieve
Presentation State from the Image Archive or Imaging Document Source actor.
4.17.1 Scope

4725

4730

This section describes the sequence of messages required for the Image Display or Imaging
Document Consumer to retrieve Grayscale Softcopy Presentation State Instances from the Image
Archive or Imaging Document Source. The Image Display or Imaging Document Consumer willquery and then retrieve Presentation State objects. The transformations will be applied by the
Image Display or Imaging Document Consumer to the image data to assure the image display isconsistent with the device that originally created and stored the Presentation State. The Image
Display or Imaging Document Consumer will be required to support all transformations definedin DICOM 2011 PS 3.4: Grayscale Softcopy Presentation State Storage. In addition, multiple
Presentation States may exist that reference the same image data.
4.17.2 Use Case Roles
Image
Archive

ImagingDocument
SourceImagingDocument
Consumer

Image
Display

Retrieve
Presentation
StatesActor: Image Display
4735

Role: Retrieve Grayscale Softcopy Presentation State objects together with the referenced image
data and apply the transformations specified by the Presentation State. This device will
implement the Query/Retrieve SOP Classes in the role of an SCU.
Actor: Imaging Document Consumer

4740

Role: Retrieve Grayscale Softcopy Presentation State objects together with the referenced image
data and apply the transformations specified by the Presentation State. This actor must support
pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in
DICOM 2011 PS 3.14. This device will implement the Query/Retrieve SOP Classes in the roleof an SCU.
Actor: Image Archive

4745

Role: Respond to retrieve requests from the Image Display for Grayscale Softcopy Presentation
States objects. Transmit requested Grayscale Softcopy Presentation State object(s) to the Image
Display. This device will implement the Query/Retrieve SOP Classes in the role of an SCP.
_____________________________________________________________________________
207
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Actor: Imaging Document Source

4750

Role: Respond to retrieve requests from the Imaging Document Consumer for Grayscale
Softcopy Presentation States objects. Transmit requested Grayscale Softcopy Presentation Stateobject(s) to the Imaging Document Consumer. This device will implement the Query/Retrieve
SOP Classes in the role of an SCP.
4.17.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.14: Grayscale Standard Display Function

4755

DICOM 2011 PS 3.4: Grayscale Softcopy Presentation State Storage
4.17.4 Interaction Diagram
Image
Display

Image
Archive

Select Presentation States (C-MOVE)Store Presentation States (C-STORE)

View Presentation States_____________________________________________________________________________
208
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
ImagingDocument
Consumer

ImagingDocument
SourceSelect Presentation States (C-MOVE)Store Presentation States (C-STORE)

View Presentation States

4760

4.17.4.1 Retrieve Grayscale Softcopy Presentation State

4765

This transaction refers to the “C-MOVE” and “C-STORE” messages between the Image Display
and Image Archive or Imaging Document Consumer and Imaging Document Source actor in theabove interaction diagram. The Retrieve (Study Root – MOVE and optionally Patient Root –MOVE) SOP Classes are supported. Refer to the DICOM 2011 PS 3.4 for detailed descriptive
semantics.

4770

In the case of retrieving Grayscale Softcopy Presentation State in a Cross-Enterprise, imaging
document sharing (XDS-I) network environment, a configuration of mapping the AE Titles to
DICOM AE Network Addresses (IP Address and Port number) are needed to be exchanged
between the Imaging Document Source and the Imaging Document Consumer. RAD TF-3:
Appendix G describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.17.4.1.1

Trigger EventsThe Image Display or Imaging Document Consumer selects specific Grayscale Softcopy
Presentation State objects to retrieve from the Image Archive.
4.17.4.1.2
4775

Message Semantics

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the
DICOM 2011 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the ImageManager or Imaging Document Source to assure that the patient and procedure information iscurrent in the images and Softcopy Presentation State objects when they are retrieved from theImage Archive or Imaging Document Source.

_____________________________________________________________________________
209
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4780

4.17.4.1.3

Expected Actions

The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a
DICOM association with the Image Display or Imaging Document Consumer actor, respectively,
and uses the DICOM Grayscale Softcopy Presentation State Storage SOP Class to transfer therequested Presentation State objects.
4785

4.17.4.2 View Presentation States
This transaction relates to the “View Presentation States” event in the above interaction diagram.
Presentation States cannot be viewed separately, but must be applied to an image. Refer tosection 4.16 for a description of the transaction used to retrieve images to which Presentation
States may be applied.

4790

4.17.4.2.1

Trigger EventsThe Image Display or Imaging Document Consumer receives Presentation State instances fromthe Image Archive or Imaging Document Source respectively.
4.17.4.2.2
4795

4800

4805

4810

Invocation Semantics

This is a local invocation of functions resident within the Image Display or Imaging Document
Consumer. The method used by the Image Display or Imaging Document Consumer to present
images for viewing by the user after the Presentation State transformations have been applied isoutside the scope of the IHE Technical Framework.
4.17.4.2.3
Expected Actions
The Image Display or Imaging Document Consumer applies the transferred Grayscale Softcopy
Presentation State to image data and renders it for viewing. The Image Display shall support
pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in
DICOM 2011 PS 3.14. The Image Display or Imaging Document Consumer may receive patient
data inconsistent with those received from a previously issued query or retrieve operation. For
example, in the event that a patient has been renamed, the Image Display or Imaging Document
Consumer will receive Softcopy Presentation State objects with the same Study Instance UID,
Series Instance UID and SOP Instance UIDs, but with a different patient name. The Image
Display or Imaging Document Consumer shall use the just queried information or the mostrecently received instances to ensure that the most recent patient data from the Image
Manger/Archive or Imaging Document Source is displayed. If the number of frames (0028,0008)
attribute is set to 1, then the Reference Frame Number (0008,1160) shall be ignored.

_____________________________________________________________________________
210
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

5715

4.27 Retrieve Reports
Transaction RAD-27 is used by the Report Manager, Report Repository, Imaging Document
Source, Report Reader, Imaging Document Consumer and External Report Repository Accessactors.
4.27.1 Scope

5720

In the Retrieve Reports Transaction, the requested DICOM Structured Reports are transferredfrom the Report Manager, Report Repository, Imaging Document Source, or External Report
Repository Access to the Report Reader or Imaging Document Consumer for viewing.
4.27.2 Use Case Roles

ReportRepository

ReportReaderReportManager

ImagingDocument
SourceExternal Report
Repository
AccessImagingDocument
Consumer

Retrieve
Reports

5725
Actor: Report Repository
Role: Sends requested DICOM Structured Reports to Report Reader.
Actor: Imaging Document Source
Role: Sends requested DICOM Structured Reports to the Imaging Document Consumer Actor.
5730

Actor: External Report Repository Access
Role: Sends requested DICOM Structured Reports to Report Reader. Such a system may berequired to convert reports of different formats (HL7) into DICOM Structured Reports (seeappendix C).
Actor: Report Reader

5735

Role: Retrieves DICOM Structured Reports from Report Repository or External Report
Repository Access and makes them available for viewing.
Actor: Imaging Document Consumer
Role: Retrieves DICOM Structured Reports from the Imaging Document Source Actor andmakes them available for viewing.

5740

Actor: Report Manager_____________________________________________________________________________
250
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Role: Sends requested DICOM Structured Reports to Report Reader.
4.27.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Storage SOP Class
5745

DICOM 2011 PS 3.16: Content Mapping Resource
4.27.4 Interaction Diagram
ReportReaderReportRepository

External Report
Repository
AccessRetrieve Reports (C-MOVE)Store Reports (C-STORE)

View Reports

Retrieve Reports (C-MOVE)Store Reports (C-STORE)

View Reports_____________________________________________________________________________
251
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

ReportReaderReportManager

Retrieve Reports (C-MOVE)Store Reports (C-STORE)

ImagingDocument
SourceImagingDocument
Consumer

Retrieve Reports (C-MOVE)Store Reports (C-STORE)

View Reports

5750

4.27.4.1 Retrieve Reports

5755This transaction relates to the retrieve section of the above interaction diagram. The Retrieve(Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes shall be supported.
The Report Reader and Imaging Document Consumer as an SCP shall support the DICOM Basic
Text SR Storage SOP Class and optionally the DICOM Enhanced SR Storage SOP Class. The
Report Manager, Imaging Document Source and the Report Repository as an SCU shall support
both the DICOM Basic Text SR Storage SOP Class and the DICOM Enhanced SR Storage SOPClass. The External Report Repository Access as an SCU shall support the DICOM Basic Text
SR Storage SOP Class and optionally the DICOM Enhanced SR Storage SOP Class. Refer to
DICOM PS 3.4, Annex C, for detailed descriptive semantics.

5760

4.27.4.1.1

Trigger Events

The user at the Report Reader or Imaging Document Consumer selects specific reports to view.
_____________________________________________________________________________
252
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
4.27.4.1.2

Message Semantics

The DICOM Query/Retrieve SOP Classes and the DICOM Structured Report Storage SOPClasses define the message semantics.
5765

A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model – MOVE
SOP Class or the DICOM Patient Root Query/Retrieve Information Model – MOVE SOP Class
shall be sent from the Report Reader to the Report Manager, Report Repository or External
Report Repository Access, or from the Imaging Document Consumer to the Imaging Document
Source.

5770

4.27.4.1.3

5775

The Report Manager, Report Repository, Imaging Document Source or External Report
Repository Access receives the C-MOVE request, establishes a DICOM association with theReport Reader or Imaging Document Consumer and uses the appropriate DICOM Structured
Report Storage SOP Classes (Basic Text SR Storage SOP Class and/or Enhanced SR Storage
SOP Class) to transfer the requested reports.

5780

Expected Actions

Report Repository responds to the queries with the information from the DICOM instances it
received from the Report Manager. Typically, Report Manager will apply information updates tothe instances of reports it holds and re-issue the reports to the Report Repository. To properly
update the content of instances that are no longer present on the Report Manager, the update
shall be performed by retrieval and re-submission of the report through the Report Manager. It
may also be done by grouping the Report Repository and Report Manager.
4.27.4.2 View Reports
This transaction relates to the “View Reports” event of the above interaction diagram.
4.27.4.2.1

5785

The Report Reader or Imaging Document Consumer receives reports from the Report
Repository, Imaging Document Source or External Report Repository Access.
4.27.4.2.2

5790

5795

Trigger Events

Invocation Semantics

This is a local invocation of functions at the Report Reader or Imaging Document Consumer, andthe method used by the Report Reader or Imaging Document Consumer to interpret and display
the report data in a meaningful way is outside the scope of the IHE Technical Framework. At aminimum the Report Reader or Imaging Document Consumer shall be able to correctly display
reports defined in RAD TF-1: 9.4. The Report Reader or Imaging Document Consumer shall beable to display reports based on the Simple Image Report (RAD TF-1: 9.4.1). If the Report
Reader or Imaging Document Consumer supports the Enhanced SR Information Object
Definition then it shall also support display of Simple Image and Numeric Reports (RAD TF-1:
9.4.2). Even though the IHE Technical Framework sets boundaries on the complexity of SR
objects, the Report Reader or Imaging Document Consumer must still be able to receive, store
and view any Basic Text SR object and optionally any Enhanced SR object in order to conform_____________________________________________________________________________
253
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

5800

to the DICOM Standard. An implementation may not be able to render, in a meaningful way,reports more complex than those specified in RAD TF-1: 9.4.
If a DICOM Structured Report references other DICOM composite objects, such as images, andsoftcopy presentation states, it is optional for the Report Reader or Imaging Document Consumer
to actually retrieve and display/apply these objects, but the Report Reader or Imaging Document
Consumer must convey to the user that such references exist in the report.

5805

4.27.4.2.2.1 Retrieve AE Title

5810

If the Report Reader is grouped with an Image Display and capable of retrieving objects
referenced in a DICOM Structured Report then the Report Reader shall retrieve these objects
from the device matching the appropriate Retrieve AE Title attribute (0008,0054) included in the
DICOM Structured Report. If the Retrieve AE Title attribute is not specified or configured, then
the Report Reader may use some other configurable Retrieve AE Title.

5815

In the case of retrieving reports in a Cross-Enterprise, imaging document sharing (XDS-I)
network environment, a configuration of mapping the AE Titles to DICOM AE Network
Addresses (IP Address and Port number) are needed to be exchanged between the Imaging
Document Source and the Imaging Document Consumer. RAD TF-3: Appendix G describes indetails the AE Title mapping to the DICOM AE Network Addresses.
4.27.4.2.3

Expected Actions

The Report Reader or Imaging Document Consumer presents to the user a DICOM Structured
Report.

_____________________________________________________________________________
254
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________

4.31 Retrieve Key Image Notes
6010

This section corresponds to Transaction RAD-31 of the IHE Technical Framework. TransactionRAD-31 is used by the Image Display and Image Archive actors or Imaging Document
Consumer and Imaging Document Source.
4.31.1 Scope

6015

In the Retrieve Key Image Notes Transaction, the requested DICOM Key Image Notes aretransferred from the Image Manager or Imaging Document Source to the Image Display or
Imaging Document Consumer for viewing along with the images flagged by the Key Image
Note.
4.31.2 Use Case Roles
Image Archive

ImagingDocument
SourceImage
Display

ImagingDocument
Consumer

Retrieve Key
Image Notes

Actor: Image Archive:
Role: Sends requested Key Image Notes to the Image Display Actor.
6020

Actor: Imaging Document Source
Role: Sends requested Key Image Notes to the Imaging Document Consumer Actor.
Actor: Image Display
Role: Receives requested Key Image Notes from the Image Archive Actor.
Actor: Imaging Document Consumer6025

Role: Receives requested Key Images Notes from the Imaging Document Source Actor.
4.31.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Key Object Selection Document Storage SOP Class_____________________________________________________________________________
267
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
6030

4.31.4 Interaction Diagram
Image
Display

Image Archive

Retrieve Key Image Notes (C-MOVE)Store Key Image Notes (C-STORE)

Render Key
Image Notes

ImagingDocument
SourceImagingDocument
Consumer

Retrieve Key Image Notes (C-MOVE)Store Key Image Notes (C-STORE)

Render Key
Image Notes

4.31.4.1 Retrieve Key Image Notes

6035

The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes will besupported. The Image Archive and Imaging Document Source as an SCU shall support DICOM
Image Storage SOP Classes. Refer to DICOM 2011 PS 3.4, Annex C, for detailed descriptive
semantics.
4.31.4.1.1

Trigger EventsThe Image Display or Imaging Document Consumer selects specific Key Image Note objects toretrieve from the Image Archive or Imaging Document Source.

_____________________________________________________________________________
268
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
6040

6045

4.31.4.1.2

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the
DICOM 2011 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the ImageManager to assure that the patient and procedure information is current in the images and Key
Image Note objects when they are retrieved from the Image Archive. It is the responsibility of
the Imaging Document Source to assure that the patient and procedure information is current in
the Key Image Note objects when they are retrieved from this Actor.
4.31.4.1.3

6050

Message Semantics

Expected Actions

The Image Archive or Imaging Document Source receives the C-MOVE request, establishes a
DICOM association with the Image Display or Imaging Document Consumer, and uses the
DICOM Key Image Note Storage SOP Class to transfer the requested Key Image Note objects.
4.31.4.2 Render Key Image Notes

6055

This transaction relates to the “Render Key Image Notes” event of the above interaction diagram.
Key Image Notes cannot be rendered separately, but must be applied to images. Refer to section
4.16 for a description of the transaction used to retrieve images to which Key Image Notes may
be applied.
The Image Display or Imaging Document Consumer is not required to, but may choose to,support retrieval and display of images from other studies than the one to which the Key Image
Note belongs
4.31.4.2.1

6060

The Image Display or Imaging Document Consumer receives Key Image Note instances fromthe Image Archive or Imaging Document Source.
4.31.4.2.2

6065

Trigger Events

Invocation Semantics

This is a local invocation of functions resident within the Image Display or Imaging Document
Consumer. The method used by the Image Display or Imaging Document Consumer to present
images for viewing by the user flagged by the Key Image Notes is outside the scope of the IHE
Technical Framework.
4.31.4.2.2.1 Retrieve AE Title

6070

6075

If the Image Display is capable of retrieving objects referenced in a DICOM Key Image Notethen it shall retrieve these objects from the device matching the appropriate Retrieve AE Title
attribute (0008,0054) included in the DICOM Key Image Note. If the Retrieve AE Title attributeis not specified or configured, then the Image Display shall use some other configurable Retrieve
AE Title.
In the case of retrieving DICOM Key Image Notes in a Cross-Enterprise, imaging document
sharing (XDS-I) network environment, a configuration of mapping the AE Titles to DICOM AE
Network Addresses (IP Address and Port number) are needed to be exchanged between the_____________________________________________________________________________
269
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 2: Transactions______________________________________________________________________________
Imaging Document Source and the Imaging Document Consumer. RAD TF-3: Appendix G
describes in details the AE Title mapping to the DICOM AE Network Addresses.
4.31.4.2.3

Expected Actions

6080

The Image Display or Imaging Document Consumer flags the images and renders the Key Image
Note.

6085

Note: It is recommended to use the just retrieved instance of the Key Image Note to ensure that the most recent patient data
be displayed to reflect possible patient merge and patient update in the Image Manager/Image Archive or Imaging
Document Source. This patient data may be inconsistent with patient data contained in a previously retrieved copy ofthe same Key Image Note instance.

_____________________________________________________________________________
270
Rev. 11.0 Final Text – 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

1120

Tag

Query Keys Matching

Query Keys Return

SCU

SCU

SCP

SCP

>Code Value(0008,0100)

O

O

R+*

R+

>Coding Scheme Designator(0008,0102)

O

O

R+*

R+

>Coding Scheme Version(0008,0103)

O

O

O

R+

>Code Meaning(0008,0104)

O

O

R+

R+

4.44.4.1.3

Expected Actions

The Image Archive receives the C-FIND request, performs the matching on the provided keys
and sends the list of matching records back to the Image Display via C-FIND responses.
The Image Display is expected to use the Template ID to select Evidence Documents for
retrieval that it supports.
1125

4.44.4.1.3.1 Mammography Image Profile
Image Display and Image Manager/Image Archive actors supporting the Mammography Image
Profile shall support the Mammography CAD SR SOP Class.

4.45 Retrieve Evidence Documents
1130

This section corresponds to Transaction RAD-45 of the IHE Technical Framework. Transaction
RAD-45 is used by the Image Archive, Image Display, Imaging Document Source and Imaging
Document Consumer.
4.45.1 Scope

1135

In the Retrieve Evidence Documents Transaction, the requested DICOM Evidence Documents
are transferred from the Image Archive to the Image Display or from the Imaging Document
Source to the Imaging Document Consumer.
4.45.2 Use Case Roles
Image Archive

Imaging Document
SourceImage Display

Imaging Document
Consumer

Retrieve Evidence
Documents

Actor: Image Archive:
Role: Sends requested Evidence Documents to the Image Display Actor.
1140

Actor: Imaging Document Source
Role: Sends requested Evidence Documents to the Imaging Document Consumer.
Rev. 11.0 Final Text – 2012-07-24

60

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Actor: Image Display
Role: Receives requested Evidence Documents from the Image Archive Actor.
Actor: Imaging Document Consumer
1145

Role: Receives requested Evidence Documents from the Imaging Document Source
4.45.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service Class, Storage SOP Class
4.45.4 Interaction Diagram
Image Archive

Image Display

Retrieve Evidence documents (C-MOVE)Store Evidence Documents (C-STORE)
RenderEvidence
Documents

1150

4.45.4.1 Retrieve Evidence Documents

1155

The Retrieve (Study Root – MOVE and optionally Patient Root - MOVE) SOP Classes shall besupported. The Image Archive as an SCU shall support DICOM Storage SOP Classes that may
be used as Evidence Documents. The Imaging Document Source as an SCU shall support
DICOM Storage SOP Classes that may be used as Evidence Documents it published for sharing.
Refer to DICOM 2011 PS 3.4, Annex C, for detailed descriptive semantics (see table 4.38-1).

1160

In the case of retrieving Evidence Documents in a Cross-Enterprise, imaging document sharing(XDS-I.b) network environment, a configuration of mapping the AE Titles to DICOM AE
Network Addresses (IP Address and Port number) is needed to be exchanged between the
Imaging Document Source and the Imaging Document Consumer. Appendix G describes indetails the AE Title mapping to the DICOM AE Network Addresses.
4.45.4.1.1

Trigger EventsThe Image Display or the Imaging Document Consumer selects specific Evidence Document
objects to retrieve from the Image Archive or the Imaging Document Source.
4.45.4.1.2
1165

Message Semantics

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the
DICOM 2011 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the Image
Rev. 11.0 Final Text – 2012-07-24

61

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Manager or Imaging Document Source to assure that the patient and procedure information iscurrent in the Evidence Document objects when they are retrieved from the Image Archive or
Imaging Document Source.
1170

4.45.4.1.3

Expected Actions

The Image Archive or the Imaging Document Source receives the C-MOVE request, establishes
a DICOM association with the Image Display or the Imaging Document Consumer, and uses the
DICOM C-STORE command to transfer the requested Evidence Document objects.
1175

Since the Image Display or the Imaging Document Consumer can select compatible documents
based on the Template IDs returned in the query, the Image Display or the Imaging Document
Consumer is required not to return an error to the Image Archive or the Imaging Document
Source due to the retrieved document content. The retrieved results may simply be discarded
instead.
4.45.4.2 Render Evidence Documents

1180

This transaction relates to the “Render Evidence Documents” event of the above interaction
diagram.
4.45.4.2.1

Trigger EventsThe Image Display or the Imaging Document Consumer receives Evidence Document instancesfrom the Image Archive or the Imaging Document Source.
1185

1190

4.45.4.2.2

This is a local invocation of functions resident within the Image Display or the Imaging
Document Consumer. Evidence Documents shall be displayed to the user of the Image Display
or the Imaging Document Consumer. The method used by the Image Display or the Imaging
Document Consumer to present Evidence Documents for viewing by the user is outside thescope of the IHE Technical Framework. For example, in the case when an Image Display or an
Imaging Document Source is grouped with an Evidence Creator, the Evidence Document may berendered as input for further processing by the Evidence Creator.
4.45.4.2.3

1195

1200

Invocation Semantics

Expected Actions

The Image Display or the Imaging Document Consumer renders the Evidence Documents
retrieved. If the Image Display or the Imaging Document Consumer is unable to handle parts ofthe document, it may inform the user and offer the choice of doing a “low-grade” rendering or
ignoring the data.
Evidence Documents may contain references to other types of evidence objects. The Image
Display or the Imaging Document Consumer shall always be able to render (or “low-grade”
render) referenced Evidence Documents or to invoke other rendering display functionality.

Rev. 11.0 Final Text – 2012-07-24

62

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
If the Image Display also supports the Consistent Presentation of Images Profile, it is also
required to apply any presentation states referenced in the Evidence Document for application to
the relevant images.
1205

If the Image Display also supports the Key Image Notes Profile, it is also required to render any
Key Image Notes referenced in the Evidence Document.

1210

Note: It is recommended to use the just retrieved instance of the Evidence Document to ensure that the most recent patient
data be displayed to reflect possible patient merge and patient update in the Image Manager/Image Archive. Thispatient data may be inconsistent with patient data contained in a previously retrieved copy of the same Evidence
Document instance.

4.45.4.2.3.1 Mammography Image Profile
Image Display and Image Manager/Image Archive actors supporting the Mammography Image
Profile shall support the Mammography CAD SR SOP Class.
1215

Image Display actors shall be able to apply Mammography CAD SR information to displayed
images; see RAD TF-2:4.16.4.2.2.1.1.8 Display of CAD Marks. It is not permitted to ignore datathat has a rendering intent of presentation required; there is no such thing as a “low-grade”
rendering for Mammography CAD SR.

Rev. 11.0 Final Text – 2012-07-24

63

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2340

4.54 Provide and Register Imaging Document Set - DEPRECATEDThis transaction has been deprecated and is superseded by the Provide and Register Imaging
Document Set – MTOM/XOP (RAD TF-3: 4.68) as part of the Cross-Enterprise Document
Sharing for Imaging (XDS-I.b) Profile.

4.55 WADO Retrieve
2345This section corresponds to Transaction RAD-55 of the IHE Technical Framework. TransactionRAD-55 is used by the Imaging Document Consumer and the Image Manager/ Image Archive
actors.
4.55.1 Scope

2350

The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM
SOP Instances with a web-based service through HTTP/HTTPS protocol.
4.55.2 Use Case Roles

Imaging Document
SourceImagingDocument
Consumer

WADO Retrieve

Actor: Imaging Document Consumer2355

Role: Issues an HTTP Get Request to access a DICOM instance.
Actor: Imaging Document Source
Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP
response with the appropriate content.
4.55.3 Referenced Standard

2360

DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)

Rev. 11.0 Final Text – 2012-07-24

111

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.55.4 Interaction Diagram
ImagingDocument Source

Imaging Document
Consumer

Object(s) request(GET HTTP Request)
Object(s) send
(HTTP Response to the GET Request)

4.55.4.1 WADO Retrieve
2365

The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instancefrom the Imaging Document Source. The Imaging Document Source receives the request,
generates the response with the appropriate content and sends an HTTP Response to the Imaging
Document Consumer.
4.55.4.1.1 Trigger Events

2370

The Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within
a DICOM Manifest.
4.55.4.1.2 Message Semantics
The message semantics are defined by the DICOM Web Access to DICOM Persistent Objects(WADO), PS 3.18.

2375

2380

The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a
HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document
Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM
instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance
UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the hostinformation (e.g., web server location, and script language) of the web server to perform thistransaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOPInstance to the web server host information based on its local configuration (see Appendix G).

Rev. 11.0 Final Text – 2012-07-24

112

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________In addition, the Imaging Document Consumer shall support the following fields in the HTTP
request:Table 4.55-1: WADO HTTP Request Fields
HTTP Field

REQ

AcceptR

Description
This field is used to specify MIME types
which are acceptable for the response

ValuesAt least one of the following values:
application/dicom
image/jpeg
application/text
application/html*/*
Other values may be included as well

AcceptLanguage

2385

O

This field specifies the language of theobject to be retrieved.

Any valid value according to RFC2616

The Imaging Document Source shall list all media types it supports in the Accept field of the
HTTP request, and shall use WADO HTTP parameter contentType to request the desired media
type of the object to be retrieved in the HTTP response (see Table 4.55-2).
The Imaging Document Source and the Imaging Document Consumer are required to support a
number of parameters in the WADO HTTP Request-URI, as described in the following table.

2390
Table 4.55-2: WADO HTTP Request Parameters
Parameter Name

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
ConsumerType of the HTTP request performed. It
must be “WADO”

R

R

studyUID

Unique identifier of the study

RR

seriesUID

Unique identifier of the seriesRR

objectUID

Unique identifier of the object

R

R

contentType

MIME type of the responseR+R+

requestType

Note

IHE-1
IHE-2

charsetCharset of the responseOO

anonymize

Anonymize object

OO

annotation

Annotation of the object

O

O

IHE-3

rows

Number of pixel rows

O

O

IHE-3

columns

Number of pixel columns

O

O

IHE-3

regionRegion of image

O

O

IHE-3

windowCenter

Window center of the image

O

O

IHE-3

windowWidth

Window width of the image

O

O

IHE-3

frameNumber

Frame number of the single frame in a
multi-frame image

O

O

IHE-3

imageQuality

Image quality factor

O

O

IHE-3

Rev. 11.0 Final Text – 2012-07-24

113

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________In addition, the Imaging Document Consumer shall support the following fields in the HTTP
request:Table 4.55-1: WADO HTTP Request Fields
HTTP Field

REQ

AcceptR

Description
This field is used to specify MIME types
which are acceptable for the response

ValuesAt least one of the following values:
application/dicom
image/jpeg
application/text
application/html*/*
Other values may be included as well

AcceptLanguage

2385

O

This field specifies the language of theobject to be retrieved.

Any valid value according to RFC2616

The Imaging Document Source shall list all media types it supports in the Accept field of the
HTTP request, and shall use WADO HTTP parameter contentType to request the desired media
type of the object to be retrieved in the HTTP response (see Table 4.55-2).
The Imaging Document Source and the Imaging Document Consumer are required to support a
number of parameters in the WADO HTTP Request-URI, as described in the following table.

2390
Table 4.55-2: WADO HTTP Request Parameters
Parameter Name

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
ConsumerType of the HTTP request performed. It
must be “WADO”

R

R

studyUID

Unique identifier of the study

RR

seriesUID

Unique identifier of the seriesRR

objectUID

Unique identifier of the object

R

R

contentType

MIME type of the responseR+R+

requestType

Note

IHE-1
IHE-2

charsetCharset of the responseOO

anonymize

Anonymize object

OO

annotation

Annotation of the object

O

O

IHE-3

rows

Number of pixel rows

O

O

IHE-3

columns

Number of pixel columns

O

O

IHE-3

regionRegion of image

O

O

IHE-3

windowCenter

Window center of the image

O

O

IHE-3

windowWidth

Window width of the image

O

O

IHE-3

frameNumber

Frame number of the single frame in a
multi-frame image

O

O

IHE-3

imageQuality

Image quality factor

O

O

IHE-3

Rev. 11.0 Final Text – 2012-07-24

113

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Parameter Name

2395

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
Consumer

Note

presentationUID

Unique identifier of the presentation
object

O

O

IHE-3

presentationSeriesUID

Unique identifier of the series containing
the presentation object

O

O

IHE-3

transferSyntax

Transfer syntax UID used with DICOM
image object returned in the response

O

O

IHE-3

IHE-1: The Imaging Document Consumer must use the value “application/dicom” toretrieve a DICOM SOP Instance in the DICOM Part 10 File Format. This allows the
Imaging Document Consumer to receive a SOP Instance in the native DICOM
format for full data manipulation.
The Imaging Document Consumer can also use the value “application/jpeg” toretrieve an image encoded in JPEG baseline format if it is a single frame DICOM
image object or a single frame image encoded in a multi-frame DICOM image
object.

2400

The Imaging Document Consumer can also use the values “application/text” or“application/html” to retrieve a DICOM SR object represented in the text or html
format.

2405

The Imaging Document Consumer can also use other values for this parameter as
specified in DICOM 2011 PS 3.18, if they are supported by the Imaging Document
Source.

2410

This parameter is optional in DICOM PS 3.18. Because the default format of the
DICOM persistent object returned in the HTTP Get response in the absence of avalue in this parameter varies depending on the SOP Class of the retrieved object,
this transaction requires that the parameter be supported, to improve
interoperability.
IHE-2: This parameter must be compatible to the value(s) that the Imaging Document
Consumer placed in the Accept field of the HTTP Request-URI.
IHE-3: The parameter applies only to a DICOM SOP Instance if it is an image object.
4.55.4.1.2.1 Example of WADO Request-URI

2415

2420

The following is an example of HTTP Request-URI for retrieving a persistent DICOM object
using WADO:
http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.
40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&
objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&contentType=application%2Fdicom

Rev. 11.0 Final Text – 2012-07-24

114

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
This example uses response MIME type application/dicom to request the DICOM SOP Instance
returned in the native DICOM Part 10 file format.
4.55.4.1.3 Expected Actions
2425

2430

Upon reception of the WADO HTTP Request, the Imaging Document Source shall parse therequest and if there are no errors, shall construct an HTTP Get Response with the requested
DICOM instance content and return the response as specified by the DICOM WADO standard,with HTTP response code 200 (OK).
The Imaging Document Source shall return HTTP response code 406 (Not Acceptable), if itcannot serve the requested response MIME type(s) in parameter contentType and/or Accept
Field.
The Imaging Document Source shall return HTTP response code 404 (Not Found) if it cannot
locate the requested DICOM SOP Instance or cannot recognize the UID values specified in thereceived HTTP Request-URI.

2435

The Imaging Document Source shall return HTTP response code 400 (Bad Request) if any
required HTTP field or required WADO HTTP parameters are missing in the received HTTP
Request-URI, or any other syntactic error is detected in the HTTP Request-URI (e.g., media type
in contentType parameter conflicts with media types in Accept field).
4.55.4.1.4 Audit Trail Trigger Events

2440

IHE specifies a number of events that shall be reportable by means of the IHE Audit Trail (ITI
TF-2a: 3.20). IHE Radiology Audit Trial Option further defines a subset of these events, which
are particularly applicable to the radiology transactions.
Table 4.55-3 lists all the radiology audit trial trigger events applied to transaction RAD-55. The
last column specifies whether the sender or receiver side of the transaction is required to audit
the event.

2445
Table 4.55-3: Audit Record Trigger Events
IHE Radiology Transaction
WADO Retrieve [55]Rev. 11.0 Final Text – 2012-07-24

ATNA Trigger Event(s)Audit Recording Requirements

Instance-Stored

Imaging Document Source shall audit

Study Used

Imaging Document Consumer shall audit

115

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3305

It is the responsibility of the Image Manager/Archive to assure that the patient and procedure
information is current in the Dose objects when they are retrieved from the ImageManager/Archive.
The Image Manager/Archive receives the C-MOVE request, establishes a DICOM association
with the Dose Information Reporter or Dose Information Consumer, and uses the DICOM CSTORE command to transfer the requested Dose objects.
4.65.4.1.3 Expected Actions

3310

3315

The Dose Information Reporter and Dose Information Consumer shall accept the Dose objects.
The Dose objects shall be processed according to the features, configuration, and business logicof the Dose Information Reporter or Dose Information Consumer product. Possibilities include
display, processing, analysis, printing, export, etc.
Dose Information Reporter actors shall be capable of processing both TID 10001 and TID
10011.
The Dose Information Reporter or Dose Information Consumer shall not return an error to theArchive due to not recognizing the template used or the retrieved document content. The
retrieved results may simply be discarded instead.

3320

The same Irradiation Event (as identified by its Irradiation Event UID) may be referenced in
multiple Dose objects. For example, the same dose event might appear in both an SR
summarizing a procedure and an SR summarizing the whole study.
The Dose Information Reporter and Dose Information Consumer shall recognize duplicate
Irradiation Events based on the Irradiation Event UIDs in the Dose object.

3325

The Dose Information Reporter shall be capable of presenting some form of report to the user
based on the retrieved dose information. The format, contents and analysis of such reports are
not defined by the REM profile. Such details should be worked out as part of the product design.

4.68 Provide and Register Imaging Document Set – MTOM/XOP
3330

3335

This section corresponds to Transaction RAD-68 of the IHE Technical Framework. “Provide andRegister Imaging Document Set – MTOM/XOP” is used by the Imaging Document Source toprovide a set of XDS imaging documents to the Document Repository, and to request that therepository store these documents and then register them with the Document Registry. Thistransaction is derived from the Transaction ITI-41 of the IHE IT Infrastructure Technical
Framework. It adds new document content types as well as additional semantics and constraints
on the metadata defined in Transaction ITI-41.
4.68.1 Scope
The Provide and Register Imaging Document Set – MTOM/XOP transaction passes a Repository
Submission Request from an Imaging Document Source to a Document Repository.
A Provider and Register Document Set – MTOM/XOP transaction carries:

Rev. 11.0 Final Text – 2012-07-24

149

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3340

3345

•
•
•
•
•

Metadata describing zero or more new documents (e.g., metadata describing zero
documents may be used to describe folders containing references to documents that werepreviously submitted)
Within metadata, one XDSDocumentEntry object per document
Submission Set definition along with the linkage to new documents and references toexisting documents
Zero or more XDS Folder definitions along with linkage to new or existing documents.
Zero or more documents

4.68.2 Use Case Roles
Document
Repository

ImagingDocument
SourceProvide and Register
Imaging Document
Set – MTOM/XOP

3350
Actor: Imaging Document Source
Role: Submits document(s) with associated metadata to a Document Repository.
Actor: Document Repository
Role: receives documents and associated metadata and:
3355

•
•
•

Stores the documents
Augments submitted metadata with repository information to enable later retrieval of
documents
Forwards the enhanced metadata to the Document Registry.

4.68.3 Referenced Standards
3360

For a list of the standards inherited from the underlying ITI-41 Provide and Register Document
Set-b, see ITI TF-2b: 3.41.3.
In addition, the following standards are used to define the radiology-specific content:
DICOM 2011 PS 3.3: Key Object Selection Document (KOS)DICOM 2011 PS 3.16: Content Mapping Resource

3365

DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)

Rev. 11.0 Final Text – 2012-07-24

150

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
PDF/A ISO 19005-1. Document management - Electronic document file format for long-termpreservation - Part 1: Use of PDF (PDF/A)
HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)
4.68.4 Interaction Diagram
3370
Document
Repository

Imaging Document
SourceProvide and Register Imaging
Document Set – MTOM/XOP Request

Provide and Register Imaging
Document Set – MTOM/XOP Response

4.68.4.1 Provide and Register Imaging Document Set – MTOM/XOP Request
message
3375

An Imaging Document Source Actor sends documents and associated metadata to a Document
Repository Actor. This message is an extension of the Provide and Register Document Set-b
transaction as defined in ITI TF-2b: 3.41.
4.68.4.1.1 Trigger Events
The triggers for this transaction are:

3380

•
•

The Imaging Document Source Actor is instructed to submit a set of one or more newimaging documents for sharing, orA previously submitted document or the contents of a previously submitted manifestchanges, requiring the Imaging Document Source to submit an update.

4.68.4.1.2 Message Semantics
3385

This transaction extends the message semantics of the ITI-41 Provide and Register Document
Set-b by specifying additional document content types, to allow the sharing of the following
types of documents:
1.

Sets of DICOM SOP instances

2.

Imaging diagnostic reports

Rev. 11.0 Final Text – 2012-07-24

151

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3390

To support these content types and their usage, additional requirements and constraints on the
XDS document metadata are specified.
The Provide and Register Imaging Document Set – MTOM/XOP Request message semantics are
specified in the following subsections:

3395

3400

1.

Sharing of Persistent DICOM Instances via a Manifest document

2.

Sharing of radiology diagnostic report in PDF or Text formats

3.

XDS-I.b document metadata specification

4.

Use of XDS Submission Set concept in sharing of radiology imaging information.

The wsdl definition for this Provide-and-Register transaction sent by the Imaging Document
Source is no different than the Provide-and-Register transaction sent by the XDS.b Document
Source in ITI-41. The wsdl definition for the Provide-and-Register transaction can be found on
the IHE FTP server at:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/XDS.b_DocumentRepository.wsdl
4.68.4.1.2.1 Sharing of Set of DICOM Instances

3405

3410

3415

3420

The Imaging Document Source creates a manifest that describes and collects references to
DICOM SOP instances that are intended for sharing. The manifest, a Key Object Selection(KOS) Document Instance, is the actual document provided to the Document Repository andregistered at the Document Registry.
As specified in IHE ITI XDS.b Integration Profile, the structure of the message between theDocument Source and the Document Repository is an MTOM/ XOP formatted message. In thistransaction, the source actor is the Imaging Document Source, but the above requirement still
applies. The KOS Document Instance is encoded in the message as a DICOM Part 10 File format
having a MIME type of “application/dicom”.
The Imaging Document Source shall ensure that the DICOM SOP Instances referenced fromwithin the manifest are available to be retrieved. If the Imaging Document Source makes one ormore SOP Instances unavailable that are referenced in a published manifest, then it shall submit
a new manifest as a replacement for the published manifest already in the Document Repository
and Document Registry (IHE ITI TF-3:4.1.6). The new manifest shall have the updated list of
DICOM SOP Instances with the unavailable instances removed. If the Imaging Document
Source makes all referenced DICOM SOP Instances unavailable in a published manifest, then it
shall deprecate the published manifest without any replacement (IHE ITI XDS Metadata Update
Supplement).
4.68.4.1.2.1.1

Manifest KOS Document

The references to the DICOM SOP Instances shall be included in the Current Requested
Procedure Evidence Sequence (0040,A375) attribute of the KOS Manifest Document.
3425

The Imaging Document Source shall support a number of attributes in Current Requested
Procedure Evidence Sequence (0040,A375), which are represented in the Hierarchical SOP
Instance Reference Macro, as described in the following table:

Rev. 11.0 Final Text – 2012-07-24

152

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table 4.68.4.1.2.1-1: Attributes of Hierarchical SOP Instance Reference Macro in KOS
Manifest Document
Attribute Name

Tag

Imaging Document Source

Study Instance UID(0020,000D)

R

Referenced Series Sequence(0008,1115)

R> Series Instance UID(0020,000E)

R> Retrieve AE Title(0008,0054)

R+> Retrieve Location UID(0040,E011)

R+> Storage Media File-Set ID(0088,0130)

O> Storage Media File-Set UID(0088,0140)

O> Referenced SOP Sequence(0008,1199)

R>> Referenced SOP Class UID(0008,1150)

R>> Referenced SOP Instance UID(0008,1155)

R

3430

Some of these requirements build on attributes which are Type 2 or Type 3 in DICOM (suchattributes are indicated with R+). Specifically, the Imaging Document Source shall include its
own identification in the Retrieve AE Title (0008,0054) and Retrieve Location UID (0040,E011)
attributes. These attributes will enable subsequent retrieval of the DICOM objects referenced
within the KOS manifest.

3435

4.68.4.1.2.2 Sharing of Report
Since text reports address many of the weaknesses of PDF reports and vice versa, it is requiredthat the Imaging Document Source shall support shared reports in at least one of the following
two different formats:

3440

•
•

CDA wrapped Text, or
PDF

To maximize interoperability of the chosen formats, the following restrictions shall be required:•

For PDF documents:
•

3445

•

For CDA wrapped Text Documents:•

3450

We are not requiring a particular PDF version but we recommend the use of the
PDF/A (ISO 19005-1)
Text shall be encoded with UTF-8 UNICODE format. Refer to section 4.68.4.1.2.3.5
for constraints on the CDA wrapper. To the extent possible, the specification for the
CDA wrapper for the report text has been made consistent with the CDA metadata
specified in the ITI XDS Scanned Documents (XDS-SD) Profile (see also ITI TF-3:
5.2.2 and 5.2.3).

A report (no matter what document format is chosen) can be shared with or without image
reference(s).

Rev. 11.0 Final Text – 2012-07-24

153

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3455

If a shared report includes image reference(s), it can embed selected images in its PDF format or
it can include fully resolved hyperlinks that point to the selected images; these hyperlinks can beinteractively clickable (e.g., PDF) or can be processed or copied (e.g., text).
The Imaging Document Source that provides and registers the shared report is responsible forformatting the hyperlink to reference relevant images. The referenced images within a sharedimaging report are meant to be accessed without the need for specialized (e.g., DICOM) viewing
applications.

3460

The hyperlink that references the selected image shall be formatted as a DICOM WADO URI.
Since the sharing environment is inherently cross-enterprise, the secured version of HTTP (i.e.,
HTTPs) shall be used when formatting the hyperlink.
The Imaging Document Source is required to ensure that image references are valid links.

3465

Even though significant images can be shared as non-DICOM format (embedded picture in PDF
report or hyperlinks in PDF or Text report), it is required that sharing of a large set of DICOM
images be achieved by sharing a set of DICOM SOP instances by providing and registering amanifest document. This is to avoid registration of a large number of individual documents in the
XDS Document Registry.
4.68.4.1.2.3 Metadata

3470

The Provide and Register Imaging Document Set – MTOM/XOP Request message shall include
the metadata attributes that will be forwarded by the XDS Document Repository Actor to the
XDS Registry Actor using the Register Document Set-b Transaction (ITI-42).
The Imaging Document Source supplies all necessary registry object attributes of an
XDSDocumentEntry.

3475

3480

3485

3490

4.68.4.1.2.3.1 Metadata Attributes: Author Information and Document CreationTime
In XDS, a registered document directly contains the clinical information of interest for sharing.
Therefore, its metadata for registration can be populated directly from the document content. For
example, a discharge letter is submitted to the Document Repository, so its author and creation
information is populated into the XDS Document metadata.
In XDS-I.b, the Manifest document submitted to the Document Repository usually does notdirectly constitute clinical information of interest for sharing, but rather is a set of references tosuch clinical information. Thus, the metadata of the Manifest document shall be related to thereferenced source content or its creation process, to reflect the clinical nature of the shared
information. This affects the metadata attributes including, but not limited to, authorSpecialty,
authorInstitution, authorPerson, authorRole, creationTime, and title.
If the manifest references source data from multiple authors, then one primary author, source
data creation time and document title shall be chosen. Note that this metadata shall be populated
from the part of the source data that most closely represents the main content for sharing in order
to best support a user query to the Registry for finding this data. For example, a manifest

Rev. 11.0 Final Text – 2012-07-24

154

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
referencing a current report, a current study as well as a prior report and study, will register
metadata populated from the current report (which is the clinical content of interest for sharing).

3495

In cases where the data to be shared is transformed from its original format (e.g., DICOM) toanother format (e.g., PDF) in advance of sending it to the Repository, the metadata of such newly
generated shared information shall be populated from the original source data (e.g., DICOM
data)
In summary, XDS-I.b metadata always reflects the main clinical content of a shared document,
which may be described directly in the document, or in the source data referenced within the
document, or in the source data from which the document is transformed.

3500

4.68.4.1.2.3.2 XDSDocumentEntry Metadata
Table 4.68.4.1.2.3-1 lists XDS document metadata elements that are either further constrained by
XDS-I.b, or have XDS-I.b specific instructions for how the Imaging Document Source is
expected to populate them. Unless otherwise specified, the “optionality” of the attributes listed in
the table below is the same as what is required by XDS for the source actor.

3505

For a full description of all the metadata attributes associated with an XDS document, see Table
4.1-5 in ITI TF-2b: 4.1.7.
Table 4.68.4.1.2.3-1: XDS-I.b-specific Metadata Requirements
XDSDocumentEntry

XDS-I.b-specific Requirements

AttributecreationTime

This attribute value shall be populated by the Imaging Document Source actor to record thedate and time at which the clinical content conveyed in the shared document is created.
If the published document is a DICOM object or is transformed from a DICOM information
object, this attribute value should be taken from the tags Instance Creation Date
(0008,0012) and Instance Creation Time (0008,0013) of the DICOM object.

eventCodeList

This attribute is required to be included in the metadata if known by the Imaging Document
Source. In other words, it is “promoted” from an optional (O) attribute in XDS to a“required if known” (R2) attribute in XDS-I.b.
This attribute shall be populated by the Imaging Document Source from code(s) in DCMR
Context Group CID 29 for Acquisition Modality and from code(s) in DCMR Context
Group CID 4 for Anatomic Region. See DICOM 2011 PS 3.16 for DICOM Context Groupdefinitions.
This attribute can contain multiple codes and there is not any specific ordering assumed inthese codes.

eventCodeDisplayNameList

This attribute is required to be included in the metadata if the eventCodeList attribute ispresent.
This attribute contains the Code Meaning text(s) of the code(s) for Acquisition Modality
and for Anatomic Region valued in eventCodeList, from DCMR Context Group CID 29
and from DCMR Context Group CID 4, respectively. See DICOM 2011 PS 3.16 for
DICOM Context Group definitions.
Note that the ordering of the Code Meaning texts populated in this attribute shall be sorted
in the same order of the corresponding codes in eventCodeList.

formatCode

This attribute shall be populated by the Imaging Document Source from one of thefollowing values:

Rev. 11.0 Final Text – 2012-07-24

155

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
XDSDocumentEntry

XDS-I.b-specific Requirements

Attribute“1.2.840.10008.5.1.4.1.1.88.59” (DICOM KOS SOP Class UID) as the Format Code Valueand “1.2.840.10008.2.6.1” (DICOM UID Registry UID) as the Format Coding Scheme
OID for a DICOM Manifest document.
“urn:ihe:rad:TEXT” for a TEXT report wrapped into a CDA document“urn:ihe:rad:PDF” for a PDF report document
mimeTypeThis attribute shall be populated by the Imaging Document Source from one of thefollowing values:“application/dicom” for a DICOM Manifest document“text/xml” for a TEXT report wrapped into a CDA document.
“application/pdf” for a PDF reportpracticeSettingCode

This attribute shall be populated by the Imaging Document Source by taking a fixed code
defined by the XDS Affinity Domain to designate “Radiology”

serviceStartTime

This attribute shall be populated by the Imaging Document Source for a date and time thatindicates the imaging service start time.
As an example, the Imaging Document Source could take the value of Study Date
(0008,0020) and Study Time (0008,0030) from the associated DICOM study

sourcePatientInfo

This attribute shall represent the Patient demographics information used in the Imaging
Document Source actor system to identify the patient.
This attribute allows multiple values for different pieces of patient demographics, see
metadata specification of the IHE ITI XDS Integration Profile (Table 4.1-5 in ITI TF3:4.1.7).
As an example, this information can be transformed from DICOM Patient’s Name
(0010,0010), Patient’s Birth Date (0010,0030), and Patient’s Sex (0010,0040).

typeCodeThis attribute shall be populated by the source actor from a coding system of the Requested
Procedure Code of the Requested Procedure, to which the document is associated. In certain
special cases previously defined in other IHE Profiles some sort of user intervention will benecessary to select the single Procedure Code used to populate this attribute. For example,
handling the “Group Case” as defined in Scheduled Workflow will require the user to selecta single, pre-coordinated procedure code that represents the multiple Requested Proceduresthat were acquired as a single study.
The coding system of the Radiology Imaging Requested Procedure Code will be designatedby the XDS Affinity Domain and shared by all Imaging Document Sources in the XDS
Affinity Domain.

typeCodeDisplayName

This attribute shall be filled by the source actor using the code meaning text of thecorresponding Requested Procedure Code valued in typeCode.

uniqueId

This attribute shall contain the Document unique ID generated by the source actor. It shallbe an ISO OID.
For a DICOM Manifest document, this attribute value shall be the same as the SOP Instance
UID of the corresponding DICOM KOS object. In the event that any information in the
manifest changes and it needs to be resubmitted from the Imaging Document Source to theDocument Repository, the Imaging Document Source shall generate a new SOP Instance
UID for the DICOM KOS object to ensure that its submission to the Repository will
succeed.
For a CDA wrapped text report, this value shall be formulated from the HL7 CDA R2
header as follows:
ClinicalDocument/id@root.ClinicalDocument/id@extension

Rev. 11.0 Final Text – 2012-07-24

156

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3510

3515

4.68.4.1.2.3.3 Transformation of DICOM VR to XDS Document Metadata Data
Types
A number of XDS document metadata attributes use HL7 data types for value representation.
Some of the metadata attributes may be transformed from data elements of the corresponding
DICOM SOP Instance. In this section, transformations of DICOM VR (Value Representation) to
the HL7 data types used in XDS metadata are described.
Note that term HL7 Data Type in the following transformations refers to their specified usage in
XDS document metadata as defined in IHE ITI XDS Integration Profile.
4.68.4.1.2.3.3.1

3520

CX – Extended Composite ID

Table 4.68.4.1.2.3-2 describes the transformation of data element of DICOM VR to CX data typeas specified in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-2: CX Data type mapping
CX DataComponent

Component NameDICOM VR
LO

Comment

1

ID NumberThis attribute represent the value of Patient
ID issued by an Assigning Authority as
indicated in component 3. In DICOM, it isdata element (0010,0020).

4.2

Assigning Authority –Universal ID

Assigning Authority information is not
required in DICOM instance. The Imaging
Document Source must use its local
configuration to populate thissubcomponent, to indicate the Patient ID
Domain, from which the Patient ID value
in component 1 has been issued. This must
be an ISO OID

4.3

Assigning Authority –Universal ID Type

This must be “ISO”

5

Identifier Type

Patient ID Type information is not requiredin DICOM instance. The Imaging
Document Source can use its local
configuration to populate this component,
to indicate the type of the Patient ID value
in component 1.

HL7 CX data components not listed in the table are not used in XDS document metadata andshall be left empty.
4.68.4.1.2.3.3.2
3525

DTM – Date / TimeHL7 DTM Data Type can be represented in the following regular expression:
YYYY[MM[DD[HH[MM[SS]]]]]
This can be transformed from DICOM elements of VR DA (format: YYYYMMDD) and TM(format: HHMMSS.fraction).

Rev. 11.0 Final Text – 2012-07-24

157

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.68.4.1.2.3.3.3
3530

XCN – Extended Composite ID Number and Name for Person

Table 4.68.4.1.2.3-3 describes the transformation of DICOM VR to XCN data type as specified
in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-3: XCN Data type mapping
XCN Data
Component

Component NameDICOM Data
Element

1

ID Number

2

Family Name

1st Component of PN

3

Given Name

2nd Component of
PN

4Second or Further Given
Names or Initials thereof

3rd Component ofPN

5Suffix5th Component of
PN

6Prefix4th Component ofPN

7

DegreeComment
This attribute component is not required in
DICOM. The Imaging Document Sourcemust use its local configuration or
personnel directory service to populate thiscomponent.
A data element of VR PN, like(0010,0010) for Patient Name

This attribute component is not included in
DICOM.

HL7 XCN data components not listed in the table are not used in XDS document metadata andshall be left empty.
3535

4.68.4.1.2.3.3.4
for Organization

XON – Extended Composite Name and Identification Number

Table 4.68.4.1.2.3-4 describes the transformation of DICOM VR to XON data type as specified
in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-4: XON Data type mapping
XON Data
Component
13540

Organization NameDICOM Data
Element
LO

Comment
A data element of VR LO, like (0008,0080)
for institution name

HL7 XON data components not listed in the table are not used in XDS document metadata andshall be left empty.
4.68.4.1.2.3.4
Types

3545

Component Name

XDS/XDS-I.b Metadata Values represented as HL7 v2.5 Data

XDS/ XDS-I.b Metadata that is represented as an HL7 v2.5 data type will require transformationfrom its corresponding HL7 CDA R2 header component. The following table (4.68.4.1.2.3-5)
guides this transformation and indirectly imposes requirements on the configuration of and/or
user interaction with implementations supporting this transaction. Additionally, this table further

Rev. 11.0 Final Text – 2012-07-24

158

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.68.4.1.2.3.3.3
3530

XCN – Extended Composite ID Number and Name for Person

Table 4.68.4.1.2.3-3 describes the transformation of DICOM VR to XCN data type as specified
in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-3: XCN Data type mapping
XCN Data
Component

Component NameDICOM Data
Element

1

ID Number

2

Family Name

1st Component of PN

3

Given Name

2nd Component of
PN

4Second or Further Given
Names or Initials thereof

3rd Component ofPN

5Suffix5th Component of
PN

6Prefix4th Component ofPN

7

DegreeComment
This attribute component is not required in
DICOM. The Imaging Document Sourcemust use its local configuration or
personnel directory service to populate thiscomponent.
A data element of VR PN, like(0010,0010) for Patient Name

This attribute component is not included in
DICOM.

HL7 XCN data components not listed in the table are not used in XDS document metadata andshall be left empty.
3535

4.68.4.1.2.3.3.4
for Organization

XON – Extended Composite Name and Identification Number

Table 4.68.4.1.2.3-4 describes the transformation of DICOM VR to XON data type as specified
in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-4: XON Data type mapping
XON Data
Component
13540

Organization NameDICOM Data
Element
LO

Comment
A data element of VR LO, like (0008,0080)
for institution name

HL7 XON data components not listed in the table are not used in XDS document metadata andshall be left empty.
4.68.4.1.2.3.4
Types

3545

Component Name

XDS/XDS-I.b Metadata Values represented as HL7 v2.5 Data

XDS/ XDS-I.b Metadata that is represented as an HL7 v2.5 data type will require transformationfrom its corresponding HL7 CDA R2 header component. The following table (4.68.4.1.2.3-5)
guides this transformation and indirectly imposes requirements on the configuration of and/or
user interaction with implementations supporting this transaction. Additionally, this table further

Rev. 11.0 Final Text – 2012-07-24

158

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
restricts the HL7 CDA R2 specification. IDs in metadata that correspond to IDs in the CDA
header (as II types) are required to have both a root and an extension attribute.
3550

Table 4.68.4.1.2.3-5: HL7 v2.5 and CDA Data type mapping
XDS/ XDS-I.b Metadata
HL7
v2.5
Data
Type

Subcomponent
index

HL7 CDA Header

Subcomponent
name

CX

HL7 CDAR2 Dataelement

HL7 CDA R2 Sub-element or
attribute

II(SEE
NOTE 1)

DTM

1

Id number

II@extension

4.1

AssigningAuthority.
namespaceII@assigningAuthorityName

4.2

AssigningAuthority.
uid

II

@root

1 (only)

Date/TimeTS or
IVL_TS@valueXCN(NOTE: format is compatible with DTM)

II and PN
1

Id number

II@extension

2.1

FamilyName.surnName

PN

Family3

Given Name

PN

Given

4

Second (middle)
Name

PN

Given

5

SuffixPN

Suffix6

PrefixPN

Prefix9.1

AssigningAuthority.
namespaceII@assigningAuthorityName

9.2

AssigningAuthority.
uid

II

@root

XON

II and ON
1

Organization Name

3

Id number

II@extension

5.1

AssigningAuthority.
namespaceII@assigningAuthorityName

5.2

AssigningAuthority.
uid

II

@root

Note 1: XDS restricts the formatting of the CX datatype. See ITI TF-2x: Appendix E.

Rev. 11.0 Final Text – 2012-07-24

159

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.68.4.1.2.3.5
3555

3560

3565

CDA Wrapper – Text Report [CDA] Option

This section outlines the content of the HL7 CDA R2 wrapper for the text content. We note herethat requirements specified below are to ensure the presence of a minimum amount of wrapper
data in order to enhance description and facilitate sharing of the document. It should be notedthat the "nullFlavor" value expresses missing values in the CDA, e.g., it may be appropriate if
such information cannot be derived from DICOM objects.
Implementers of the “Text Report [CDA]” Profile Option can and should make use of additionalannotation within the CDA header to provide richer context. The examples in the following
sections contain the minimal amount of wrapper data, as specified, and in many cases do makeuse of additional CDA header elements for enriched context.
To the extent possible, the specification for the CDA wrapper for the report text has been madeconsistent with the CDA metadata specified in the ITI XDS Scanned Documents (XDS-SD)
Profile (see ITI TF-3: 5.2.3) and has be replicated here for the readers’ convenience.
Elements and attributes that apply to the XDS-SD use case(s) but not to the use case of sharing
an electronically transmitted radiology report have been omitted, where allowed by the CDA R2
specification. Descriptions for how to populate certain elements and attributes consistent with the“sharing a text-based radiology report” use case have been included.

3570

4.68.4.1.2.3.5.1

Wrapper Format – HL7 CDA R2

The CDA metadata wrapper for plain text reports is the same as defined in the ITI XDS-SD
Profile (see the metadata specification table in ITI TF-3: 5.2.3) with the exceptions described
below and in the following subsections:
3575•

The ClinicalDocument/dataEnterer element, as it is defined in XDS-SD, does not apply tothe report sharing use case and thus may be omitted.

4.68.4.1.2.3.5.1.1

ClinicalDocument Child-less Elements

The requirements for the ClinicalDocument Child-less elements for CDA-wrapped plain text
reports is the same as defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.1), with thefollowing exceptions/ clarifications:
3580

•
•

The ClinicalDocument/templateId element shall be 1.3.6.1.4.1.19376.1.2.21
The ClinicalDocument/code element shall be set with the following attribute values:
•
•
•
•

3585
•

code=“11528-7”
codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC”
displayName=“Radiology Report”/>

The ClinicalDocument/effectiveTime shall denote the time at which the CDA text
document was recorded. At a minimum, the time shall be precise to the day and shall
include the time zone offset from GMT.

Rev. 11.0 Final Text – 2012-07-24

160

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Example:<ClinicalDocument xmlns=“urn:hl7-org:v3”><typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/><templateId root=”1.3.6.1.4.1.19376.1.2.21”><id root=“1.3.6.4.1.4.1.2835.2.7777”/><code code=“11528-7” codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC” displayName=“Radiology Report”/><title>Chest X-Ray</title><effectiveTime value=“20050329224411+0500”/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code=“en-US”/>

3590
4.68.4.1.2.3.5.1.2

3595

ClinicalDocument/recordTarget

The requirements and example for the ClinicalDocument/recordTarget element for CDAwrapped plain text reports is the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.2).
4.68.4.1.2.3.5.1.3

ClinicalDocument/author (original)

The requirements and example for the ClinicalDocument/author element (that represents theoriginal author of the report) for CDA-wrapped plain text reports is the same as defined in the
ITI XDS-SD Profile (see ITI TF-3: 5.2.3.3).
3600

4.68.4.1.2.3.5.1.4

ClinicalDocument/author (reporting system)

The requirements for the ClinicalDocument/author element (that represents the reporting systemand software used to produce the report content) for CDA-wrapped plain text reports is the sameas defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.4), with the following exceptions/clarifications:
3605

•
•

3610

When reading the XDS-SD specification, references to scanned, scanning, scanned
content etc. refer to reporting, report content etc. in this context.
When reading the XDS-SD specification concerning theClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code element
references to CDA-wrapped PDF can be ignored since they do not apply to the radiology
report sharing use case.

Example:Rev. 11.0 Final Text – 2012-07-24

161

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________<author><time value=“20050329224411+0500”/><assignedAuthor><templateId root=”1.3.6.1.4.1.19376.1.2.20.2”/><id root=“1.3.6.4.1.4.1.2835.2.1234”/><assignedAuthoringDevice><code code=“WSD” displayName=“Workstation” codeSystem=“
1.2.840.10008.2.16.4” /><manufacturerModelName>SOME REPORTING NAME AND MODEL</manufacturerModelName><softwareName> REPORTING SOFTWARE NAME v0.0</softwareName></assignedAuthoringDevice><representedOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME REPORTING Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country></addr></representedOrganization></assignedAuthor></author>

4.68.4.1.2.3.5.1.5
3615

The requirements and example for the ClinicalDocument/custodian element for CDA-wrappedplain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.6). Its
context is left up to the reporting facility to define in accordance with local policies and to reflect
the entity responsible for the report content. In most cases this will be the reporting facility.
4.68.4.1.2.3.5.1.6

3620

ClinicalDocument/legalAuthenticator

The requirements and example for the ClinicalDocument/legalAuthenticator element for CDAwrapped plain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.7) and its context is left up to the reporting facility to define in accordance with local
policies.
4.68.4.1.2.3.5.1.7

3625

ClinicalDocument/custodian

ClinicalDocument/documentationOf

The requirements and example for the ClinicalDocument/documentationOf element for CDAwrapped plain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.8).

Rev. 11.0 Final Text – 2012-07-24

162

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.68.4.1.2.3.5.1.8
3630This ClinicalDocument/component/nonXMLBody element shall be present and used to wrap thetext content. The requirements for the nonXMLBody are the same as defined in the ITI XDS-SD
Profile (see ITI TF-3: 5.2.3.9), with the following exceptions/ clarifications:•

3635

ClinicalDocument/component/nonXMLBody•

When reading the XDS-SD specification, references to scanned, scanning, scanned
content etc. refer to reporting, report content etc. in this context.
When reading the XDS-SD specification concerning theClinicalDocument/component/nonXMLBody element, references to CDA-wrapped PDF
can be ignored since they do not apply to the radiology report sharing use case.

Example (report text content is in the same language as the wrapper):<component><nonXMLBody><text mediaType=“text/plain” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF
0ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWu
hBQ/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZxa5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGD
mcZOBWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpG
yrHDuK7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG
9iago0</text></nonXMLBody></component></ClinicalDocument>

3640

4.68.4.1.2.4 Use of XDS Submission Set
4.68.4.1.2.4.1

Linking Report to Set of DICOM Instances

Figure 4.68.4.1.2.4-1 shows examples of three Submission Sets:
•
3645

•
•

Submission Set 1 includes a report and a Manifest that are stored in the Document
Repository. The manifest references DICOM instances that are archived in the IM/IA.
Submission Set 2 includes one single manifest.
Submission Set 3 includes a report and references the manifest from Submission Set 2
since it was generated by interpreting the images referenced by that manifest. Submission
Set 3 also references the report and the manifest from Submission Set 1 since that reportand images that are referenced by that manifest were used for the interpretation.

Rev. 11.0 Final Text – 2012-07-24

163

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________PRIOR

CURRENT
Submission
Set 2

XDS

Submission
Set 1

Submission
Set 3

Optional References

Imaging
ManifestDocument 2

Imaging
ManifestDocument 1

Radiology
Diagnostic
Report 2

DICOM

Radiology
Diagnostic
Report 1

Images and Evidence
Documents Referenced in
Manifest

3650

Figure 4.68.4.1.2.4-1: Imaging Information Sharing Submission Set

4.68.4.1.2.4.2

3655

Images and Evidence
Documents Referenced in
Manifest

Linking Report to prior report

The Report Submission Set can reference the manifest for a set of prior images published if theprior images were used in creating the interpretation. Likewise the report submission set canreference a report from a previous submission.
4.68.4.1.3

Expected Actions

The Document Repository Actor will receive this message and will process it according to therequirements specified in ITI TF-2b: 3.41.4.1.3.
3660

4.68.4.2 Provide and Register Imaging Document Set – MTOM/XOP Response
message
The Document Repository sends a Provide and Register Imaging Document Set – MTOM/XOP
Response message when the processing of a Provide and Register Imaging Document Set –MTOM/XOP Request message is complete. The specification of the trigger events, message
semantics and expected actions are the same as those specified in ITI TF-2b: 3.41.4.2.

3665

The conditions of failure and possible error messages are given in the ebRS standard. The
Imaging Document Source shall handle all error messages detailed for the Provide and Registertransaction in ITI TF-3: 4.1.13 “Error Reporting”.

Rev. 11.0 Final Text – 2012-07-24

164

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4.69 Retrieve Imaging Document Set
3670

3675

This section corresponds to Transaction RAD-69 of the IHE Technical Framework. “Retrieve
Imaging Document Set” is used by the Imaging Document Consumer to retrieve DICOM objects
from an Imaging Document Source. The objects retrieved are those that are referenced within an
XDS-I.b manifest document as described in RAD TF-3: 4.68. This transaction is derived from,and is nearly identical to, the “Retrieve Document Set” Transaction (ITI-43) of the IHE IT
Infrastructure Technical Framework. It adds minor additional semantics and constraints on therequirements defined in Transaction ITI-43.
4.69.1 Scope

3680

3685

This transaction is used by the Imaging Document Consumer to retrieve a set of DICOM objects
from the Imaging Document Source. The Imaging Document Consumer gains access to the
manifest object (KOS) previously retrieved from the Document Repository by the grouped
Document Consumer Actor via the Retrieve Document Set transaction. The Imaging Document
Consumer extracts the XDSDocumentEntry.uniqueId and a repositoryUniqueId associated with
the Imaging Document Source from the manifest (KOS) object for use in creating the retrieval
request.
4.69.2 Use Case Roles
ImagingDocument
SourceImaging Document
Consumer

Retrieve Imaging
Document Set

Actor: Imaging Document Consumer
Role: Issues a web service request to retrieve a set of DICOM instances.
Actor: Imaging Document Source
3690

Role: Receives a web service request for retrieval of a set of DICOM instances and generates the
web service response with the appropriate content.
4.69.3 Referenced Standards
For a list of the standards inherited from the underlying ITI-43 Retrieve Document Set, see ITI
TF-2b: 3.43.3.

Rev. 11.0 Final Text – 2012-07-24

165

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3695

4.69.4 Interaction Diagram
Imaging Document
Consumer

ImagingDocument Source

Retrieve Imaging Document Set
RequestRetrieve Imaging Document Set
Response

4.69.4.1 Retrieve Imaging Document Set Request message

3700

An Imaging Document Consumer sends a request to an Imaging Document Source to retrieve theset of images referenced within a manifest object. This message is an extension of the Retrieve
Document Set transaction as defined in ITI TF-2b: 3.43.
4.69.4.1.1 Trigger Events

3705

3710

The Imaging Document Consumer wishes to retrieve a set of DICOM instances that arereferenced within a DICOM Manifest that was previously retrieved by the grouped Document
Consumer Actor. The Imaging Document Consumer obtains the documents’ uniqueIds (i.e., the
SOP Instance UIDs referenced within the DICOM manifest) along with the associated study andseries instance UIDs. The Imaging Document Consumer will either compute therepositoryUniqueId(s) from the Retrieve AE Title attribute(s) within the DICOM manifest or
populate the repositoryUniqueId(s) using the Retrieve Location UID attribute(s) within the
DICOM manifest. The Imaging Document Consumer also maps the repositoryUniqueId(s) to
web services endpoint(s) which are the targets of the message.
Once the documents’ uniqueIds and repositoryUniqueId(s) have been obtained, the Imaging
Document Consumer will send the Retrieve Imaging Document Set Request to the Imaging
Document Source.
4.69.4.1.2 Message Semantics

3715

The Retrieve Imaging Document Set Request shall carry the following information:•

3720

A required repositoryUniqueId that identifies the Imaging Document Source from which
the DICOM instance is to be retrieved. This value shall either be “computed” based on
the Retrieve AE Title (0008, 0054) attribute(s) present in the DICOM manifest or be
populated from the Retrieve Location UID (0040,E011) attribute(s) that is present in the
DICOM manifest. For a description of how this “computation” can be achieved, see IHE
RAD TF-3: Appendix G.3.

Rev. 11.0 Final Text – 2012-07-24

166

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
•
3725

•
•

3730

•

A required list of one or more documentUniqueIds that identify the documents within the
Imaging Document Source. These values correspond to the SOP Instance UIDs
referenced within the DICOM manifest.
A required list of one or more DICOM transfer syntax UIDs that the Imaging Document
Consumer is capable of processing.
A required Study Instance UID value that identifies the study containing the DICOM
images/ objects to be retrieved. The Study Instance UID is extracted from the KOS
manifest.
A required Series Instance UID value that identifies the series containing the DICOM
images/ objects to be retrieved. The Series Instance UID is extracted from the KOS
manifest.

The message shall be structured as described in section 4.69.5 Protocol Requirements.
4.69.4.1.3 Expected Actions
3735

When receiving a Retrieve Imaging Document Set Request, an Imaging Document Source shallgenerate a Retrieve Document Set Response.
4.69.4.2 Retrieve Imaging Document Set Response message
4.69.4.2.1 Trigger Events
This message will be triggered by receipt of a Retrieve Imaging Document Set Request Message.

3740

4.69.4.2.2 Message Semantics
The semantics of the Retrieve Imaging Document Set Response Message are identical to thoseinherited from the ITI-43 transaction and are specified in ITI TF-2b: 3.43.4.2.2.
4.69.4.2.3 Expected Actions

3745

3750

An Imaging Document Source shall provide the document(s) indicated in the request. The
Imaging Document Source shall return the document(s) or an error code in case the document
could not be returned. The pixel data shall be encoded using one of the DICOM transfer syntaxes
included in the Retrieve Imaging Document Set Request Message. If the Imaging Document
Source cannot encode the pixel data using any of the provided transfer syntaxes then an error
status shall be returned.
If the Imaging Document Consumer specifies a transfer syntax field of 1.2.840.10008.1.2.4.94(DICOM JPIP Referenced Transfer Syntax) or 1.2.840.10008.1.2.4.95 (DICOM JPIP Referenced
Deflate Transfer Syntax), the following behavior is expected:
•

3755

•

If the DICOM Image Object(s) have a transfer syntax(es) that match the requested
transfer syntax, the Retrieve Imaging Document Set Response shall include the DICOM
Image Objects unchanged.
If the DICOM Image Object(s) have a transfer syntax that differs from that of the request,
the Retrieve Imaging Document Set Response shall include the DICOM image with theRev. 11.0 Final Text – 2012-07-24

167

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3760
•
3765

•

transfer syntax changed to the requested transfer syntax. In addition, the pixel data
Attribute (7Fe0,0010 tag) will have been removed and replaced with a Pixel Data
Provider URL (0028,7FE0 tag). The URL represents the JPIP request and will include thespecific target information.
Upon receipt of this Retrieve Imaging Document Set Response, the Imaging Document
Consumer may request the pixel data from the pixel data provider using the supplied
URL. Additional parameters required by the application may be appended to the URL
when accessing the pixel data provider.
For example, a JPIP request for a 200 by 200 pixel rendition of the entire image can beconstructed from the Pixel Data Provider URL as follows:
•

3770

•

Pixel Data Provider URL (0028,7FE0) =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2,
URL Generated by the application =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200

The conditions of failure and possible error messages are given in the ebRS standard and detailedin ITI TF-3: 4.1.13 “Error Reporting”.
4.69.5 Protocol Requirements
3775

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

3780

•
•

Accept the Retrieve Document Set Request message in MTOM/XOP format.
Generate the Retrieve Document Set Response message in MTOM/XOP format

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

3785
WSDL Namespace Definitions
iheradurn:ihe:rad:xdsi-b:2009

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

These are the requirements for the Retrieve Imaging Document Set transaction presented in theorder in which they would appear in the WSDL definition:•

The following types shall be imported (xsd:import) in the /definitions/types section:Rev. 11.0 Final Text – 2012-07-24

168

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3790

•
•

3795

•
•
•

3800

3805

•
•

namespace="urn:ihe:rad:xdsi-b:2009", schema="
XDSI.b_ImagingDocumentSource.xsd"
The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema=”
XDS.b_DocumentRepository.xsd”)

The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
Request message shall be defined as “iherad:RetrieveImagingDocumentSetRequest”
The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
Response message shall be defined as “ihe:RetrieveDocumentSetResponse”
The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve
Imaging Document Set Request message shall be defined as“urn:ihe:rad:2009:RetrieveImagingDocumentSet”
The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve
Imaging Document Set Response message shall be defined as“urn:ihe:iti:2007:RetrieveDocumentSetResponse”
The /definitions/binding/operation/soap12:operation/@soapAction attribute shall bedefined as “urn:ihe:rad:2009:RetrieveImagingDocumentSet”

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 4.69.5.1 Sample SOAP Messages.
3810

For informative WSDL for the Imaging Document Source actor see example on the IHE FTP
server at: ftp://ftp.ihe.net/TF_Implementation_Material/RAD.
The <iherad:RetrieveImagingDocumentSetRequest/> element for use with the Retrieve Imaging
Document Set Request Message is defined as:•

3815

One or more <iherad:StudyRequest/> elements each of which includes a“studyInstanceUID” attribute identifying the study associated with the DICOM images/
objects being retrieved. Each <iherad:StudyRequest/> element shall contain:•

3820

One or more <iherad:SeriesRequest/> elements each of which includes a“seriesInstanceUID” attribute identifying the series associated with the DICOM
images/ objects being retrieved. Each <iherad:SeriesRequest/> element shall contain:
•
•

3825

•
•

One or more <ihe:DocumentRequest/> elements, each one representing an
individual document that the Imaging Document Consumer wants to retrieve fromthe Imaging Document Source. Each <ihe:DocumentRequest/> element contains:
A required <ihe:RepositoryUniqueId/> element that identifies the Imaging
Document Source from which the document is to be retrieved. This value
corresponds to XDSDocumentEntry.repositoryUniqueId.
A required <ihe:DocumentUniqueId/> element that identifies the document
within the Imaging Document Source. This value corresponds to the SOP Instance
UID referenced within the DICOM manifest.
An optional <ihe:HomeCommunityId/> element that corresponds to the homeattribute of the Identifiable class in ebRIM.

Rev. 11.0 Final Text – 2012-07-24

169

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3830

3835

•

A required <iherad:TransferSyntaxUIDList/> element which contains a list of one ormore <ihe:TransferSyntaxUID> elements. Each of the <iherad:TransferSyntaxUID>
elements represent one of the transfer syntax encodings that the Imaging Document
Consumer is capable of processing.

This allows the Imaging Document Consumer to specify one or more documents to retrieve fromthe Document Repository.
The <ihe:RetrieveDocumentResponse/> element for use with the Retrieve Imaging Document
Set Response Message is defined as::
•
•

3840

3845

A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
An optional sequence of <ihe:DocumentResponse/> elements containing
•

•

3850
•
3855

3860

•
•

3865

A <ihe:HomeCommunityId/> element. The value of this element shall be the same as
the value of the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/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 be present.
A required <ihe:RepositoryUniqueId/> that identifies the Imaging Document Sourcefrom which the document is to be retrieved. The value of this element shall be thesame as the value of the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/RepositoryUniqueId element in the original Retrieve Imaging Document Set
Request Message. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
A required <ihe:DocumentUniqueId/> that identifies the document within the
Imaging Document Source. The value of this element shall be the same as the valueof the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/DocumentUniqueId element in the original Retrieve Imaging Document Set
Request Message. This value corresponds to the SOP Instance UID referenced within
the DICOM manifest.
A required <ihe:Document/> element that contains the retrieved document inbase64binary encoded format
A required <ihe:mimeType/> element that indicates the MIME type of the retrieved
document

The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall
status of the request: It shall contain one of the following values:
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

See ITI TF-3: 4.1.13 Error Reporting for the interpretation of these values.

Rev. 11.0 Final Text – 2012-07-24

170

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3870

For each document requested in a
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:
•

3875

3880

•
•
•
•
•
•

3885

3890

3895

If a warning is reported when retrieving the document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:The document shall be returned in an instance of/RetrieveDocumentSetResponse/DocumentResponse/Document as base64binary encoded
data. The returned document and warning are correlated via the DocumentUniqueId.
If an error is reported when retrieving a document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:
•
•
•
•

•
•

@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning@errorCode is specified@codeContext contains the warning message@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
returnedIf 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 base64binary encoded data.

The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not
used in this transaction.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in thistransaction.
3900

A full XML Schema Document for the XDS.b and XDS-I.b types is available online on the IHE
FTP site at: ftp://ftp.ihe.net/TF_Implementation_Material/RAD (for XDS-I.b) and
ftp://ftp.ihe.net/TF_Implementation_Material/ITI (for XDS.b).
4.69.5.1 Sample SOAP Messages

3905

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
IHE ITI TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP

Rev. 11.0 Final Text – 2012-07-24

171

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
message is omitted for brevity; in a real scenario the empty element will be populated with theappropriate metadata.
3910

Samples presented in this section are also available online on the IHE FTP site, see
ftp://ftp.ihe.net/TF_Implementation_Material/RAD.
4.69.5.1.1

3915
3920
3925
3930
3935
3940
3945

<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:rad:2009:RetrieveImagingDocumentSet </a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</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:2647/XdsService/IHEXDSIDocSource.svc</a:To></s:Header><s:Body><RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"><SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest></StudyRequest><TransferSyntaxUIDList><TransferSyntaxUID> 1.2.840.10008.1.2.1</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.57</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList></RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.69.5.1.2
3950
3955
3960
3965

Sample Retrieve Imaging Document Set SOAP Request

Sample Retrieve Document Set SOAP Response<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"
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:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse>

Rev. 11.0 Final Text – 2012-07-24

172

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3970
3975

<DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>

3980

Rev. 11.0 Final Text – 2012-07-24

173

Copyright © 2012: IHE International, Inc.

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

3.20 Record Audit Event
3605

This section corresponds to Transaction 20 of the IHE IT Infrastructure Technical Framework.
Transaction 20 is used by the all IHE actors that support the Audit Trail and Node Authentication
Integration Profile to communicate with the Audit Record Repository actors.
3.20.1 Scope
In the Record Audit Event transaction, the IHE actor creates an entry in the Audit Log at the
Audit Record Repository.

3610

3.20.2 Use Case Roles
Any
Application
or
Actor

Audit Record
Repository

RecordAudit Event

Application or Actor: Any actor or any other application that is grouped with the Secure Node
Actor.
Role: Create an audit record and transmit this record to the Audit Record Repository.
3615

Actor: Audit Record Repository
Role: Receive an audit record from the Audit Record Creator and store this for audit purposes.
3.20.3 Referenced Standards
IETF:

The Syslog Protocol. (RFC 5424);
Transmission of Syslog Messages over TLS (RFC 5425)

3620

Transmission of Syslog Messages over UDP (RFC 5426)
Security Audit and Access Accountability Message XML Data Definitionsfor Healthcare Applications (RFC 3881).

3625

DICOM:

Supplement 95

ASTM:

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

NIST:

SP 800-92 Guide to Computer Security Log Management.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

138

Copyright © 2011 IHE International,

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

Recommendation: Extensible Markup Language (XML) 1.0

3.20.4 Interaction Diagram
Audit Record
Repository

Any IHE
Actor or any PHI
application
Record Audit
Event

3630

3.20.5 Record Audit Event
The Audit Record Repository shall accept the Audit Record message. The usage of the result by
the Audit Record Repository is beyond the scope of the IHE Technical Framework.
3.20.6 Trigger Events and Message semantics

3635

3640

An Audit Log is a record of actions performed on data by users. Actions are queries, views,
additions, deletions and changes. The IHE actor creates an Audit Record when an IHE
transaction-related event occurs or when a non-transaction event occurs.
IHE specifies that events defined in Table 3.20.6-1 shall be reportable by means of the IHE
Audit Trail. Radiology devices may also find that their subset of events is reportable by meansof the IHE Provisional Audit Message Format. This is not recommended other than as a strategy
for managing the upgrade of products and systems to the DICOM Audit Message Standard withIHE Extensions.
Table 3.20.6-1. Audit Record trigger events
Trigger Event

Description

Source Vocabulary

Actor-start-stop

Startup and shutdown of any actor. Applies to all actors. Is
distinct from hardware powerup and shutdown.

DICOM (Sup 95)“Application Activity”

Audit-Log-Used

The audit trail repository has been accessed or modified bysomething other than the arrival of audit trail messages.

DICOM (Sup 95) “Audit
Log Used”

Begin-storing-instances

Begin storing SOP Instances for a study. This may be a mix
of instances.

DICOM (Sup 95) “Begin
Transferring DICOM
Instances”

Health-service-event

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

IHE Extension (ITI TF-2a:3.20.7.3) “Health Services___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

139

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Trigger Event

Description

Source Vocabulary

and cancellation. See note below.

Provision Event”

Instances-deleted

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

DICOM (Sup 95) “DICOM
Instances Accessed” or“DICOM Study Deleted”

Instances-Stored

Instances for a particular study have been stored on thissystem. One event covers all instances stored for theparticular study.

DICOM (Sup 95) “DICOM
Instances Transferred”

Medication

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

IHE Extension (ITI TF-2a:3.20.7.3) “Medication
Event”

See note below.
Mobile-machine-event

Mobile machine joins or leaves secure domain.

DICOM (Sup 95)“Network Entry”

Node-Authentication-failure

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

DICOM (Sup 95) “Security
Alert”

Order-record-event

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

DICOM (Sup 95) “Order
Record”

Patient-care-assignment

Staffing or participant assignment actions relevant to theassignment of healthcare professionals, caregivers attending
physician, residents, medical students, consultants, etc. to apatient It also includes change in assigned role orauthorization, e.g., relative to healthcare status change, andde-assignment

IHE Extension (ITI TF-2a:3.20.7.3) “Patient Care
Resource Assignment”

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

IHE Extension (ITI TF-2a:3.20.7.3) “Patient Care
Episode”

Patient-care-protocol

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

IHE Extension (ITI TF-2a:3.20.7.3) “Patient Care
Protocol”

Patient-record-event

Patient record created, modified, or accessed.

DICOM (Sup 95) “Patient
Record”

PHI-export

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

DICOM (Sup 95) “Export”

PHI-import

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

DICOM (Sup 95) “Import”

Procedure-record-event

Procedure record created, modified, accessed or deleted.

DICOM (Sup 95)“Procedure Record”

Query Information

A query has been received, either as part of an IHE
transaction, or as part other products functions. For
example:DICOM (Sup 95) “Query”

1) Modality Worklist Query
2) Instance or Image Availability Query
3) PIX, PDQ, or XDS Query
Notes: The general guidance is to log the query event with___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

140

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Trigger Event

Description

Source Vocabulary

the query parameters and not the result of the query. The
result of a query may be very large and is likely to be oflimited value vs. the overhead. The query parameters can beused effectively to detect bad behavior and the expectation isthat given the query parameters the result could be
regenerated if necessary.
Security Alert

Security Administrative actions create, modify, delete,query, and display the following:1.

Configuration and other changes, e.g., software updates
that affect any software that processes protected
information. Hardware changes may also be reported
in this event.

2.

Security attributes and auditable events for theapplication functions used for patient management,
clinical processes, registry of business objects andmethods (e.g., WSDL, UDDI), program creation andmaintenance, etc.

3.

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

4.

Security categories or groupings for functions and datasuch as patient management, nursing, clinical, etc.

5.

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

6.

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

7.

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

8.

Unauthorized user attempt to use security
administration functions.

9.

Audit enabling and disabling.

DICOM (Sup 95) “Security
Alert”

10. User authentication revocation.
11. Emergency Mode Access (aka Break-Glass)
Security administration events should always be audited.
User Authentication

This message describes the event of a user attempting to log
on or log off, whether successful or not. No Participant
Objects are needed for this message.

DICOM (Sup 95) “User
Authentication”

Study-Object-Event

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

DICOM (Sup 95) “DICOM
Instances Accessed”

Study-used

SOP Instances from a specific study are created, modified or

DICOM (Sup 95) “DICOM___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

141

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Trigger Event

Description

Source Vocabularyaccessed. One event covers all instances used for theparticular study.

3645

Note:

Instances Accessed”

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

3.20.6.1 Audit Record Transportation
3650

3655

3660

This profile defines two transport mechanisms for the audit messages:
1.

Transmission of Syslog Messages over TLS (RFC5425) with The Syslog Protocol(RFC5424) which formalizes sending syslog messages over a streaming protocol
protectable by TLS

2.

Transport utilizing the Transmission of Syslog Messages over UDP (RFC5426) withThe Syslog Protocol (RFC5424) which formalizes and obsoletes BSD Syslog protocol
defined in RFC-3164.

The Audit Record Repository shall support both transport mechanisms for the receipt of
messages. Given that Audit Record Repository must accept both transports, the Secure Node
Actors may choose to utilize either of the transport mechanisms, unless they also comply withanother Profile that further restricts the use.
3.20.6.2 Audit Record format
The IHE defines several audit record formats, and future profiles may define more message
formats. An IHE actor shall utilize one or more of these audit record formats. All audit record
formats utilize XML encoding and are defined by XML schema.

3665

3670

The present list of audit record schema are:1.

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

2.

IHE Provisional Audit Record format, defined below. This was previously defined aspart of the IHE Radiology technical framework. Its use is deprecated, this implies thatno extensions will be made and new applications should use the new IHE Audit Trailformat.

3.20.6.3
3675

Audit Message Transports

The Secure Node or Secure Application actor will create the Audit Record and transmit this to
the Audit Record Repository as soon as possible. When for some reason the Audit Record
Repository is not available, the Secure Node or Secure Application actor shall store the Audit
Record in a local buffer until the Audit Record Repository is available again. The local Audit___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

142

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Record at the Secure Node or Secure Application actor may be deleted when this record has beentransmitted to the Audit Record Repository.
3680

3685

The syslog message shall be created and transmitted as described in RFC 5424 and the following
subsections. ATNA actors shall take into account the following points:• The XML audit message may contain Unicode characters that are encoded using the UTF-8
encoding rules. UTF-8 avoids utilizing the control characters that are mandated by thesyslog protocol, but it may appear to be gibberish to a system that is not prepared for UTF-8.
Audit repositories must accept UTF-8 encodings and store them without damage, e.g.,preserve all 8 bits.
•

The PRI field shall be set using the facility value of 10 (security/authorization messages).
Most messages should have the severity value of 5 (normal but significant), althoughapplications may choose values of 4 (Warning condition) if that is appropriate to the moredetailed information in the audit message. This means that for most audit messages the PRI
field will contain the value “<85>”. Audit repositories shall be prepared to deal
appropriately with any incoming PRI value.

•

The MSGID field in the HEADER of the SYSLOG-MSG shall be set to “IHE+RFC-3881”(minus the quotes).

•

STRUCTURED-DATA is not used for IHE ATNA audit messages, since the MSG field
itself holds structured data.

•

The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure
following the RFC 3881 format, as specified in this profile.

3690

3695

3.20.6.3.1
3700

The Reliable Syslog “cooked” mode is no longer specified by this profile. Applications using
Reliable Syslog should switch to transmission of syslog messages over TLS.
3.20.6.3.2

3705

3710

3715

Reliable Syslog

Transmission of Syslog Messages over UDP (formerly:BSD Syslog)

Transmission of Syslog Messages over UDP (RFC5426) with The Syslog Protocol (RFC5424)
formalizes and obsoletes the BSD syslog protocol (RFC3164). This syslog is appropriate in somesituations, it was defined in the IHE Rad Technical Framework, and it is a widely used legacy
protocol.
• Note that the underlying UDP transport might not accept messages longer than 1024 or the
MTU size minus the UDP header length. Long syslog messages may be truncated. The
Audit Repository must be prepared for arbitrary truncation of messages. The IHE
Provisional schema uses shortened names to reduce the size of messages, but some may
exceed the largest size supported by the underlying transport. When syslog messages aretruncated the resulting XML will be incorrect and will need to be corrected by the Audit
Repository to close the truncated portions of the message.
• Because of this potential for truncated messages and other security concerns, thetransmission of syslog messages over TLS may be preferred.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

143

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
3.20.6.3.3

3720

Transmission of Syslog Messages over TLS

Transmission of Syslog Messages over TLS (RFC5425) with The Syslog Protocol (RFC5424)
formalizes sending syslog messages over a streaming protocol protectable by TLS. The
RFC5424 states that this MUST be TLS version 1.2. For this transport that requirement isrelaxed to be that it MUST be TLS, version 1.2 is RECOMMENDED.
3.20.7 Audit Message Formats

3725

3.20.7.1 RFC-3881 format
A common XML schema was defined based upon joint work by IHE, HL7, DICOM, ASTM
E31, and the Joint NEMA/COCIR/JIRA Security and Privacy Committee. The IHE IT
Infrastructure technical framework prefers use of this schema for audit records generated by all
IHE actors. The schema can be found at:
http://www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd

3730

3735

The DICOM Standard, Supplement 95 Audit Trail Messages provides vocabulary and further
specification of the use of these schema elements for events that may occur in the context of
DICOM equipment. IHE has evaluated this and determined that it is more broadly applicable,
and extended it for more general healthcare use.
For reference, the schema elements are diagrammed below. The diagrams are read from left toright: elements to the right are part of the lefthandside element.
Required single element. A NetworkEntry element
consists of exactly one MachineAction element.
Optional single element. A NetworkEntry element
consists of zero or one MachineAction element.

3740

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

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

3745

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

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

144

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
element AuditMessage
diagram3750

element AuditMessage/EventIdentification
diagramelement AuditMessage/ActiveParticipant
diagramelement AuditMessage/AuditSourceIdentification
diagram

3755

3760

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

145

Copyright © 2011 IHE International,

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

element AuditMessage/ParticipantObjectIdentification
diagram

3765

Note:

ParticipantObjectDetail should not include unnecessary detail such as duplication of the attributes otherwise
encoded in the audit message.

3.20.7.2 DICOM Audit Trail
3770

A Secure Node actor shall be able to detect events that are defined by the DICOM standard in
Supplement 95, and generate Record Audit Event transactions that conform to the DICOM
standard when these events take place.
The DICOM Standard provides a schema for the basic messages and states that extensions arevalid. This profile does not restrict private extensions that comply with the W3C XML encoding
rules for the use of schemas, namespaces, etc.

3775

3.20.7.3 IHE Audit Trail
The DICOM standard and RFC-3881 do not address all the kinds of security and privacy events
that can take place in the healthcare environment. The additional IHE defined events
enumerated in ITI TF-2a: 3.20.7.5 shall be used for their defined purpose.

3780

The notation used in these tables is that used in the DICOM standard. The messages shall be
encoded as instances based on the RFC-3881 schema. In cases where there is an event thatapplies to more than one patient, there shall be a separate audit message for each patient.
3.20.7.4 Other event reports

3785

Events that do not correspond to DICOM events or IHE Extension events can be reported. They
shall comply with RFC-3881. Neither ATNA profile, DICOM, nor RFC-3881 restrict private
extensions to the RFC-3881 schema however any private extensions shall comply with the W3C
XML encoding rules for the use of schemas, namespaces, etc.
3.20.7.5 Controlled Terminology for IHE Extensions
This profile defines the following controlled terminology for use in the IHE extensions.
___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

146

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a): Transactions Part A______________________________________________________________________________
Context ID ccc1
Audit Event ID
Type: Extensible
Version: 2004xxxx

3790
CodingSchemeDesignator

CodingSchemeVersionCode Value

Code Meaning

IHE

IHE0001

Health Services Provision Event

IHE

IHE0002

Medication Event

IHE

IHE0003

Patient Care ResourceAssignment

IHE

IHE0004

Patient Care EpisodeIHE

IHE0005

Patient Care Protocol

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

3795

Code
Value

Code Meaning

Definition

Notes

IHE0001

Health Services Provision
Event

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

IHE0002

Medication Event

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

IHE0003

Patient Care Resource
Assignment

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

IHE0004

Patient Care EpisodeSpecific patient care episodes or problems
that occur within an instance of care. This
includes initial assignment, updates oramendments, resolution, completion, andcancellation.

IHE0005

Patient Care Protocol

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

3.20.7.6 IHE Provisional Audit Message Form
A provisional XML Schema was defined for the contents of the audit records generated by the
IHE actors in the deprecated Basic Security Integration Profile as part of the IHE Radiology
domain. The ATNA profile includes this schema as an alternative format for audit messages. It___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

147

Copyright © 2011 IHE International,

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

3800

3805

3810

is less flexible than the IHE Audit Trail format, and is no longer the recommended format for
IHE use. The preferred format is the IHE Audit Trail format with extensions that is describedabove.
However, the IHE Provisional Audit Message format is suitable for many diagnostic equipment
settings and can be transformed into an equivalent IHE Audit Trail format. It is also installed
and in use at many locations. So the IHE Provisional Audit Message format is part of the IHE IT
profile. The transition from its format to the IHE Audit Trail format is encouraged to reduce theburden on Audit Repositories which may result from processing this alternative format.
A provisional XML Schema has been defined for the contents of the audit records generated by
the IHE actors in the Basic Security Integration Profile from the radiology technical framework.
The audit records are used to generate an audit record log for activities related to protected healthinformation.
The IHE Provisional Audit Message Schema is described in ITI TF-2x: Appendix F.
3.20.7.7 RoleIDCode with access control roles

3815

RoleIDCode is a CodedValueType. When describing a human users participation in an event,
this value should represent the access control roles/permissions that authorized the event/trans.
Use of standards based roles/permissions is preferable to site or application specific. As RFC3881 indicates Many security systems are unable to produce this data, hence it is optional.
For example: at a site "St Fraser" they have defined a functional role code "NURSEA" forattending nurse. This can be represented as

3820

EV("NURSEA", "St Fraser", "Attending Nurse")
Candidate standards based structural/functional role codes can be found at ISO, HL7, ASTM,
and various other sources.

___________________________________________________________________________
Rev. 8.0 Final Text 2011-08-19
Inc.

148

Copyright © 2011 IHE International,

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix K:

XDS Security Environment

This Appendix expands on the summary provided in the XDS specification (ITI TF-1: 10.8).
1235

1240

1245

The XDS operations assume that a suitable security and privacy environment has been
established. Almost all of the relevant threats will be managed by agreements, policies, andtechnologies that are external to the XDS transactions. The few that affect the XDS transactions
will be managed by generic security mechanisms that are not unique to XDS. The threats andsecurity objectives that must be addressed are described in Sections K1 and K2 below. Only a
few of these have issues that are unique to the XDS application.
Section K3 discusses these few threats and objectives in terms of the agreements and policies
that need to be established to create a suitable environment for XDS. Establishing these
agreements often involves business agreement discussions that are part of establishing the XDS
Affinity Domain. These agreements are necessary because the exchange of documents implies
agreeing to the delegation of responsibility for maintaining the security of these documents andfor providing the necessary audit and record keeping facilities.

K.1:

Security Environment

K.1.1: Threats
1250

Specific threats to the overall XDS system are listed below. These threats are identified using
the Common Criteria nomenclature defined by ISO 17799. Most of these are mitigated bypolicies, procedures, and technologies that are not unique to XDS and do not require any special
XDS considerations. Many of these mitigations do require that the parties within the XDS
Affinity Domain have agreement on details of how they will work together.
T.ADMIN_ERROR Improper administration may result in defeat of specific security features.

1255

T.ADMIN_ROGUE Authorized administrator’s intentions may become malicious resulting in
TSF data to be compromised.
T.AUDIT_CORRUPTA malicious process or user may cause audit records to be lost or
modified, or prevent future records from being recorded by taking actions to exhaust audit
storage capacity, thus masking an attacker’s actions.

1260

T.CONFIG_CORRUPTA malicious process or user may cause configuration data or othertrusted data to be lost or modified.
T.DISASTER System or network may failure due to disaster (e.g., fire, earthquake).
T.DOS
A malicious process or user may block others from system resources via a
resource exhaustion denial of service attack.

1265

T.EAVESDROP
A malicious process or user may intercept transmitted data inside oroutside of the enclave. Some of the XDS environments are not concerned with eavesdrop__________________________________________________________________________
45
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
exposure. They may employ external protective mechanisms such as physical network security
or VPNs to protect against eavesdropping.
T.HARDWARE
1270

Hardware may malfunction.

T.IMPROPER_INSTALLATION XDS components may be delivered, installed, orconfigured in a manner that undermines security.
T.INSECURE_START
T.INTRUSION

1275

Reboot may result in insecure state of the operating system.

Malicious software (e.g., virus) may be introduced into the system.

T.MASQUERADE A malicious process or user on one machine on the network may
masquerade as an entity on another machine on the same network.
T.OBJECTS_NOT_CLEAN
Systems may not adequately remove the data from objects
between usage by different users, thereby releasing information to a user unauthorized for thedata. This also includes swapping hard disk with PHI during service and repair.

1280

T.POOR_DESIGN Unintentional or intentional errors in requirement specification, design ordevelopment of the TOE components may occur.
T.POOR_IMPLEMENTATION Unintentional or intentional errors in implementing thedesign of the XDS environment may occur.
T.POOR_TEST
Incorrect system behavior may result from inability to demonstrate that allfunctions and interactions within the XDS operation are correct.

1285

T.REPLAY A malicious process or user may gain access by replaying authentication (orother) information.
T.SPOOFING
A hostile entity may masquerade itself as part of the XDS Affinity
Domain and communicate with authorized users who incorrectly believe they are communicatingwith authorized members.

1290

T.SYSACC A malicious process or user may gain unauthorized access to the administrator
account, or that of other trusted personnel.
T.UNATTENDED_SESSION
to an unattended session.

1295

1300

A malicious process or user may gain unauthorized access

T.UNAUTH_ACCESS
Unauthorized access to data by a user may occur. This includes
access via direct user interaction with the device, access via network transactions, and access via
removable electronic and printed media.
T.UNAUTH_MODIFICATION
resources may occur.

Unauthorized modification or use of XDS attributes and

T.UNDETECTED_ACTIONS
unauthorized actions may occur.

Failure of the XDS components to detect and record

T.UNIDENTIFIED_ACTIONS
unauthorized actions may occur.

Failure of the administrator to identify and act upon__________________________________________________________________________
46
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
T.UNKNOWN_STATE
Upon failure of XDS components, the security of the XDS
environment may be unknown.
1305

T.USER_CORRUPT

User data may be lost or tampered with by other users.

K.1.2: Security and Privacy Policy

1310

There are a wide variety of security and privacy regulations established by law and regulation.
These are interpreted and extended to create individual enterprise policies. This equipment will
be installed into a variety of enterprises that are subject to a variety of laws and regulations. The
XDS environment will provide support for the common aspects of these enterprise policies. The
policy statements whose enforcement must be provided by the XDS security mechanisms are:P.ACCOUNT
the system.

1315

The users of the system shall be held accountable for their actions within

P.AUTHORIZATIONThe system must limit the extent of each user’s abilities inaccordance with the TSPP. (See P.PATIENT_CARE)
P.AUTHORIZED_USERS Only those users who have been authorized to access theinformation within the system may access the system. (See P.PATIENT_CARE)

1320

P.CRYPTOGRAPHY
The system shall use standard approved cryptography (methods
and implementations) for key management (i.e., generation, access, distribution, destruction,
handling, and storage of keys) and cryptographic services (i.e., encryption, decryption, signature,hashing, key exchange, and random number generation services).
P.DECLARATIVE_SECURITY The system shall allow the administrator to define security
related rules. Examples include defining access control policies and password expiration
restriction.

1325

1330

P.I_AND_A All users must be identified and authenticated prior to accessing any controlled
resources with the exception of public objects.
P.OBJECTAUTHORIZATION The XDS components must enforce the policy regarding
how authorization is established for protected objects. The policy determines how access control
and other policies are enforced. (This is often considered part of P.Authorization, but in the
XDS context it may make sense to consider this as a separate policy.)
P.PATIENT_CARE The security and privacy measures should not prevent patient care. In
particular, there should be emergency bypass mechanisms to override security when necessary toprovide patient care.

1335

1340

P.SYSTEM_INTEGRITY The system must have the ability to periodically validate its correct
operation and, with the help of Administrators, Backup and Restore Operators, and Service
Personnel, it must be able to recover from any errors that are detected.
P.TRACEThe primary method for enforcing the security and privacy policy is the use ofauditing. The XDS components must have the ability to review the actions of individuals. The
XDS environment must provide sufficient audit information to external audit and monitoring
systems to permit the review of actions of individuals by that other system.
__________________________________________________________________________
47
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
P.TRUSTED_RECOVERY
Procedures and/or mechanisms shall be provided to assure
that, after a system failure or other discontinuity, recovery without a protection compromise is
obtained
1345

P.VULNERABILITY_SEARCH The XDS environment must undergo an analysis forvulnerabilities beyond those that are obvious.
K.1.3: Security Usage Assumptions
Assumptions of the use of the XDS environment:

1350

A.PHYSICAL
It is assumed that appropriate physical security is provided within thedomain for the value of the IT assets and the value of the stored, processed, and transmitted
information.
A. AUDIT_REVIEW
It is assumed that there will be audit repository and review services
provided that can accept audit information from the XDS components in real time.
A.OPERATION
It is assumed that networks, firewalls, etc. are deployed andmaintained to meet appropriate network security levels.

1355

A.PERSONNEL
It is assumed that the organization can assure IT user & otherworkforce personal integrity/trustworthiness.
A.PKI It is assumed that there will be a facility to provide signed certificates as needed for nodeand user authentication. The key management maybe done manually or automatically dependingon the availability of appropriate technology.

1360

K.2: Security Objectives

1365

This section defines the security objectives for the XDS environment. These objectives are
suitable to counter all identified threats and cover all identified organizational security policies
and assumptions. Common Criteria nomenclature is used. The XDS component security
objectives are identified with “O.” appended to at the beginning of the name and the environment
objectives are identified with “OE.” appended to the beginning of the name.
K.2.1: XDS Component Security Objectives
O.ACCESS The XDS components will ensure that users gain only authorized access to it andto the resources that it controls. (See O.EMERGENCY_BYPASS)

1370

1375

O.ACCESS_HISTORYThe XDS components will display information (to authorizedusers) related to previous attempts to establish a session.
O.ADMIN_ROLE The XDS components will provide separate administrator roles to isolate
administrative actions. These include a General Administrator role, a Backup and Restore
Operator role, a Cryptographic Administrator role, and a Service Personnel role. Additionalroles can be defined. These roles are collectively called Administrators.
__________________________________________________________________________
48
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
O.ADMIN_TRAINEDThe XDS components will provide authorized Administrators with
the necessary information for secure management and operation.

1380

O.AUDIT_GENERATIONThe XDS components will provide the capability to detectand create records of security and privacy relevant events associated with users. The XDS
components will reliably transmit this information to the central audit repository, and provide
reliable local storage of events until the central audit repository has confirmed receipt. (SeeOE.AUDIT_REVIEW)
O.AUDIT_PROTECTION Each XDS component will provide the capability to protect audit
information within its scope of control.

1385

O.AUDIT_REVIEW
If an external central audit repository is not part of theenvironment, the components will be configured to provide limited capability to analyze andselectively view audit information. (See OE.AUDIT_REVIEW)
O.CONFIG_MGMT
be tracked and controlled.

1390

1395

All changes to the components and its development evidence will

O.DECLARATIVE_SECURITY The components will allow security functions and access
control to be defined by the authorized administrator.
O.DISASTER_RECOVERYThe components should allow the authorized
Administrators to perform backup and restore of electronic data, and rapid configuration andreconfiguration of device operation. In addition, the TOE should support administrative
procedures to restore operation after disasters that may have substantially destroyed portions of
the hospital operation and where substitute temporary systems are in place.
O.DISCRETIONARY_ACCESS The components will control accesses to resources based
upon the identity of users and the role of users. (See O.EMERGENCY_BYPASS)

1400

O.DISCRETIONARY_USER_CONTROLThe components will allow authorized users
to specify which resources may be accessed by which users and groups of users. (SeeO.EMERGENCY_BYPASS)
O.EMERGENCY_BYPASSThe XDS components should allow access to any secured data
during a declared medical emergency.

1405

O.ENCRYPTED_CHANNEL
Based on the environmental policies, encryption may be
used to provide confidentiality of protected data in transit over public network.
O.INSTALL The XDS components will be delivered with the appropriate installation guidancein the form of installation manuals and training to establish and maintain component security.
O.INTRUSION_DETECTION
software (e.g., virus) is detected.

1410

The XDS components will ensure intrusion of malicious

O.MANAGE The XDS components will provide all the functions and facilities necessary tosupport the authorized Administrators in their management of the security of the TOE.
O.PROTECT
resources.

The XDS components will provide means to protect user data and__________________________________________________________________________
49
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1415

O.RECOVERY
Procedures and/or mechanisms will be provided to assure that recovery is
obtained without a protection compromise, such as from system failure or discontinuity.
O.REMOTE_SERVICEThe XDS components will provide the means for remote service
without sacrificing security or privacy policy.

1420

O.RESIDUAL_INFORMATION The XDS components will ensure that any information
contained in a protected resource is not released when the resource is reallocated. Informationon permanent media such as hard disk shall be secured during service and repair.
O.RESOURCE_SHARING

No user will block others from accessing resources.

O.SELF_PROTECTION Each XDS component will maintain a domain for its own
execution that protects itself and its resources from external interference, tampering, or
unauthorized disclosure.
1425

O.TRAINED_USERS
The XDS environment will provide authorized users with thenecessary guidance for secure operation.
O.TRUSTED_PATHThe TOE will provide a means to ensure users are notcommunicating with some other entity pretending to be the TOE. This covers entity
authentication. (See O.USER_AUTHENTICATION.)

1430

O.TRUSTED_SYSTEM_OPERATION
maintains security.

The XDS components will function in a manner that

O.USER_AUTHENTICATION The XDS components will verify the claimed identity of
the interactive user. (See O.ENTITY_AUTHENTICATION.)
1435

O.USER_IDENTIFICATION
users.

The XDS components will uniquely identify the interactive

K.2.2: Environment Security Objectives
OE.PHYSICAL
Physical security will be provided within the domain for the value of the
IT assets protected by the XDS environment and the value of the stored, processed, andtransmitted information.
1440

OE.AUDIT_REVIEW
There may be an audit repository and review service provided that
can accept audit information from the XDS environment in real time. This facility will provide
review and analysis functions. (See O.AUDIT_GENERATION, O.AUDIT_REVIEW)
OE.OPERATION
Networks, firewalls, etc. are deployed and maintained to meet
appropriate network security levels.

1445

OE.PERSONNEL
integrity/trustworthiness.

Assure IT user & other workforce personal

OE.PKI
There will be a facility to provide signed certificates as needed for node and user
authentication.

K.3: Functional Environment__________________________________________________________________________
50
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1450

The XDS can be modeled as having four different organizations that have a delegatedresponsibility relationship where each organization has a different functional responsibility. In
some configurations a single organization is responsible for two or more of these functions,which makes delegation much easier. This section discusses the major areas that must be solved.
The four functions are:

1455

Creator – This functional organization has created the PHI and is legally responsible to thepatient and others for providing healthcare and for protecting this data.
Repository – This functional organization is responsible for providing access to persistent
documents to readers. The creator has delegated responsibility to the repository to provide
adequate protection for a subset of the PHI. This subset is called the document.

1460

Registry - This functional organization is responsible for providing query services to readers.
The creator has delegated responsibility to the to the registry to provide adequate protection for asubset of the PHI. This subset is called the metadata.
Reader – This functional organization is providing healthcare services that make use of data thatis contained in the metadata and the documents.

1465
There are three levels of difficulty in delegation.

1470

1475

1480

1485

“Trivial” delegation is that where it is not necessary to delegate the responsibility for
implementing the threat mitigation. In those cases it does not matter whether the organizations
have the same policy or mitigations. For example, if the registry provides adequate mitigation
against the threat of disaster, it need not be concerned with the disaster related policies of thereader.
“Easy” delegation is that where the two organizations have the equivalent policies. In thosecases there is an initial difficult phase of discovering that the policies are the same and evaluatingthat the mitigation strategies are acceptable. This results in a simple binary decision to approveor disapprove a business relationship permitting the exchange of data. With the exception of thethree policy classes described as “hard” below, the details of policies are likely to differ, but thegoals are sufficiently uniform that a simple business decision can be made.
For the “easy” delegation, the IHE transactions must provide adequate mitigations for the threatsso that the business decision to exchange data can be made based simply on review of thepartners policies and mitigations. This means that some IHE transactions will have additional
security requirements attached. For example, encryption to avoid the threat of eavesdropping
may be required. These requirements are not unique to XDS and will be able to use standardized
security features like TLS and VPN tools. These requirements may be significantly different
from the usual practice within an enterprise, because of the differences in the environment.
“Hard” delegation is that where the two organizations have different policies orinconsistent/incompatible mitigation strategies. These are likely to occur for the following
policies, where organizations often disagree on the details of the policy goals, and where policies
often change:__________________________________________________________________________
51
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1490

1495

1500

1505

P.Authorization – The authorized access policies and authorized modification policies often
differ, and are often subject to change. The changes that occur are often at a detailed level, e.g.,access rights to a particular patient information may change. This means that either there is anagreed mechanism to propagate changes, or an acceptance that policy changes may not be
enforced, or there will be restrictions on the data exchange to avoid delegating responsibility fordata that is subject to change.
P.Account and P.trace – The policies for accountability and traceability often differ. These aremuch less subject to change, but it is often difficult to reconcile delegation when these policies
differ. This will be an especially difficult issue for repository and registry functions that support
multiple different creator organizations.
P.ObjectAuthorization – The policies regarding creation and modification of access rights often
differ. In addition, any of the policy and threat mitigations may be determined to be unacceptableby creator, registry, or repository. In the simple situation where there are only four real world
participants this simply means that there is no business relationship. In the more complex world
where the registry or repository are in many relationships with many creators and readers it
introduces a serious problem. Either the registry and repository must limit its relationship to that
small set of creators and readers that mutually accept all the policies and mitigations of all theother organizations, or there must be a mitigation strategy so that creators can restrict delegations
by the registry and repository to only those readers that have policies and mitigations that are
acceptable to the creator.
Mitigations for differences include the following:

1510

1515

Limit the data exchange to that data where the differences are not significant. For example,
highly sensitive data like psychiatric notes might not be shared, while relatively insignificant
data like allergy information is shared.
Provide a revocation mechanism to deal with policy changes, so that future delegations can beprohibited. It is often impractical to revoke past delegations because the PHI has already been
disclosed. But the revocation mechanism can stop further delegation from taking place. This
revocation mechanism must be part of the P.Authorization and P.ObjectAuthorization policies
and must be mutually acceptable for this mitigation to be effective.
Trusted third party inspections and audits can sometimes deal with reconciliation of differencesin P.Account and P.Trace.

1520

1525

An “approved delegation” list identifying acceptable and unacceptable creator/reader pairs canmitigate the repository and registry issues when the reader has incompatible policies with thecreator. This does require the creator to accept the approved delegation policy andimplementation of the repository and registry, but it reduces the combinatorial explosion ofpolicy combinations between creators, repositories, registries, and readers into a linear growth incomplexity.
The “approved delegation” may go further into identification of persons, but this is only a viable
path when all parties have policies the easily support delegation of personal responsibility.
Persons are usually required to comply with organizational policies, and organizations generally__________________________________________________________________________
52
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1530

1535

use roles rather than persons to establish policies. The often viable exception is the special caseof the “deny access to person X”. This can be a viable means of dealing with situations
involving a conflict of interest. This kind of access denial may be applicable to just a particularsubset of the PHI exchanged, (e.g., denying access to an ex-spouse).
These mitigations do not directly change the technical requirements for the XDS transactions.
They are policy decisions that may affect how particular actors are configured. The
implementation of XDS actors will need to be aware that this kind of site-specific configuration
management and policy control will be routinely required.

__________________________________________________________________________
53
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix V:

Web Services for IHE Transactions

V.1: Introduction
2340“Web Services” has become a catch-all phrase describing a wide range of HTTP transactions
over a TCP/IP network. A more precise definition of Web Services implies richer infrastructure
capabilities with all transactions built using SOAP messages. This appendix provides theguidelines for specifying the use of SOAP-based Web Services as the messaging infrastructure
and transport mechanism for IHE transactions.

2345

V.2: Relevant Standards

2350

Virtually all web services specifications are developed under the auspices of the World Wide
Web Consortium (W3C) or the Organization for the Advancement of Structured Information
Standards (OASIS). The Web Services-Interoperability organization (WS-I) publishes profiles,
which incorporate several existing standards, and constrain them for interoperability. For eachprofile, WS-I also publishes a test assertion document and corresponding interoperability testing
tools for Java and C#.
V.2.1: WS-I Profiles

2355

Even though the Web Services for IHE transactions will be based on SOAP 1.2, they will takeadvantage of the guidelines expressed in the WS-I Basic Profile 1.1 (BP 1.1) and Simple SOAP
Binding Profile 1.0 (SSBP 1.0) where applicable. Some IHE transaction may also take advantageof the WS-I Basic Security Profile 1.0 (BSP 1.0).
V.2.2: WS-* Specifications

2360

2365

In addition to the requirements of the current WS-I profiles, the Web Services for IHE
transactions will support the following Web Services standards:• WS-Addressing• MTOM• XOP• WS-Security
WS-I have started workgroups on defining profiles combining several of the above WS-*
standards, as well as including:• WS-SecureConversation• WS-Trust• WS-Policy• WS-ReliableMessaging__________________________________________________________________________
130
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2370

In the future, the Web Services for IHE transactions will consider support for these new WS-I
profiles, or particular WS-* standards as needed by specific use cases.
V.2.3: HL7 Web Services Profile

2375

The HL7 Web Services Profile provides a framework for using Web Services as the transportmechanism for HL7 V3 messages. The framework provides a layered approach to specifying
Web Services requirements. IHE will use the same approach as a guideline when specifying Web
Services transport for IHE transactions and will do its best to maintain this consistency overtime.
V.2.4: XML Namespaces

2380

Table V.2.4-1 lists XML namespaces that are used in this appendix. The choice of any
namespace prefix is arbitrary and not semantically significant.
Table V.2.4-1 XML Namespaces and Prefixes
PrefixNamespace

Specification

wsdl (ordefault)

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

WSDL 1.1 binding for SOAP 1.1
WSDL 1.1 binding for SOAP
1.2

wsoap12

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

WSDL 1.1 binding for SOAP
1.2

wsoap11

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

WSDL 1.1 binding for SOAP 1.1

wsoap

Either wsoap11 or wsoap12, depending on context

wsa

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

WSA 1.0 - Corewsaw

http://www.w3.org/2007/05/addressing/metadata

WSA 1.0 - Metadata

soap12

http://www.w3.org/2003/05/soap-envelope

SOAP 1.2

soap11

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

SOAP 1.1

soap

Either soap11 or soap12 depending on context

Hl7

urn:hl7-org:v3

HL7 V3 XML ITS

xsd

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

XML Schema

xsi

http://www.w3.org/2001/XMLSchema-instanceXML Schema

V.3: Web Services Requirements
2385

The requirements in this section represent guidance for IHE Technical Framework authors whoneed to use web services in specific transactions. These requirements fall into two categories:__________________________________________________________________________
131
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1. Providing consistency and clarity in the IHE specifications.
2. Affecting the wire format of the transactions.

2390

Note: When the requirements for particular text are specified, the following notation is used:• curly braces (i.e. {}) are used to denote a part of a string which shall always be
replaced with a string corresponding to the specific transaction, actor, or profile;• square brackets (i.e. []) are used to denote a part of a string which shall be either
replaced with a string corresponding to the specific transaction, or shall be completely
omitted.
V.3.1: Requirements for Transactions using HL7 V3 Messages

2395

When IHE transactions use HL7 V3 Messages, the Web Services protocol will conform to the
HL7 Web Services Basic, Addressing, Security, and Reliable Messaging Profiles, with additional
constraints as specified in the following sub-sections.
V.3.1.1:

2400

2405

HL7 WS Basic Profile Constraints

The Sender and Receiver shall conform to the HL7 WS Basic Profile with four modifications.
The first modification is the requirement of supporting SOAP 1.2, while the HL7 WS Basic
Profile provides the choice of supporting either SOAP 1.1 or SOAP 1.2, or both.
The second modification is to HL7-WSP200, which recommends that a WSDL document
describes a specific HL7 application role. For consistency with non-HL7 V3 transactions, IHE
specifications shall provide an example WSDL document for all transactions of an actor per
profile (see IHE-WSP200).
The third modification is to HL7-WSP201, which recommends that the HL7 Application Role ID
is to be used as the name of the WSDL definition. For consistency with non-HL7 V3 transactions
the name of the example WSDL definition provided in the IHE specification shall be the actor
name of the transaction's receiver (see the IHE-WSP201).

2410

2415

The fourth modification is to HL7-WSP202, which specifies the use of the HL7 namespace as
the target namespace of the WSDL document. This would prevent creating a single WSDL for
actors which use both HL7 V3 and non-HL7 V3 IHE transactions (e.g., an XDS registry
implementing the XDS.b profile with the Patient Identity Feed HL7 V3 transaction). For
consistency among all IHE transactions, when creating an IHE transaction specification, the
WSDL target namespace shall be specified as “urn:ihe:<committee name>:<profile>:<year> (seeIHE-WSP202).
V.3.1.2:

HL7 WS Addressing Profile Constraints

The Sender and Receiver should conform to the HL7 WS Addressing Profile. No additional
constraints are made in this sub-section.
2420

V.3.1.3:

HL7 WS Security Profile Constraints__________________________________________________________________________
132
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2425

IHE does not specify whether the Sender and Receiver should implement the HL7 WS Security
Profile. The decision to implement the HL7 WS Security Profile is left to implementers. Each
IHE transaction specifies its ATNA requirements for security and authentication. Security
profiles such as Cross-Enterprise User Assertion (XUA) contain further security requirements.
With the publication of WS-Security 1.1 and when the WS-I Basic Security Profile 1.1 isreleased, it is expected that ATNA (or a different profile) may incorporate additional options for
Web Services, and the HL7 WS Security Profile will be incorporated in this appendix.
V.3.1.4:2430

HL7 WS Reliable Messaging Profile Constraints

IHE does not specify whether the Sender and Receiver should implement the HL7 WS Reliable
Messaging Profile. The decision to implement the HL7 WS Reliable Messaging Profile is left to
implementers. When the WS-I Reliable Secure Profile Working Group releases a profile it isexpected that additional options for Web Services may be added, and the HL7 WS Reliable
Messaging Profile will be incorporated in this appendix.
V.3.2: Requirements for Transactions which don’t use HL7 V3 Messages

2435

The following IHE web services requirements are derived from the HL7 Web Services profile.
This provides consistency among the IHE transactions, compatibility to existing Web Services
implementations through the WS-I profiles, and a well-defined mechanism for adding additional
layers of web services in the future. The HL7 Web Services profile also provides detailed
background regarding the requirements presented here.

2440

The numbering scheme for the individual requirements uses the following convention:• IHE-WS[P|A|S|RM]nnn[.e]) text

2445

2450

P, A, S, and RM represent the Basic, Addressing, Security, and Reliable Messaging requirements
sections in this specification, nnn represents a unique number for this specification, and text isthe text of the requirement. This directly corresponds to the convention used in the HL7 Web
Services profile, and for easier navigation, the same numbers correspond to the equivalentrequirements in both specifications. Note that not all implementation decisions from the HL7
Web Services profile are relevant for non-HL7 web services transactions. If there are cases
where an IHE Web Services requirement exists that does not correspond to an implementation
decision from the HL7 Web Services Profile, the optional extension to the number (shown as .e
above) can be used to eliminate the possibility of confusion.
Table V.3.2-1 Web Services Requirements for Non-HL7 Transitions
Requirement
Identifier

Requirement text

SOAP message
format affected?

IHE-WSP200

Example WSDL documents shall implement a specific IHE
Actor within a specific IHE Integration Profile.

No

IHE-WSP201

The attribute /wsdl:definitions/@name in the example WSDL
document provided with an IHE specification shall be thename of the IHE Actor providing the service.

No

IHE-WSP202

The targetNamespace of the example WSDL shall beurn:ihe:{committee}:{profile}:{year}

No__________________________________________________________________________
133
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Requirement
Identifier

Requirement text

SOAP message
format affected?

IHE-WSP203

The example WSDL shall include XML Schema Definitionreferences for the transactions payloads.

No

IHE-WSP205

Two WSDL messages shall be defined for a request-responsetransaction.

No

IHE-WSP206

In the example WSDL provided by an IHE specification asingle WSDL part named Body shall be defined for each
WSDL message and the part type shall refer to an element
defined in the Schema Definition required in IHE-WSP203.

Determines the formatof the SOAP Body

IHE_WSP207

For each input and output message defined in the WSDL
portType operation an attribute wsaw:Action SHALL be
included.

No

IHE_WSP208

WSDL operations SHALL use
wsdl:operation/wsdl:input/@wsaw:Action ="urn:ihe:{committee}:{Year}:{Transactionname}[Operation]" andwsdl:operation/wsdl:output/@wsaw:Action ="urn:ihe:{committee}:{Year}:{Transactionname}[Operation]Response"

Determines the SOAP
header content for
wsa:Action

IHE_WSP211

Operations defined in the WSDL portType may or may nothave a wsoap:operation/@soapAction attribute provided.

Determines the valueof soapAction

SOAP message consumers shall ignore any soapAction value
found in a SOAP message.
IHE_WSP212

The example WSDL provided with an IHE specification shalluse the SOAP Binding described in WSDL 1.1 Chapter 3 andthe binding extension for SOAP 1.2.

No

IHE_WSP215

IHE transactions referencing the standards specified by
Appendix V shall support SOAP 1.2, unless otherwise notedin the transaction. The example WSDL document provided
with an IHE specification shall contain a SOAP 1.2 binding
unless the transaction specifically notes that SOAP 1.2 is notsupported.

Determines thenamespace of the
SOAP message

IHE_WSP216

For transactions which require SOAP 1.1 (contrary to thedefault SOAP 1.2) the WSDL shall contain a SOAP 1.1
binding. If the example WSDL document provided with an
IHE specification contains a SOAP 1.1 binding, it shall use
the SOAP Binding described in WSDL 1.1 Chapter 3.

Determines thenamespace of the
SOAP message

IHE_WSP300

SOAP messages and WSDL documents shall conform to the
WS-I Basic Profile 1.1 (within the requirements for IHEWSP215).

Yes

IHE_WSA100

The example WSDL provided with IHE transactions shall use
the WS-Addressing framework when specifying the Web
Services protocol.

Determines the WSA
content for the SOAP
headerIHE_WSA101

All <wsa:Action> elements shall have themustUnderstand attribute set (mustUnderstand=”1”)

Ensures that web
services frameworks
are configured toproperly generate andprocess WSAddressing headers

IHE_WSA102

The <wsa:ReplyTo> element of the initiating message

Ensures that responses__________________________________________________________________________
134
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Requirement
Identifier

Requirement text
shall be present and shall have the mustUnderstand attributeset (mustUnderstand=”1”)

2455

V.3.2.1:

Basic Requirements

V.3.2.1.1.

Naming conventions and namespaces

SOAP message
format affected?
are routed to theappropriate webservices end point, oras an immediate
response

IHE-WSP200) Example WSDL documents shall implement a specific IHE Actor within a
specific IHE Integration Profile.
This editorial requirement means that if several IHE actors within a profile are combined, thenseparate WSDL documents for each actor need to be provided. This only applies to actors, which
provide a particular service, i.e. the receivers in an IHE transaction.
IHE-WSP201)

2460

2465

IHE requires the profile writers and recommends the implementers to use the following naming
convention for WSDL artifacts.
• NAME – represents the formal IHE Actor Name of the actor providing the service withspaces omitted from the name (ex. DocumentRegistry is the NAME value for the XDS.b
Document Registry Actor). Specifically, NAME is the value of the /wsdl:definitions/@nameattribute which will be specified for each transaction.
• Transaction Name – represents the formal IHE Transaction Name for this particular webservice exchange with spaces omitted from the name (ex. RegistryStoredQuery is the
TRANSACTION_for the XDS.b Registry Stored Query Transaction)
WSDL Artifact

2470

Proposed Naming

message request{Transaction Name}_Message

message response{Transaction Name}Response_Message

portType{NAME}_PortType

Operation{NAME}_{Transaction Name}[_OperationID]

SOAP 1.1 binding{NAME}_Binding_Soap11

SOAP 1.1 port

{NAME}_Port_Soap11

SOAP 1.2 binding{NAME}_Binding_Soap12

SOAP 1.2 port

{NAME}_Port_Soap12

Here is an example of how the nomenclature is applied:
For wsdl:definitions/@name="DocumentRegistry":message request-> "RegistryStoredQuery_Message"__________________________________________________________________________
135
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
message response

2475-> RegistryStoredQueryResponse_Message

portType-> "DocumentRegistry_PortType"operation-> "DocumentRegistry_RegistryStoredQuery_Request"

SOAP 1.2 port-> "DocumentRegistry_Port_Soap12"

SOAP 1.1 port-> "DocumentRegistry_Port_Soap11"

SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"

SOAP 1.1 binding -> "DocumentRegistry_Binding_Soap11"

2480

2485

2490

IHE-WSP202)
IHE requires the use of the following naming convention for targetNamespace of example
WSDL.
• DOMAIN – represents the acronym of the IHE domain who authored this web-service
transaction (ex. iti)
• PROFILE – represents the acronym of the IHE profile which references this web-service
transaction (ex. xds-b)• YEAR – represents the four digit year that this transaction was first published within a Trial
Implementation profile• TYPE – optional extension of which other IHE specifications already using XML
namespaces may make use
The targetNamespace of the example WSDL shall beurn:ihe:{DOMAIN}:{PROFILE}:{YEAR} and may be extended tourn:ihe:{DOMAIN}:{PROFILE}:{YEAR}:{TYPE}

2495

As an example the namespace for the 2008 XDS.b Integration Profile is urn:ihe:iti:xdsb:2007.
IHE-WSP203) The example WSDL shall include XML Schema Definition references for thetransactions payloads.

2500

The purpose of this requirement is to specify how authors of IHE profiles specify thetransactions which use web services. This requires both the existence of an XML schema
definition for the transaction payloads, and the manner in which it is specified in the WSDL file– by reference.
V.3.2.1.2:

Message and portType Definitions

IHE-WSP205) Two WSDL messages shall be defined for a request-response transaction.
2505

IHE-WSP206) In the example WSDL provided by an IHE specification a single WSDL part
named Body shall be defined for each WSDL message and the part type shall refer to an element
defined in the Schema Definition required in IHE-WSP203.

__________________________________________________________________________
136
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
IHE-WSP207) For each input and output message defined in the WSDL portType operation an
attribute wsaw:Action SHALL be included.
2510

2515

For compatibility with the Addressing requirements and consistency with naming across IHE
Web Services implementations, the wsaw:Action attribute for each WSDL input and output
message must be defined.
The wsaw:Action attribute shall be ignored by Web Services implementations that do notsupport WS-Addressing. It is very important to have the attribute in mixed cases where just oneof the endpoints might support the WS-Addressing specification to avoid communication or
routing errors.
IHE-WSP208) WSDL operations SHALL use wsdl:operation/wsdl:input/@wsaw:Action ="urn:ihe:{Domain}:{Year}:{Transaction name}" andwsdl:operation/wsdl:output/@wsaw:Action = "urn:ihe:{Domain}:{Year}:{Transactionname}Response"2520

For example, the wsaw:Action value for the Registry Stored Query (ITI-18) transaction is
specified as “urn:ihe:iti:2007:RegistryStoredQuery” and“urn:ihe:iti:2007:RegistryStoredQueryResponse”.

V.3.2.1.3:
2525

2530

Binding

Multiple WSDL bindings can be defined in order to support different protocols and transports.
The naming is consistent with the naming rules specified in the previous section.
IHE-WSP211) For each operation defined in the WSDL portType awsoap:operation/@soapAction attribute shall be provided. The value of
wsoap:operation/@soapAction shall be consistent with the name for the corresponding WSDL
operation defined in the WSDL portType (see IHE-WSP207 and IHE-WSP208)
IHE-WSP212) The example WSDL provided with an IHE specification shall use the SOAP
Binding described in WSDL 1.1 Chapter 3 and the binding extension for SOAP 1.2.

2535

IHE-WSP215) IHE transactions referencing the standards specified by Appendix V shallsupport SOAP 1.2, unless otherwise noted in the transaction. The example WSDL document
provided with an IHE specification shall contain a SOAP 1.2 binding unless the transaction
specifically notes that SOAP 1.2 is not supported.
SOAP 1.2 is the base standard for several WS specification, and has many available and easily
accessible implementations.

2540

IHE-WSP216) For transactions which require SOAP 1.1 (contrary to the default SOAP 1.2) the
WSDL shall contain a SOAP 1.1 binding. If the example WSDL document provided with an IHE
specification contains a SOAP 1.1 binding, it shall use the SOAP Binding described in WSDL
1.1 Chapter 3.
A SOAP 1.1 binding can be useful for backwards compatibility.
__________________________________________________________________________
137
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2545

IHE-WSP300) SOAP messages and WSDL documents shall conform to the WS-I Basic Profile
1.1 (within the requirements for IHE-WSP215).
Example 1: Example WSDL File with an Non-HL7 Transaction

2550

2555

2560

2565

2570

2575

2580

2585

2590

2595

<definitions xmlns:wsoap11="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:rs="urn:oasis:names:tc:ebxmlregrep:xsd:rs:3.0"
targetNamespace="urn:ihe:iti:xds-b:2007"
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsaw="http://www.w3.org/2007/05/addressing/wsdl"
name="XDSRepository"><documentation>IHE XDS Document Repository</documentation><types><xsd:schema elementFormDefault="qualified"><xsd:import namespace="urn:oasis:names:tc:ebxmlregrep:xsd:rs:3.0"
schemaLocation="../schema/ebXML_RS/rs.xsd"/><xsd:import namespace="urn:ihe:iti:xds-b:2007"
schemaLocation="../schema/IHE/IHEXDS.xsd"/></xsd:schema></types><message name="RetrieveDocumentSet_Message"><documentation>Retrieve Document Set</documentation><part name="body" element="ihe:RetrieveDocumentSetRequest"/></message><message name="RetrieveDocumentSetResponse_Message"><documentation>Retrieve Document Set Response</documentation><part name="body" element="ihe:RetrieveDocumentSetResponse"/></message><message name="ProvideAndRegisterDocumentSet_Message"><documentation>Provide and Register Document Set</documentation><part name="body"element="ihe:ProvideAndRegisterDocumentSetRequest"/></message><message name="ProvideAndRegisterDocumentSetResponse_Message"><documentation>Provide And Register Document Set
Response</documentation><part name="body" element="rs:RegistryResponse"/></message><portType name="XDSDocumentRepository_PortType"><operation name="ProvideAndRegisterDocumentSet"><input message="ihe:ProvideAndRegisterDocumentSet_Message"
wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSetb"/><output
message="ihe:ProvideAndRegisterDocumentSetResponse_Message"
wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSetbResponse"/></operation><operation name="RetrieveDocumentSet"><input message="ihe:RetrieveDocumentSet_Message"__________________________________________________________________________
138
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2600

2605

2610

2615

2620

2625

2630

2635

2640

2645

wsaw:Action="urn:ihe:iti:2007:RetrieveDocumentSet"/><output message="ihe:RetrieveDocumentSetResponse_Message"
wsaw:Action="urn:ihe:iti:2007:RetrieveDocumentSetResponse"/></operation></portType><binding name="XDSDocumentRepository_Binding_Soap11"
type="ihe:XDSDocumentRepository_PortType"><wsoap11:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="ProvideAndRegisterDocumentSet"><wsoap11:operation
soapAction="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"/><input><wsoap11:body use="literal"/></input><output><wsoap11:body use="literal"/></output></operation><operation name="RetrieveDocumentSet"><wsoap11:operation
soapAction="urn:ihe:iti:2007:RetrieveDocumentSet"/><input><wsoap11:body use="literal"/></input><output><wsoap11:body use="literal"/></output></operation></binding><binding name="XDSDocumentRepository_Binding_Soap12"
type="ihe:XDSDocumentRepository_PortType"><wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/><operation name="ProvideAndRegisterDocumentSet"><wsoap12:operation
soapAction="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output></operation><operation name="RetrieveDocumentSet"><wsoap12:operation
soapAction="urn:ihe:iti:2007:RetrieveDocumentSet"/><input><wsoap12:body use="literal"/></input><output><wsoap12:body use="literal"/></output>__________________________________________________________________________
139
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2650

2655

2660

</operation></binding><service name="XDSDocumentRepository_Service"><port name="XDSDocumentRepository_Port_Soap11"
binding="ihe:XDSDocumentRepository_Binding_Soap11"><wsoap11:address
location="http://servicelocation/XDSDocumentRepository_Service"/></port><port name="XDSDocumentRepository_Port_Soap12"
binding="ihe:XDSDocumentRepository_Binding_Soap12"><wsoap12:address
location="http://servicelocation/XDSDocumentRepository_Service"/></port></service></definitions>

V.3.2.2:
2665

2670

2675

Addressing Requirements

The Web Services Addressing specification (WS-Addressing) defines a framework for atransport-neutral SOAP messaging. Although understanding the concepts outlined in WSAddressing is important, most of the underlying details will be shielded by the abstraction layers
provided to developers. This specification assumes an abstract separation between theapplication layer, the Web services messaging infrastructure layer, and the message transportlayer.
The IHE transaction is built at the application layer, it is passed to the Web services messaging
infrastructure layer where the SOAP message is constructed according to the rules set in the
WSDL. The action value specified in the WSDL is used to construct the <wsa:Action> SOAP
header. The endpoint address specified in the WSDL (or the supplied end point reference) is used
to construct the <wsa:To>. Depending on the message exchange pattern (e.g., one-way, requestresponse), other WS-Addressing headers may be added at this point (e.g., <wsa:From>,<wsa:ReplyTo>, etc.).
IHE-WSA100) The example WSDL provided with IHE transactions shall use the WSAddressing framework when specifying the Web Services protocol.

2680

IHE-WSA101) All <wsa:Action> elements shall have the mustUnderstand attribute set(mustUnderstand=”1”)
IHE-WSA102) The <wsa:ReplyTo> element of the initiating message shall be present andshall have the mustUnderstand attribute set (mustUnderstand=”1”)

2685

2690

Example 2: Request Message<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soap12:Header><wsa:Action
soap12:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetb</wsa:Action><wsa:MessageID>urn:uuid:1600bc1a-10fd-4c3a-b41b7a15f4f46fb9</wsa:MessageID>__________________________________________________________________________
140
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________<wsa:ReplyTo soap12:mustUnderstand="1">

2695

2700

2705

s>

<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Addres</wsa:ReplyTo><wsa:To>
http://localhost:2647/XdsService/IHEXDSRepository.svc</wsa:To></soap12:Header><soap12:Body><ProvideAndRegisterDocumentSetRequest xmlns="urn:ihe:iti:xdsb:2007"/></soap12:Body></soap12:Envelope>

Example 3: Response Message
2710

2715

2720

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soap12:Header><wsa:Action
soap12:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetbResponse</wsa:Action><wsa:RelatesTo>urn:uuid:1600bc1a-10fd-4c3a-b41b7a15f4f46fb9</wsa:RelatesTo></soap12:Header><soap12:Body><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxmlregrep:xsd:rs:3.0"/></soap12:Body></soap12:Envelope>

V.3.2.3:

2725

Security Requirements

The IHE ATNA Integration Profile contains requirements which address certain aspects of
security and authentication, including HTTPS transport requirements. Individual transactions
which use Web Services will incorporate these requirements depending on their needs. Security
profiles such as Cross-Enterprise User Assertion (IHE XUA) contain further security
requirements. With the publication of the WS-I Basic Security Profile it is expected that ATNA
will incorporate additional options for Web Services, and this appendix will reflect any
requirements specific for Web Services for IHE transactions.

2730

V.4: Web Services for specific IHE Transactions

2735

The Web Services specification is provided in three parts. The first part will be in Volumes 2aand 2b, where a separate subsection shall be added for each affected IHE transaction at the endof the “Message Semantics” section. This subsection shall detail the types and message parts of
the WSDL. The actor-specific constraints against the IHE Web Services Requirements specified
above shall be added at the end of each “Expected Actions” section.

__________________________________________________________________________
141
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2740

The second, informative part of the specification shall be on the IHE ftp site (See ITI TF-2x:
Appendix W), which shall contain a complete WSDL (Web Services Description Language)
description of the web service, which aggregates the snippets from Volumes 2a and 2b describedabove. There will be one WSDL contract per actor per profile. Each transaction is represented bya port type, where the operations names and message names follow the requirements specified in
ITI TF-2x: V.3.2.1.1. The complete WSDL is for reference purposes for implementers.

V.5: Web Services Standards Evolution
2745

As the industry acceptance of newer standards/newer versions of existing standards progresses,
new options will be added to existing transactions. One such expected change is the support for
WS-Security and WS-Reliable Messaging as new options to web services transactions.

V.6: Web Services References
WS-I: http://ws-i.org/
WS-I Basic Profile 1.1: http://www.ws-i.org/Profiles/BasicProfile-1.1.html
2750

WS-I Simple SOAP Binding Profile: http://www.ws-i.org/Profiles/SimpleSoapBindingProfile1.0.html
SOAP 1.1: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
SOAP 1.2: http://www.w3.org/TR/soap12-part0/
WSDL 1.1 SOAP 1.1 binding (Chapter 3): http://www.w3.org/TR/wsdl.html#_soap-b
WSDL 1.1 SOAP 1.2 binding: http://www.w3.org/Submission/wsdl11soap12/2755

HL7 V3 Web Services Profile:
http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-wsprofiles.htm
WS-Addressing: http://www.w3.org/TR/ws-addr-core
WS-I Basic Security Profile: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
MTOM: http://www.w3.org/TR/soap12-mtom/

2760

XOP: http://www.w3.org/TR/xop10/
WS-Security 1.0: http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss#technical
WS-Security 1.1: http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss#technical2765

WS-Secure Conversation: http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf
WS-Trust: http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html
WS-Policy: http://www.w3.org/Submission/WS-Policy/
WS-Reliable Messaging: http://docs.oasis-open.org/ws-rx/wsrm/200702__________________________________________________________________________
142
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix W: Implementation Material
2770

Implementation material for ITI profiles such as XDS, XCA, RFD can be found on the IHE FTP
site under ftp://ftp.ihe.net/TF_Implementation_Material/ITI/.
Some of the types of implementation material available are schema, examples and informative
WSDL.

__________________________________________________________________________
143
Rev. 8.0 – 2011-08-19

Copyright © 2011: IHE International, Inc.