Integrating the Healthcare Enterprise

5

10

IHE IT Infrastructure
Technical Framework
Volume 2x
IHE ITI TF-2x
Volume 2 Appendices

15

20

Revision 12.0 – Final Text
September 18, 201525

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

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________CONTENTS
30

35

40

45

50

55

60

65

Appendix A: Web Service Definition for Retrieve Specific Information for Display and
Retrieve Document for Display Transaction.............................................................................. 6
Appendix B: Definition of Document Unique Ids ................................................................... 14
B.1: Requirements for Document UIDs ................................................................................... 14
B.2: Structure of a Document UID ........................................................................................... 14
B.3: Document UID encoding rules ......................................................................................... 15
B.4: How to obtain a UID registration root? ............................................................................ 15
B.5: Example of a Document UID ........................................................................................... 15
B.6: Representing UUIDs as OIDs ........................................................................................... 16
Appendix C: HL7 Profiling Conventions ................................................................................ 17
C.1: HL7 Message Profiling Convention ................................................................................. 18
Static definition - Message level ........................................................................ 18
C.1.1:
C.1.2:
Static definition – Segment level and Data Type level ...................................... 19
C.2: HL7 Implementation Notes............................................................................................... 20
C.2.1:
Network Guidelines ............................................................................................ 20
C.2.2:
Message Control ................................................................................................. 21
Acknowledgment Modes .................................................................................... 22
C.2.3:
C.2.4:
Common Segment Definitions ........................................................................... 26
C.2.5:
Message granularity............................................................................................ 26
C.2.6:
HL7 empty field convention ............................................................................... 27
Appendix D: Cross-Profile Interactions of PIX and PSA ........................................................ 28
D.1: Namespace Translation from PIX Query to CCOW......................................................... 30
D.2: Processing Multiple Identifiers ......................................................................................... 30
Appendix E:
Usage of the CX Data Type in PID-3-Patient Identifier List ............................. 32
E.1: Patient Identifier Cross-reference Manager Actor Requirements ..................................... 33
E.1.1:Other actor requirements ........................................................................................... 34
E.1.2:Examples of use ......................................................................................................... 35
E.1.3:Data sent by source systems ...................................................................................... 35
E.1.4:Data sent by the Patient Identifier Cross-reference Manager .................................... 36
E.2: HL7 V3 II Data Type ........................................................................................................ 37
E.2.1:Patient Identifier Cross-reference Manager requirements ......................................... 38
E.2.2:Other actor requirements ........................................................................................... 39
E.2.3:Examples of use ......................................................................................................... 40
Appendix F:
Character String Comparisons ............................................................................ 42
Appendix G: Transition from Radiology Basic Security to ATNA ......................................... 43
Appendix H: Intentionally Left Blank ..................................................................................... 44
Appendix I:
Intentionally Left Blank ..................................................................................... 45
Appendix J:
Intentionally Left Blank ..................................................................................... 46
Appendix K: XDS Security Environment ................................................................................ 47
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

2

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

70

75

80

85

90

95

100

105

110

K.1: Security Environment ....................................................................................................... 47
K.1.1:
Threats ................................................................................................................ 47
K.1.2:
Security and Privacy Policy................................................................................ 49
K.1.3:
Security Usage Assumptions .............................................................................. 50
K.2: Security Objectives ........................................................................................................... 50
K.2.1:XDS Component Security Objectives ................................................................ 50
K.2.2:
Environment Security Objectives ....................................................................... 52
K.3: Functional Environment.................................................................................................... 53
Appendix L:
Relationship of Document Entry Attributes and Document Headers ................ 55
Appendix M: Using Patient Demographics Query in a Multi-Domain Environment .............. 56
M.1:
HL7 QBP^Q22 Conformance Model ........................................................................ 56
M.2:
IHE PDQ Architecture ............................................................................................... 56
M.3:
Implementing PDQ in a multi-domain architecture .................................................. 57
Appendix N: Common Data Types .......................................................................................... 59
N.1: CX Data Type ................................................................................................................... 59
N.2: EI Data Type ..................................................................................................................... 59
N.3: HD Data Type ................................................................................................................... 60
N.4: PL data Type ..................................................................................................................... 60
N.5: TS Data Type .................................................................................................................... 62
N.6: XPN Data Type ................................................................................................................. 63
Appendix O: HL7 v3 Transmission and Trigger Event Control Act Wrappers....................... 65
O.1: HL7 V3 Transmission Wrappers ...................................................................................... 65
O.1.1:
Send Message Payload Information Model (MCCI_RM000100IHE) ............... 65
O.1.2:
Send Accept Acknowledgement Information Model (MCCI_RM000200IHE) 68
O.1.3:
Send Application Acknowledgement Information Model(MCCI_RM000300IHE)............................................................................................ 72
O.2: HL7 V3 Transmission Content ......................................................................................... 76
O.2.1:
Master File/Registry Event Notification Control Act (Role Subject) Information
Model (MFMI_MT700701IHE) ................................................................................ 76
O.2.2:
Master File/Registry Query Response Control Act (Role Subject) Information
Model (MFMI_MT700711IHE) ................................................................................ 80
O.2.3:
Query Control Act Request: Query By Parameter Information Model(QUQI_MT021001IHE) ............................................................................................ 83
O.2.4:
Query Control Act Request Continue/Cancel Information Model(QUQI_MT000001IHE) ............................................................................................ 85
O.3: IHE Transactions and Corresponding Transmission and Control Act Wrappers ............. 87
Appendix P:
Examples of messages ........................................................................................ 88
P.1: Example of transaction ITI-31: Admit for Surgical Procedure ........................................ 88
P.1.1: Storyboard.................................................................................................................. 88
P.1.2: Interaction Diagram ................................................................................................... 89
P.1.3: Messages .................................................................................................................... 91
P.2: Example of transaction ITI-31: Admit and cancel admit.................................................. 93
P.2.1: Storyboard.................................................................................................................. 93
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

3

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

115

120

125

130

135

140

145

150

P.2.2: Interaction Diagram ................................................................................................... 94
P.2.3: Messages .................................................................................................................... 95
P.3: HL7 V3 Sample Messages ................................................................................................ 95
P.3.1: ITI-44 Patient Identity Feed HL7 V3 – Sample Messages ........................................ 95
P.3.2: ITI 45 PIXV3 Query – Sample Messages ................................................................. 96
P.3.3: ITI 46 PIXV3 Update Notification – Sample Messages ........................................... 96
P.3.4: ITI 47 Patient Demographics Query HL7 V3 – Sample Messages ........................... 96
Appendix Q: HL7 V3 Sample Payload XML Schemas ........................................................... 97
Q.1: ITI-44 Patient Identity Feed HL7 V3 – Sample Schemas ................................................ 97
Q.2: ITI-45 PIXV3 Query – Sample Schemas.......................................................................... 97
Q.3: ITI-46 PIXV3 Update Notification – Sample Schemas .................................................... 97
Q.4: ITI-47 Patient Demographics Query HL7 V3 – Sample Schemas ................................... 98
Appendix R: Mapping of HL7v2.5 to HL7v3 for PIX and PDQ ............................................. 99
R.1: Data Types ........................................................................................................................ 99
R.2: Add New Person Message .............................................................................................. 101
Appendix S:
Intentionally Left Blank ................................................................................... 125
Appendix T:
Use of eMail (Informative) ............................................................................... 126
Appendix U: Intentionally Left Blank ................................................................................... 129
Appendix V: Web Services for IHE Transactions ................................................................. 130
V.1: Introduction ..................................................................................................................... 130
V.2: Relevant Standards.......................................................................................................... 130
V.2.1:
WS-I Profiles .................................................................................................... 130
V.2.2:
WS-* Specifications ......................................................................................... 130
V.2.3:
HL7 Web Services Profile ................................................................................ 131
V.2.4:XML Namespaces ............................................................................................ 131
V.3: Web Services Requirements ........................................................................................... 131
V.3.1:
Requirements for Transactions using HL7 V3 Messages ................................ 132
V.3.2:
Requirements for Transactions which don’t use HL7 V3 Messages ............... 133
V.4: Web Services for specific IHE Transactions .................................................................. 142
V.5: Synchronous and Asynchronous Web Services Exchange ............................................. 143
V.5.1:
Overview .......................................................................................................... 143
V.5.2:
Considerations for using Asynchronous Web Services Exchange ................... 143
V.5.3:
Specification of the use of Asynchronous Web Services Exchange ................ 144
V.6: Web Services Standards Evolution ................................................................................. 144
V.7: Web Services References ................................................................................................ 144
Appendix W: Implementation Material .................................................................................. 146
Appendix X: Basic Unstructured Workflow Definition Example .............................................. 146
X.1 Workflow definition identifier ........................................................................................ 146
X.2 Workflow definition identifier ........................................................................................ 146
X.3 Workflow opening and closing ....................................................................................... 146
X.4 Tasks descriptions ........................................................................................................... 147
X.4.1 Task type “born completed” .................................................................................... 147
X.4.2 Task type “two states task” ..................................................................................... 147
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

4

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
155

GLOSSARY ............................................................................................................................... 149

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

5

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

160

165

Appendix A:
Web Service Definition for Retrieve SpecificInformation for Display and Retrieve Document for Display
Transaction
The following is an example WSDL definition of web services used in Transactions ITI-11 andITI-12. This code is provided as an example and is not intended to replace the formal
specification of Transactions ITI-11 and ITI-12 in Volume 2a. Also, the definitions ofsummaryRequestType, listRequestType and contentType shall correspond to the capabilities of
the Information Source Actor.
<?xml version="1.0" encoding="utf8"?>

170

175

180

185

190

195

200

205

<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/"><!-- Defines the types available for the parameters --><!-- May also include the return type definitions --><types><s:schema elementFormDefault="qualified"targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"><!-- Add any items that control the returned values list or type here -><!-- Add or remove items in the actual supplied WSDL to show theavailable types. --><s:simpleType name="summaryRequestType"><s:restriction base="s:string"><s:enumeration value="SUMMARY" /><s:enumeration value="SUMMARY-RADIOLOGY" /><s:enumeration value="SUMMARY-CARDIOLOGY" /><s:enumeration value="SUMMARY-LABORATORY" /><s:enumeration value="SUMMARY-SURGERY" /><s:enumeration value="SUMMARY-EMERGENCY" /><s:enumeration value="SUMMARY-DISCHARGE" /><s:enumeration value="SUMMARY-ICU" /></s:restriction></s:simpleType><s:simpleType name="listRequestType"><s:restriction base="s:string"><s:enumeration value="LIST-ALLERGIES" /><s:enumeration value="LIST-MEDS" /></s:restriction></s:simpleType>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

6

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

210

215

220

225

230

235

240

245

250

<!-- Please list all content types available, and remove those notavailable. --><s:simpleType name="contentType"><s:restriction base="s:string"><s:enumeration value="text/html" /></s:restriction></s:simpleType><!-- Indicates that this item is a returned rows restriction --><s:simpleType name="ReturnedResultCount" type="s:positiveInteger" /><!-- Please use the string "Search" as a prefix for all search
criteria, and list below --><!-- Indicates that this item is a search string --><s:simpleType name="SearchString" type="s:string" /></s:schema></types><message name="RetrieveSummaryInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined
above. --><part name="requestType" type="summaryRequestType" /><part name="patientID" type="SearchString" /><part name="lowerDateTime" type="s:dateTime" /><part name="upperDateTime" type="s:dateTime" /><part name="mostRecentResults" type="ReturnedResultCount" /></message><message name="RetrieveSummaryInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that --><!-- it be used here instead of s0:string. If a complex type is allowed
as one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveListInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined
above. --><part name="requestType" type="listRequestType" /><part name="patientID" type="SearchString" /></message>

255<message name="RetrieveListInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that -->HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

7

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

260

265

270

275

280

285

290

295

300

305

310

<!-- it be used here instead of s0:string. If a complex type is allowed
as one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveDocumentHttpGetIn"><!-- Add other parameters here if they are available, using types defined
above. --><!-- It is recommended that one of the sub-types of SearchUID is chosen
here --><!-- Especially if SearchStudyUID is allowed, then the display client canknow that --><!-- it is permissible to use a dicom uid here --><part name="documentUID" type="SearchString" /><part name="contentType" type="contentType" /></message><message name="RetrieveDocumentHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that --><!-- it be used here instead of s:string. If a complex type is allowed as
one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s:string" /></message><portType name="IHERetrieveForDisplayHttpGet"><operation name="RetrieveSummaryInfo"><input message="s0:RetrieveSummaryInfoHttpGetIn" /><output message="s0:RetrieveSummaryInfoHttpGetOut" /></operation><operation name="RetrieveListInfo"><input message="s0:RetrieveListInfoHttpGetIn" /><output message="s0:RetrieveListInfoHttpGetOut" /></operation><operation name="RetrieveDocument"><input message="s0:RetrieveDocumentHttpGetIn" /><output message="s0:RetrieveDocumentHttpGetOut" /></operation></portType><binding name="IHERetrieveForDisplayHttpGet"
type="s0:IHERetrieveForDisplayHttpGet"><http:binding verb="GET" /><operation name="RetrieveSummaryInfo"><http:operation location="/IHERetrieveSummaryInfo" /><input><http:urlEncoded />HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

8

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________</input>

315

320<output><mime:content type="text/html" /></output></operation><operation name="RetrieveListInfo"><http:operation location="/IHERetrieveListInfo" /><input><http:urlEncoded /></input>

325<output><mime:content type="text/html" /></output></operation>

330<operation name="RetrieveDocument"><http:operation location="/IHERetrieveDocument" /><input><http:urlEncoded /></input>

335

340

345

350

355

360

<!-- The type of the output should be restricted on a per-server basis
to the types --><!-- actually provided. --><output><mime:content type="text/html" /><mime:content type="application/x-hl7-cda-level-one+xml" /><mime:content type="application/pdf" /><mime:content type="image/jpeg" /></output></operation></binding><!-- Bind the actual service here --><service name="IHERetrieveForDisplay"><port name="IHERetrieveForDisplayHttpGet"binding="s0:IHERetrieveForDisplayHttpGet"><http:address location="http://localhost/" /></port></service><?xml version="1.0" encoding="utf8"?><definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/">

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

9

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
365

370

375

380

385

390

395

400

<!-- Defines the types available for the parameters --><!-- May also include the return type definitions --><types><s:schema elementFormDefault="qualified"targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"><!-- Add any items that control the returned values list or type here -><!-- Add or remove items in the actual supplied WSDL to show theavailable types. --><s:simpleType name="summaryRequestType"><s:restriction base="s:string"><s:enumeration value="SUMMARY" /><s:enumeration value="SUMMARY-RADIOLOGY" /><s:enumeration value="SUMMARY-CARDIOLOGY" /><s:enumeration value="SUMMARY-LABORATORY" /><s:enumeration value="SUMMARY-SURGERY" /><s:enumeration value="SUMMARY-EMERGENCY" /><s:enumeration value="SUMMARY-DISCHARGE" /><s:enumeration value="SUMMARY-ICU" /><s:enumeration value="SUMMARY-RX" /></s:restriction></s:simpleType><s:simpleType name="listRequestType"><s:restriction base="s:string"><s:enumeration value="LIST-ALLERGIES" /><s:enumeration value="LIST-MEDS" /></s:restriction></s:simpleType><!-- Please list all content types available, and remove those notavailable. --><s:simpleType name="contentType"><s:restriction base="s:string"><s:enumeration value="text/html" /></s:restriction></s:simpleType><!-- Indicates that this item is a returned rows restriction --><s:simpleType name="ReturnedResultCount" type="s:positiveInteger" />405<!-- Please use the string "Search" as a prefix for all search
criteria, and list below --><!-- Indicates that this item is a search string --><s:simpleType name="SearchString" type="s:string" />410</s:schema></types>415<message name="RetrieveSummaryInfoHttpGetIn">

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

10

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

420<!-- Add other parameters here if they are available, using types defined
above. --><part name="requestType" type="summaryRequestType" /><part name="patientID" type="SearchString" /><part name="lowerDateTime" type="s:dateTime" /><part name="upperDateTime" type="s:dateTime" /><part name="mostRecentResults" type="ReturnedResultCount" /></message>

425

430

435

440

445

450

455

460

465

<message name="RetrieveSummaryInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that --><!-- it be used here instead of s0:string. If a complex type is allowed
as one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveListInfoHttpGetIn"><!-- Add other parameters here if they are available, using types defined
above. --><part name="requestType" type="listRequestType" /><part name="patientID" type="SearchString" /></message><message name="RetrieveListInfoHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that --><!-- it be used here instead of s0:string. If a complex type is allowed
as one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s0:string" /></message><message name="RetrieveDocumentHttpGetIn"><!-- Add other parameters here if they are available, using types defined
above. --><!-- It is recommended that one of the sub-types of SearchUID is chosen
here --><!-- Especially if SearchStudyUID is allowed, then the display client canknow that --><!-- it is permissible to use a dicom uid here --><part name="documentUID" type="SearchString" /><part name="contentType" type="contentType" /></message><message name="RetrieveDocumentHttpGetOut"><!-- If a complex type is defined for the return value, then it issuggested that -->HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

11

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
470

475

480

485

490

495

500

505

510

515

520

<!-- it be used here instead of s:string. If a complex type is allowed as
one --><!-- of the options, but an arbitrarily formatted string is also allowed,
then create --><!-- a union type here that allows either option. --><part name="Body" element="s:string" /></message><portType name="IHERetrieveForDisplayHttpGet"><operation name="RetrieveSummaryInfo"><input message="s0:RetrieveSummaryInfoHttpGetIn" /><output message="s0:RetrieveSummaryInfoHttpGetOut" /></operation><operation name="RetrieveListInfo"><input message="s0:RetrieveListInfoHttpGetIn" /><output message="s0:RetrieveListInfoHttpGetOut" /></operation><operation name="RetrieveDocument"><input message="s0:RetrieveDocumentHttpGetIn" /><output message="s0:RetrieveDocumentHttpGetOut" /></operation></portType><binding name="IHERetrieveForDisplayHttpGet"
type="s0:IHERetrieveForDisplayHttpGet"><http:binding verb="GET" /><operation name="RetrieveSummaryInfo"><http:operation location="/IHERetrieveSummaryInfo" /><input><http:urlEncoded /></input><output><mime:content type="text/html" /></output></operation><operation name="RetrieveListInfo"><http:operation location="/IHERetrieveListInfo" /><input><http:urlEncoded /></input><output><mime:content type="text/html" /></output></operation><operation name="RetrieveDocument"><http:operation location="/IHERetrieveDocument" /><input><http:urlEncoded /></input>
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

12

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

525

530

<!-- The type of the output should be restricted on a per-server basis
to the types --><!-- actually provided. --><output><mime:content type="text/html" /><mime:content type="application/x-hl7-cda-level-one+xml" /><mime:content type="application/pdf" /><mime:content type="image/jpeg" /></output></operation></binding>

535

540

<!-- Bind the actual service here --><service name="IHERetrieveForDisplay"><port name="IHERetrieveForDisplayHttpGet"binding="s0:IHERetrieveForDisplayHttpGet"><http:address location="http://localhost/" /></port></service>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

13

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

545

550

555

Appendix B:

Definition of Document Unique Ids

The Retrieve Information for Display Integration Profile in its Retrieve Persistent Documenttransaction relies on a globally unique identification of persistent objects. It is the Information
Source Actor’s responsibility, when a specific document instance is available for retrieval, toassign to this document instance a globally unique identifier, thus allowing Display Actors toretrieve the same document instance at different points in time and to obtain the same semantics
for its presented content.
This appendix describes how unique identifiers for documents shall be created. A unique
identifier may be created by the Information Source Actor or by any other system to which theinformation source is connected. The requirements specified in this appendix are derived fromthe common practices and definitions of OIDs in ISO 8824, HL7 V3 and CDA and UIDs in
DICOM. They guarantee uniqueness across multiple countries, sites, vendors and equipment.

B.1:

Requirements for Document UIDs

The UID identification scheme is based on the OSI Object Identification (numeric form) as
defined by the ISO 8824 standard.
560

All Unique Identifiers, used within the context of this transaction shall be registered values as
defined by ISO 9834-3 to ensure global uniqueness. These requirements result in the following
structure for unique Ids.

B.2:
565

570

575

Structure of a Document UID

Each Document UID is composed of two parts, an <org root> and a <suffix> separated by a“period”. Therefore: UID = <org root>.<suffix>
The <org root> portion of the UID uniquely identifies an organization, (e.g., manufacturer,
research organization, hospital, etc.), and is composed of a number of numeric components as
defined by ISO 8824. The <suffix> portion of the UID is also composed of a number of numericcomponents, and shall be unique within the scope of the <org root>. This implies that theorganization identified in the <org root> is responsible for guaranteeing <suffix> uniqueness byproviding registration policies. These policies shall guarantee <suffix> uniqueness for all UID's
created by that organization. Unlike the <org root>, which may be common for UID's in an
organization, the <suffix> shall take different unique values between different UID's that identify
different objects. The <org root> is used only for uniqueness and not for any other purpose.
Although a specific implementation may choose some particular structure for its generated UIDs,
it should never assume that a UID carries any semantics. A UID shall not be "parsed" to find aparticular value or component. Component definition (for the suffix) is implementation-specificand may change as long as uniqueness is maintained. Parsing UID's (including extracting theroot) may jeopardize the ability to inter-operate as implementations evolve.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

14

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
580

B.3:

Document UID encoding rules

The UID encoding rules are defined as follows:•

Each component of a UID is a number and shall consist of one or more digits. The first
digit of each component shall not be zero unless the component is a single digit.

Note:

585

590

•

Each component numeric value shall be encoded using the characters 0-9 of the Basic G0
Set of the International Reference Version of ISO 646:1990. This particular encoding is
the same as the UTF-8 encoding for these characters in UNICODE.

•

Components shall be separated by the character "." (2EH).

•

UIDs shall not exceed 64 total characters, including the digits of each component, andseparators between components.

B.4:

595

Registration authorities may distribute components with non-significant leading zeroes. The leading zeroes
should be ignored when being encoded (i.e., “00029” would be encoded “29”).

How to obtain a UID registration root?

Organizations that define UIDs are responsible for properly registering their UIDs (at leastobtain a registered <Org Root>) as defined for OSI Object Identifiers (ISO 9834-3). The
organization defining the UID shall accept the responsibility of ensuring its uniqueness. IHE will
not register UIDs or issue registered organization roots. There are a large number of means to
obtain free or for a reasonable fee an organization root.
A useful resource that is often used by the DICOM community lists the many ways to obtain aregistered UID Root for a small fee or even for free, anywhere in the world.

600

http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration
The manner in which the suffix of a Document UID is defined is not constrained by any IHE
Integration Profile. Only the guarantee of its uniqueness by the defining organization is required
by IHE.

B.5:
605

Example of a Document UID

This example presents a particular choice made by a specific organization in defining its suffix toguarantee uniqueness. A variant is discussed.
"1.2.840.xxxxx.4076078054086.11059664469.235212"(root)(suffix)

In this example, the root is:
610

1

Identifies ISO

2

Identifies ANSI Member Body

840

Country code of a specific Member Body (U.S. for ANSI)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

15

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
xxxxx Identifies a specific Organization (provided by ANSI)
615

620

In this example the remaining components of the suffix relate to the identification of a specificdocument instance:
4076078054086

802.3 MAC Address (004 076 078 054 086)

11059664469

Time system was booted (July 31, 2033 10:14:29)

235212

Monotonically increasing sequence number

In this example, the organization has chosen these components to guarantee uniqueness. Other
organizations may choose an entirely different series of components to uniquely identify its
documents.
Because of the flexibility allowed in creating Document UIDs, implementations should notdepend on any assumed structure of UIDs and should not attempt to parse UIDs to extract thesemantics of some of its components.

625

630

635

B.6:

Representing UUIDs as OIDs

The standards ITU X.667 and ISO 9834-8 defined a particular OID root for the UUIDs, anddefine the translation between these two formats. The top node 2.25 is assigned for all UUIDs.
This means that the UUID that can be written as urn:uuid:f81d4fae-7dec-11d0-a76500a0c91e6bf6 (using hexadecimal notation) is also
2.25.329800735698586629295641978511506172918 (using dotted decimal notation). It can also
be encoded using the ASN.1 rules in a binary form internally within X.509 Certificates and some
LDAP messages. All of these are the same OID. The reverse is not true. Not all OIDs can be
represented as UUIDs. UUIDs are a subset of the OIDs.
This relationship is one way to obtain OIDs in situations where an OID is needed. It is notnecessary to use the 2.25 root. An OID assigning authority might take advantage of the UUID
generation mechanisms to assign new OIDs within its own root domain. These OIDs would not
be UUIDs, but they would be valid OIDs.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

16

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

640

Appendix C:

HL7 Profiling Conventions

The HL7 tables included in this document have been modified from the HL7 2.5 standard
document. Such a modification is called a profile. Refer to the HL7 2.5 standard for themeanings of specific columns in the table.
645

The profiling tables in this document leverage the ongoing HL7 profile definition. To maintainthis specification at a generic level, the following differences have been introduced:•

Message specifications do not indicate the cardinality of segments within a message.

•

For fields composed of multiple components, there is no indication of the size of eachcomponent.

•

Where a table containing enumerated values is referenced from within a segment profile
table, the enumerated values table is not always present.

•

The number of times a repeating field can repeat is not indicated.

•

The conditions that would require inclusion of conditional fields are not defined when
they depend on functional characteristics of the system implementing the transaction andthey do not affect data consistency.

650

655

The following terms refer to the OPT column, which has been profiled:R

Required

R2

This is an IHE extension. If the sending application has data for the field, it isrequired to populate the field. If the value is not known, the field may not be sent.

R+

This is an IHE extension. This is a field that IHE requires that was listed as optional
within the HL7 standard.

O

Optional

C

Conditional

660

665

IHE requires that Z-segments be present in HL7 transactions only when explicitly provided forwithin the associated IHE message profile specification. According to the HL7 standard, if thevalue of a field is not present, the receiver shall not change corresponding data in its database.
However, if sender includes explicit NULL value (i.e., two double-quotes “”), it shall cause
removal of any values for that field in the receiver’s database.
Table C-1 provides a sample profile for an imaginary HL7 segment. Tables for real segments arecopied from the HL7 2.5 standard with modifications made only to the OPT column.

670
Table C-1: Sample HL7 Profile
SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

1

1

ST

R

xx001

Element 1

2

4

ST

O

xx002

Element 2

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

17

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

C.1:
675

SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

3

180

HD

R2

xx003

Element 3

4

180

HD

C

xx004

Element 4

5

180

HD

O

xx005

Element 5

6

180

HD

R+

xx006

Element 6

HL7 Message Profiling Convention

The messages used by each transaction are described in this document using static definitions as
described for HL7 constrainable message profiles; refer to HL7 Version 2.5, Chapter 2, Section
2.12.6. The static definition of each message is represented within tables. The message level
table represents the IHE-constrained message structure with its list of usable segments. The
segment level table represents the IHE-constrained content of one segment with its usable fields.
C.1.1: Static definition - Message level

680

The message table representing the static definition contains 5 columns:•

Segment: gives the segment name, and places the segment within the hierarchy of themessage structure designed by HL7, but hiding the traditional square brackets and braces
that designate optionality and repeatability in HL7 standard message tables. The
beginning and end lines of a segment group (see HL7 Version 2.5, Chapter 2, Section
2.5.2 for definition) are designated in this column by --- (3 dashes).

•

Meaning: Meaning of the segment as defined by HL7. The beginning of a segment groupis designated by one line in this column giving the segment group name in all caps,
prefixed by --- (3 dashes), and followed by the keyword “begin”. The end of a segmentgroup is designated by one line in this column giving the segment group name in all caps,
prefixed by --- (3 dashes), and followed by the keyword “end”.

•

Usage: Coded usage of the segment, in the context of this IHE Integration Profile. The
coded values used in this column are:

685

690

695

700

R: Required: A compliant sending application shall populate all "R" elements with a
non-empty value. A compliant receiving application may ignore the information
conveyed by required elements. A compliant receiving application shall not raise anerror due to the presence of a required element, but may raise an error due to theabsence of a required element.
RE: Required but may be empty. The element may be missing from the message, butshall be sent by the sending application if there is relevant data. A conformant
sending application shall be capable of providing all "RE" elements. If theconformant sending application knows a value for the element, then it shall send thatvalue. If the conformant sending application does not know a value, then thatelement may be omitted.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

18

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Receiving applications may ignore data contained in the element, but shall be able tosuccessfully process the message if the element is omitted (no error message shouldbe generated if the element is missing).

705

O: Optional. The usage for this field within the message is not defined . The sending
application may choose to populate the field; the receiving application may choose toignore the field.
710

C: Conditional. This usage has an associated condition predicate. (See HL7 Version 2.5,
Chapter 2, Section 2.12.6.6, "Condition Predicate".)If the predicate is satisfied: A compliant sending application shall populate theelement. A compliant receiving application may ignore data in the element. It may
raise an error if the element is not present.
If the predicate is NOT satisfied: A compliant sending application shall NOT
populate the element. A compliant receiving application shall NOT raise an error if
the condition predicate is false and the element is not present, though it may raise anerror if the element IS present.

715

CE: Conditional but may be empty. This usage has an associated condition predicate.
(See HL7 Version 2.5, Chapter 2, Section 2.12.6.6, "Condition Predicate".)If the predicate is satisfied: If the conforming sending application knows the required
values for the element, then the application must populate the element. If theconforming sending application does not know the values required for this element,
then the element shall be omitted. The conforming sending application must be
capable of populating the element (when the predicate is true) for all ‘CE’ elements.
If the element is present, the conformant receiving application may ignore the valuesof that element. If the element is not present, the conformant receiving application
shall not raise an error due to the presence or absence of the element.
If the predicate is NOT satisfied: The conformant sending application shall not
populate the element. The conformant receiving application may raise an application
error if the element is present.

720

725

730

X: Not supported. For conformant sending applications, the element will not be sent.
Conformant receiving applications may ignore the element if it is sent, or may raise
an application error.
735•

Cardinality: Within square brackets, minimum and maximum number of occurrences
authorized for this segment in the context of this Integration Profile.

•

HL7 chapter: Reference of the HL7 v2.5 chapter that describes this segment.

C.1.2: Static definition – Segment level and Data Type level
The Segment Table and the Data Type Table each contain 8 columns:
740•

SEQ: Position (sequence) of the field within the segment.

•

LEN: Maximum length of the field

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

19

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

745•

DT: Field Data Type•

Usage: Usage of the field within this IHE Integration Profile. Same coded values as in themessage level: R, RE, C, CE, O, X.

•

Cardinality: Minimum and maximum number of occurrences for the field in the context
of this Integration Profile.

•

TBL#: Table reference (for fields using a set of defined values)•

ITEM#: HL7 unique reference for this field•Element Name: Name of the field in a Segment table. / Component Name: Name of a
subfield in a Data Type table.

750

Table C1.2-1: Example: The MSH segment description
SEQ

LE
N

DT

Usage

Card.

TBL
#

1

1

ST

R

[1..1]

00001

Field Separator

2

4

ST

R

[1..1]

00002

Encoding characters

3

227

HD

R

[1..1]

00003

Sending Application

0361

ITEM#

Element name

…

C.2:
755

HL7 Implementation Notes

C.2.1: Network Guidelines
The HL7 2.5 standard does not define a network communications protocol. Beginning with HL7
2.2 , the definitions of lower layer protocols were moved to the Implementation Guide, but are
not HL7 requirements. The IHE Framework makes these recommendations:

760

765

1. Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the
HL7 Implementation Guide.
2. An initiating application that wants to send a message (initiate a transaction) will initiate
a network connection to start the transaction. The receiver application will respond withan acknowledgement or response to query over the open connection. The initiating
application can initiate a new transaction on the same connection. However, the initiating
application must be able to handle cases where the connection has been closed due topossible timeout by the accepting application. For example if the initiating application
does not submit a request over the connection in a timely manner, the accepting
application has the right to close the connection. When this condition is detected, theinitiating application needs to open a new connection for subsequent requests.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

20

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
770

C.2.2: Message Control
According to the HL7 standard, each message shall begin with the MSH (message header)segment. Table C.2.2-1 identifies all required fields in this message. This table shall beinterpreted according to the HL7 Standard unless otherwise noted in ITI TF-2x: Appendix C.

775

Table C.2.2-1: IHE Profile - MSH segment
SEQ

LEN

DT

OPT

TBL#

ITEM #

Element Name

1

1

ST

R

00001

Field Separator

2

4

ST

R

00002

Encoding Characters

3

180

HD

R+

00003

Sending Application

4

180

HD

R+

00004

Sending Facility

5

180

HD

R+

00005

Receiving Application

6

180

HD

R+

00006

Receiving Facility

7

26

TS

R

00007

Date/Time Of Message

8

40

ST

O

00008

Security

9

13

CM

R

00009

Message Type

10

20

ST

R

00010

Message Control ID

11

3

PT

R

00011

Processing ID

12

60

VID

R

00012

Version ID

13

15

NM

O

00013

Sequence Number

14

180

ST

O

00014

Continuation Pointer

15

2

ID

O

0155

00015

Accept Acknowledgment Type

16

2

ID

O

0155

00016

Application Acknowledgment
Type

17

3

ID

O

0399

00017

Country Code

18

16

ID

C

0211

00692

Character Set

19

250

CE

O

00693

Principal Language Of
Message

20

20

ID

O

01317

Alternate Character Set
Handling Scheme

21

427

EI

O

01598

Message Profile Identifier #0076/ 0003

0104

0356

Adapted from the HL7 Standard, version 2.5 and version 2.3.1# Note: This element is only applicable in HL7 version 2.5 and later, and thus is only applicable for those transactions
based on HL7 v2.5 and later.

780

The IHE IT Infrastructure Technical Framework requires that applications support HL7recommended values for the fields MSH-1-Field Separator and MSH-2-Encoding Characters.
Field MSH-18-Character Set shall only be valued if the message utilizes character sets other thanISO IR-6, also known as ASCII.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

21

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

785

Implementations supporting sequence number protocol (and using the field MSH-13-Sequence
Number) shall be configurable to allow them to perform transactions without such protocol.

790

In messages conforming to an IHE Transaction using HL7 v2.5 and later, it is recommended thatfield MSH-21-Message Profile Identifier contain one field repetition with a value representing
the IHE transaction identifier, in the form “<domain>-<transaction number>^IHE” (e.g., “ITI10^IHE”). Other field repetitions may be present with global (HL7-registered), vendor specific,
and/or realm specific message profile IDs.
C.2.3: Acknowledgment Modes
IHE supports both Acknowledgement Modes specified in HL7 standard v2.5 (see HL7 Standard,
Section 2.9 “Message Processing Rules”): Original Acknowledgement Mode and Enhanced
Acknowledgement Mode.

795

An IHE transaction which uses HL7 messages will explicitly include the requirement forenhanced mode if used. If no such statement is specified, the transaction shall use only original
mode.

800

This section specifies the common structure of the Application Level Acknowledgement
Message in the Original Mode (called Application ACK Message for short), and the Commit
Acknowledgement Message in the Enhanced Mode (called Commit ACK Message for short).

805

The Application Level Acknowledgement Message in the Enhanced Mode contains theapplication-specific content, and shall be explicitly specified in the corresponding transaction
which requires it. A transaction can, however, refer to the Application ACK Message specified
in this section as its Application Level Acknowledgement Message in the enhanced mode if it issuitable.
Table C.2.3-1: Common ACK static definition:
Segment

810

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

MSA

Message AcknowledgementR[1..1]

2

ERR

Error

C

[0..*]

2

In the original mode, the ACK message conveys application errors (if any) detailed by thereceiving application.
The receiving application shall reject an incoming message, if it does not recognize either themessage type (MSH-9.1) or the trigger event (MSH-9.2).
In the Application ACK message, this is an application-rejection, and field MSA-1 of theacknowledgement shall contain the value AR.

815

In the Commit ACK message, this is a commit-rejection, and Field MSA-1 of theacknowledgement shall contain the value CR.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

22

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
The components of Field ERR-2 of the acknowledgement shall be populated as follows.

820

ERR-2.1:

MSH

ERR-2.2:

1

ERR-2.3:

9

ERR-2.4:

1

ERR-2.5:

1

if an unrecognized message type2

if an unrecognized trigger event

The components of Field ERR-3 of the acknowledgement shall be populated as follows.
825

ERR-3.1:
ERR-3.2:

200

if an unrecognized message type201

if an unrecognized trigger event

Unsupported message type or
Unsupported trigger event as appropriate

ERR-3.3:
830

HL70357

Details of field encoding of these segments are discussed in the following sections.
C.2.3.1:

MSA - Message Acknowledgement segment

Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)
This segment contains information sent while acknowledging another message.
835

Table C.2.3.1-1: MSA - Message Acknowledgement
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

0008

00018

Acknowledgement code

1

2

ID

R

[1..1]

2

20

ST

R

[1..1]

00010

Message Control Id

3

80

ST

X

[0..0]

00020

Text Message

4

15

NM

O

[0..1]

00021

Expected Sequence Number

X[0..0]

00022

Delayed Acknowledgment TypeX

[0..0]

00023

Error Condition

5
6

250

CE

0357

MSA-1 Acknowledgment Code (ID), required.

840

As is the case throughout IHE, original mode acknowledgement is in use. IHE ITI authorizes twovalue sets of the acknowledgement codes, both taken from HL7 Table 0008 - Acknowledgement
code for the Application and Commit ACK messages, respectively.
In the original mode, the Application ACK message shall use one of the following three codes topopulate Field MSA-1:
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

23

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Table C.2.3.1-2: HL7 Table 0008 - Acknowledgement codes in Application ACK message
Value

845

Description

CommentAA

Original mode:
Application Accept

The message has been accepted and integrated by the receiving
application

AE

Original mode:
Application Error

The message contains errors. It SHALL not be sent again without
correcting the error.

AR

Original mode:
Application Reject

The message has been rejected by the receiving application. If therejection is not related to an invalid value in the MSH segment, thesender may try again to send the message later.

In the enhanced mode, the Commit ACK message shall use one of the following three codes topopulate Field MSA-1:
Table C.2.3.1-3: HL7 Table 0008 - Acknowledgement codes in Commit ACK message
Value

Description

Comment

CA

Enhanced mode:Commit Accept

The message has been received and safe-kept in the receiving
application for processing. No resend is required.

CE

Enhanced mode:Commit Error

The message contains errors. It SHALL not be sent again without
correcting the error.

CR

Enhanced mode:Commit Reject

The message has been rejected by the receiving application. If therejection is not related to an invalid value in the MSH segment, thesender may try again to send the message later.

MSA-2 Message Control ID (ST), required.
850

Definition: This field contains the message control ID from Field MSH-10-Message Control IDof the incoming message for which the acknowledgement is sent.
MSA-3 Text Message (ST), not supported. See the ERR segment.
MSA-6 Error Condition (CE), not supported. See the ERR segment.
C.2.3.2:

855

ERR - Error segment

Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)
This segment is used to add error comments to acknowledgment messages.
Table C.2.3.2-1: ERR – Error segment
SEQ

LEN

DT

Usage

Card.

TBL#

1

493

ELD

X

[0..0]

2

18

ERL

RE

[0..*]

3

705

CWE

R

[1..1]

0357

4

2

ID

R

[1..1]

5

705

CWE

O

[0..1]ITEM#

Element name00024

Error Code and Location

01812

Error Location

01813

HL7 Error Code

0516

01814

Severity

0533

01815

Application Error Code

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

24

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

860

865

SEQ

LEN

DT

Usage

Card.

6

80

ST

O

7

2048

TX

8

250

9

20

10

TBL#

ITEM#

Element name[0..10]01816

Application Error ParameterO[0..1]

01817

Diagnostic Information

TX

O[0..1]

01818

User Message

ISO[0..*]

0517

01819

Inform Person Indicator

705

CWE

O

[0..1]

0518

01820

Override Type

11

705

CWE

O

[0..*]

0519

12

652

XTN

O

[0..*]

01821

Override Reason Code01822

Help Desk Contact Point

ERR-1 is deprecated in HL7 Version 2.5 (i.e., retained for backward compatibility only) andtherefore not supported by IHE.
ERR-2 is populated except when the error is not within an HL7 field, component or
subcomponent. For example, if the receiver returns an acknowledgement containing MSA-2acknowledgement code value AR or CR to indicate that the receiving application was
unavailable, ERR-2 is not populated.
ERR-3 HL7 Error Code (CWE) is required. It identifies the HL7 (communication) error code.
Valid values are given by HL7 Table 0357:
HL7 Table 0357: Message error condition codes
Value

Description

Comment

0

Message accepted

Success. Optional, as the AA conveys success. Used for systems thatmust always return a status code.

100

Segment sequence error

Error: The message segments were not in the proper order, or required
segments are missing.

101

Required field missing

Error: A required field is missing from a segment

102

Data type error

Error: The field contained data of the wrong data type, e.g., an NM fieldcontained "FOO".

103

Table value not foundError: A field of data type ID or IS was compared against thecorresponding table, and no match was found.

200

Unsupported message
type

Rejection: The Message Type is not supported.

201

Unsupported event code

Rejection: The Event Code is not supported.

202

Unsupported processing
id

Rejection: The Processing ID is not supported.

203

Unsupported version id

Rejection: The Version ID is not supported.

204

Unknown key identifier

Rejection: The ID of the patient, order, etc., was not found. Used fortransactions other than additions, e.g., transfer of a non-existent patient.

205

Duplicate key identifier

Rejection: The ID of the patient, order, etc., already exists. Used in
response to addition transactions (Admit, New Order, etc.).

206

Application record locked

Rejection: The transaction could not be performed at the application
storage level, e.g., database locked.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

25

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Value
207

Description

Comment

Application internal error

Rejection: A catchall for internal errors not explicitly covered by othercodes.

870
ERR-4 Severity (ID) is required. It identifies the severity of an application error. Valid values
are given by HL7 Table 0516:
HL7 Table 0516: Error severity
Value

875

Description

CommentW

Warning

Transaction successful, but there may be issues

I

Information

Transaction was successful but includes information, e.g., informpatient

E

Error

Transaction was unsuccessful

C.2.4: Common Segment Definitions
The following table specifies the contents of the EVN segment that is common to several HL7based transaction messages defined in ITI TF-2a and 2b.
Table C.2.4-1: IHE Profile - EVN segment
SEQ

LEN

DT

OPT

TBL#

1

3

ID

O

2

26

TS

R

3

26

TS

O

4

3

IS

O

0062

5

60

XCN

O

0188

6

26

TS

7

180

HD

880

0003

ITEM#

ELEMENT NAME

00099

Event Type Code

00100

Recorded Date/Time

00101

Date/Time Planned Event

00102

Event Reason Code00103

Operator ID

R2

01278

Event Occurred

O

01534

Event Facility #Adapted from the HL7 Standard, version 2.5 and version 2.3.1# Note: This element is only applicable in HL7 version 2.5 and thus is only applicable for those transactions based on HL7
v2.5

Field EVN-1-Event Type Code is optional; however, if present, its value shall be equal to thesecond component of the field MSH-9-Message Type.
885

C.2.5: Message granularity

890

The sending application shall send as many messages as there are events recorded. For instance,
if at the same time there is a change both to the patient’s location (from emergency room to GI
surgery ward) and to the patient’s attending doctor (from Dr. Eric Emergency to Dr. John
Appendectomy), the sending application will transmit two movements using HL7 messages
ADT^A02 (transfer) and ADT^A54 (change attending doctor). Both events will have the same
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

26

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
effective date/time (EVN-6 – Event Occurred). If the Historic Movement Option is in use, eachof these movements will have a unique identifier.
The exceptions to this fine granularity are:•

The Admit Inpatient (A01) and Register Outpatient (A04) events can also assign alocation and an attending doctor to the patient, known when the event is recorded.

•

A change of patient class (A06 or A07) also assigns at the same time a new location to
the patient.

•

The Cancel Discharge/End Visit event also includes at the same time the patient location
after the cancellation has been processed.

895

900

C.2.6: HL7 empty field convention

905

According to the HL7 standard, if the value of a field is not present, the receiver shall not change
corresponding data in its database. However, if the sender defines the field value to be theexplicit NULL value (i.e., two double quotes ""), it shall cause removal of any values for thatfield in the receiver's database. This convention is fully applied by IHE profiles based on HL7v2.x messages.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

27

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix D:
910

915

920

925

930

Cross-Profile Interactions of PIX and PSA

When the Context Manager Actor in a Patient Synchronized Application Integration Profile isgrouped with a Patient Identifier Cross-reference Consumer in a Patient Identifier Crossreferencing Integration Profile, patient identifiers must be accessible to both actors in aconsistent manner. This Appendix provides the necessary mapping rules.
The Patient Identifier Cross-Referencing (PIX) Integration Profile defines a general-purpose
mapping of a Patient ID within a Patient Identification Domain to aliases in other Patient
Identification Domains. This mapping is intended to be used across all IHE systems that requirepatient identification in transactions crossing Patient Identification Domains. The PIX
Integration Profile relies on HL7 V2 Transactions.
The Patient Synchronized Application Integration Profile relies on HL7 CCOW which,confronted with a similar need, has defined a Patient Mapping API within its architecture. The
HTTP Technology mapping for the CCOW Patient Mapping Agent API supports its operation
over a network interface, thus creating an alternative to HL7 V2 messages.
As IHE strives to avoid the inclusion in its integration profiles of incompatible but functionallyequivalent variants, it has decided to use HL7 V2 ADT messages for the Patient Identifier Crossreferencing Integration Profiles. In consequence, the combined use of the Patient Synchronized(CCOW based) Integration Profile and of the Patient Identifier Cross-referencing Integration
profiles requires that the IHE Context Manager Actor uses the services of the PIX Integration
Profile. To do so, the Patient Identifier Cross-reference Consumer Actor in communication with
the Patient Identifier Cross-reference Manager Actor operates as a substitute for the CCOW
Patient Mapping Agent. This is shown in Figure D-1 below as a dashed oval surrounding thePatient Cross-reference Manager and the Patient Identifier Cross-reference Consumer actors. As
a result it is likely that a context management solution would bundle a PMA proxy applicationthat would implement the PIX Query in support of the Patient Identifier Cross-reference
Consumer Actor.
Patient Mapping
Product
Grouping

Patient
ID Consumer

PIX Query

Patient CrossRef Manager

Join Context

Context
Participant

Change Context
Follow Context
Leave Context

Context
Manager

PMA

CCOW Context

935
Figure D-1: Actor Grouping Diagram
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

28

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

940

945

950

This Appendix provides the definition of the mapping of the CCOW Patient Mapping Agent API
methods onto the PIX Query Transaction (HL7 V2 QBP^Q23/RSP^K23) as defined by the PIX
Integration Profile.
Figure D-1 shows the definition of the Patient Mapping Methods parameters as implemented in
Web technology. Most of these Arguments relate to the normal operations of the Patient
Mapping Agent methods that pose no mapping challenge except for the ItemNames and
ItemValues which pose some constraints. The first constraint comes from the translation ofPatient Identity Domains for both query and response from and to a CCOW defined name / value
pair. The second one comes from the fact that CCOW participant applications can set more than
one identifier in context the ability to detect when these identifiers represent the identities ofmore than one patient. IHE has taken steps to mitigate these issues by further restricting how the
IHE Context Participant implements the methods. Each of these constraints is addressed in
sections below.
Table D-1: ContextChangesPending
HTTP Request Message
Argument
Name

Data
Type

Comment

Interfacestring“ContextAgent”

Methodstring“ContextChangesPending”

agentCoupon

long

“-1”

contextManager

string

URL for the Context Manager that is requesting the patient id cross-reference

itemNames

string[]One or more item names (e.g., Patient.Id.IdList)

itemValues

string[]

The patient identifiers corresponding to the domains identified in item names

contextCoupon

longContext Coupon value for pending context change transaction

managerSignaturestring

Not required
HTTP Reply Message

agentCoupon

long

“-1”

itemNames

string[]See below for valid item names for patient subject

itemValues

string[]See below for any constraints on item values

contextCoupon

long

Return the value provided in request

agentSignaturestring

Not required

Decisionstring“valid” or “invalid”

ReasonstringReason text if mapping is invalid

Adapted from the HL7 Context Management “CCOW” Standard, version 1.4

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

29

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
955

D.1:

Namespace Translation from PIX Query to CCOWThe CCOW standard defines multiple identifier items that may be set into the context by an
instigating participant application. The current list of valid identifier names are listed in Table D2.
Table D-2: Patient Subject Identifiers
Patient Subject Identifier
Item Name

HL7 Meaning

HL7
Data
Type

HL7 Semantic Constraints on
ValuesCase
Sensitive

Patient.Id.MRN.Suffix

Patient medical
record number,per PID-2

ST

HL7 Table 0203
Identifier Type = MR

No

Patient.Id.MPI

Patient
identifier in the“Master Patient
Index”, per
PID-2

ST

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

Patient.Id.NationalIdNumber

Patient national
identifier
number, per
PID-2

ST

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

No

Patient.Id.IdList

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

CX

May be a repeating set of CX item
values (per Section 1.7 of the HL7
Context Management “CCOW”
Standard: Subject Data Definitions
document), each of which contains an
identifier that denotes the same patient

No

960

Adapted from the HL7 Context Management “CCOW” Standard, version 1.4
IHE has specified in the Context Change Transaction as documented in ITI TF-2a that theContext Participant Actor shall use the Patient.Id.IdList item. The intent is to eliminatetranslation as the Patient.Id.IdList value maps directly to PIX Query Transaction QPD-3.

965

Applications using in their identifier items Patient.Id.MRN.Suffix will need to migrate to thePatient.Id.IdList item as expected by the HL7 CCOW standard.

D.2:

970

Processing Multiple Identifiers

CCOW participant applications are permitted to populate as many patient identifiers as they haveavailable to them. This means that when a user selects a patient in one of these applications thecontext is populated with multiple identifiers for the selected patient. When the CCOW Patient
Mapping Agent (PMA) accepts multiple patient identifiers as input, the PMA has the
responsibility of invalidating patient mapping and causing the context change transaction to becancelled if it determines that the multiple identifiers supplied as part of the transaction identify
more than one patient.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

30

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
975

980

985

The QPD segment as defined in the IHE PIX Query Transaction specifies a single identifier
uniquely identifying one patient within a given Patient Identification Domain. In the case wheremultiple identifiers are populated, the context manager may have to process the response to theinitial PIX Query Transaction to evaluate if the other identifiers in context are included. If so, nofurther processing is required. Otherwise, an additional PIX Query will need to be issued and theresults processed. Should a non-null result be returned, indicating the identifier uniquely
identifies a different patient for the given domain, the context manager shall assume “invalid” inthe decision field and “multiple patients identified” in the reason field.
In order to mitigate this condition, IHE specifies that all context participants supporting thePatient Synchronized Applications Profile shall only set one identifier for the patient when a
Patient Identifier Cross-referencing Integration Profile is used by the context manager. Thismeans that the context participant for those applications that manage multiple patient identifiers
will need to be configurable as to which identifier item is passed in the Change Context
Transaction.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

31

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

990

Appendix E:
List

Usage of the CX Data Type in PID-3-Patient Identifier

995

The Health Level Seven Standard (HL7) uses data type CX to express various identifiers,
including the Patient ID in the third field of the PID segment. We discuss here how IHE IT
Infrastructure expects the CX data type to be populated in the PID-3-Patient Identifier List fieldsof messages that it defines.

1000

Requirements for populating the elements of PID-3-Patient Identifier List vary slightly,
depending on what actor is originating the transaction in which the PID segment is sent. If thePatient Identifier Cross-reference Manager is the source of the PID segment, the requirements(specifically, with respect to populating the Assigning Authority subcomponents) are more
rigorous than otherwise.
PID-3-Patient Identifier List permits multiple occurrences of the CX data type. Data type CX
contains 8 components as shown below. This structure allows expression of the value andcontext for each identifier that the system knows.

1005

Table E-1: Components of HL7 Data Type CX
Cmp

Len

DT

Opt

1

15

Tbl

Name

ST

R

ID

2

ST

O

Check digit

3

ID

O

HD

R

5

ID

O

6

HD

O

Assigning facility

7

DT

O

Effective date

8

DT

O

Expiration date

4

227

0061

Code identifying the check digit scheme employed
Assigning authority

0203

Identifier type code

Adapted from the HL7 Standard, Version 2.5

1010

Each occurrence of PID-3-Patient Identifier List contains, at a minimum, an identifier value in
Component 1 and an assigning authority in Component 4. The assigning authority
unambiguously provides the context for the identifier. It is also common practice to provide an
identifier type code in Component 5, but this is not required by IHE in the context of the PIX
transactions ITI-8, ITI-9, and ITI-10. Other components are optional and will not be discussed
here; implementers may refer to HL7 Version 2.5 for more information.
Component 1 of Data Type CX, ID, is of data type ST. This data type allows a free text value ofup to 15 characters.1
1
As implemented in HL7 Version 2.5. Prior to Version 2.5, HL7 did not specify the length of individualcomponents. Although the profiles in IHE-ITI are based Versions 2.3.1 and 2.4 of HL7, they use the component
length constraints provided by Version 2.5 to support forward compatibility.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

32

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1015

Component 4 of Data Type CX, Assigning Authority, is of data type HD. This data typecontains 3 components that, when implemented at the component level, become subcomponentsof Component 4. The requirements for the subcomponents of Component 4 vary by actor.

E.1:
1020

1025

Patient Identifier Cross-reference Manager Actor Requirements

The Patient Identifier Cross-reference Manager Actor is expected to have access to complete
internal and external identifier information for the Assigning Authority of the patient identifier.
To facilitate interoperability, it is required that the Patient Identifier Cross-reference Manager
Actor populate all subcomponents of the Assigning Authority component. The usage of these
subcomponents will be explained in the examples below.
This requirement applies to the response portion of Transaction ITI-9 (PIX Query) and toTransaction ITI-10 (PIX Update Notification).
Table E-2: Usage of HL7 Data Type CX by the PIX Manager Actor
Cmp

Sbc

Len

DT

Opt

15

ST

R

ID

2

ST

O

Check digit

3

ID

O

227

HD

R

1

4

1030

Tbl

0061

Name

Code identifying thecheck digit scheme
employed
Assigning authority

0363

Conditionality predicate

4

1

20

IS

R

4

2

199

ST

R

4

3

6

ID

R

0301

Universal ID type

5

ID

O

0203

Identifier type code

6

HD

O

Subcomponent 1 must refer to thesame entity as Subcomponents 2 and3.

Namespace ID
Universal ID

Assigning facility

6

1

IS

O

0300

6

2

ST

C

6

3

ID

C

7

DT

O

Effective date

8

DT

O

Expiration date

0301

If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID
Universal ID

Populated if, and only if,
Subcomponent 3 is populated.

Universal ID type

Populated if, and only if,
Subcomponent 2 is populated

IHE specifies that the Patient Identifier Cross-reference Manager Actor must populate all 3
subcomponents of Component 4. The following rules apply:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

33

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1035

Subcomponent 1 of Component 4, Namespace ID, is of data type IS. HL7 specifies that whenvalued in the Patient ID field, the value in this subcomponent be a code taken from user-defined
Table 0363, Assigning Authority. Version 2.5 of HL7 provides suggested values for assigningauthorities in various local jurisdictions, such as USSSA for U.S. Social Security Administration.
Sites may add values to this table, but for interoperability must ensure that added values (andmeanings) are agreed upon by all communicating systems.
Subcomponent 2 of Component 4, Universal ID, is of data type ST. This subcomponent contains
a value from either a known external domain or a specified internal domain. The domain is given
in Subcomponent 3.

1040

Subcomponent 3, Universal ID Type, is of data type ID. This subcomponent contains a codetaken from HL7 Table 0301, Universal ID Type. Table 0301 contains values for various known
external identifier domains such as DNS (Internet dotted name) and ISO (International Standards
Organization Object Identifier, or OID), as well as the values L, M, and N to permit the use ofinternal identifier domains.

1045

Subcomponent 1 must refer to the same entity as Subcomponents 2 and 3.
E.1.1: Other actor requirements
The PID segment may also appear in messages generated by other IHE Actors, including thePatient ID Cross-reference Consumer and the Information Source. These actors must also
populate the Assigning Authority.

1050

1055

However, IHE specifies that they need not populate all three subcomponents of Assigning
Authority. They must populate either Namespace ID (an entry from a user-defined table), or
Universal ID and Universal ID Type (allowing the use of an externally defined identifier
scheme).
This requirement applies to Transaction ITI-8 (Patient Identity Feed) and to the query portion ofTransaction ITI-9 (PIX Query). This requirement does not apply to the response portion of ITI-9
and to ITI-10.
Table E-3: Usage of HL7 Data Type CX by other IHE Actors
Cmp

Sbc

1

Len

DT

Opt

15

Tbl

Name

ST

R

ID

2

ST

O

Check digit

3

ID

O

227

HD

R

4

4

1

20

IS

C

4

2

199

ST

C

0061

0363

Conditionality predicate

Code identifying thecheck digit scheme
employed
Assigning authority

If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID

Must be populated if Subcomponents 2
and 3 are not populated.

Universal ID

Must be populated if Subcomponent 1

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

34

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1060

Cmp

Sbc

Len

DT

Opt

Tbl

Name

4

3

6

ID

C

0301

Universal ID type

5

ID

O

0203

Identifier type code

6

HD

O

Assigning facility

6

1

IS

O

6

2

ST

C

0300

6

3

ID

C

7

DT

O

Effective date

8

DT

O

Expiration date

0301

Conditionality predicate
is not populated.
Populated if, and only if,
Subcomponent 3 is populated.
Must be populated if Subcomponent 1
is not populated.
Populated if, and only if,
Subcomponent 2 is populated.
If all three subcomponents are
populated, they must refer to the same
entity.

Namespace ID
Universal ID

Populated if, and only if,
Subcomponent 3 is populated.

Universal ID type

Populated if, and only if,
Subcomponent 2 is populated.

The definitions of the subcomponents of Component 4 are as given above for the Patient
Identifier Cross-reference Manager Actor. If all three subcomponents are defined, Subcomponent
1 must refer to the same entity as Subcomponents 2 and 3.
E.1.2: Examples of use

1065

Metropolitan Medical Center treats a patient, Jane Smith, for whom 3 identifiers are known. (Forthis example, assume that the HL7 V2 default delimiters are in use: | for field separator, ^ forcomponent separator, ~ for repetition separator and & for subcomponent separator.)
E.1.3: Data sent by source systems
The source systems provide data to the Patient Identifier Cross-reference Manager. These data
are sent either in a Patient Identity Feed transaction [ITI-8] or in response to a PIX Query.

1070

Patient Smith’s Social Security number is 999-99-4452. This number is assigned by the U.S.
Social Security Administration.
The ADT system sends the Social Security number at registration, in an occurrence of
PID-3-Patient Identifier List that looks like this:999-99-4452^^^USSSA

1075

Note that only Subcomponent 1 of Assigning Authority is assigned here, while
Subcomponents 2 and 3 are left empty.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

35

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Patient Smith’s medical record number is 9990-99497. This number is assigned by Metropolitan
Medical Center, for which no external identifier is known. Metropolitan Medical Center
incorporates the Namespace ID 99MMC for the medical record numbers it assigns.
1080

The ADT system sends the medical record number at registration, in an occurrence of
PID-3-Patient Identifier List that looks like this:999099497^^^99MMC
Note again that only Subcomponent 1 of Assigning Authority is assigned here.

1085

Patient Smith’s medical insurance number is 99998410. This number is assigned by MLH Life &Casualty Company, whose Internet domain name is www.mlhlifecasualty.com.2
The billing system sends the medical insurance number in an occurrence of PID-3Patient Identifier List that looks like this:99998410^^^&www.mlhlife.com&DNS
Note that only Subcomponents 2 and 3 of Assigning Authority are assigned here.
Also note the value DNS in the third subcomponent of Component 4 to indicate an
Internet domain name.

1090

E.1.4: Data sent by the Patient Identifier Cross-reference Manager

1095

The Patient Identifier Cross-reference Manager implements HL7 Table 0363, Assigning
Authority, by incorporating the values in HL7 Version 2.5 as well as the values 99MMC for
Metropolitan Medical Center and 99MLHLIFE for MLH Life & Casualty.3 It also includes aknown ISO Object Identifier for the Social Security Administration, 1.2.mm.nnnnn.555.6666.4
To send the identifiers in PID-3-Patient Identifier List, the Patient Identifier Cross-referenceManager builds and concatenates them as follows.

1100

In the first occurrence, the Social Security number is sent in the first component, as well as the
known internal and external values for SSN assigning authority in the fourth component.
Note the value ISO in the third subcomponent of Component 4 to indicate an ISO Object
Identifier.
999-99-4452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO

1105

2
Implementers should take into account the possibility that, as with any domain identifier, Internet domain
identifiers – either fully qualified domain names (FQDNs) or IPv4 or IPv6 addresses – are liable to change.
3
The use of 99 to preface these codes is not mandated by HL7, but reflects the practice directed by Chapter
7 of HL7 Version 2.5 for specifying local coding system values.
4This OID is fictitious. The real OID for the SSA should be substituted here.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

36

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________In the second occurrence, the medical insurance number is sent in the first component, as well as
the known internal and external values for insurance number assigning authority in the fourthcomponent.
99998410^^^99MLHLIFE&www.mlhlife.com&DNS
1110

1115

In the third occurrence, the medical record number is sent in the first component, as well as the
known internal and external values for MRN assigning authority in the fourth component.
Note that no external value is known for MRN assigning authority, so the HIS repeats theinternal value as an external value and uses the value L in the third subcomponent of
Component 4 to indicate a locally assigned value.
999099497^^^99MMC&99MMC&L
In sending all values in a PIX Update Notification transaction [ITI-10], the Patient Identifier
Cross-reference Manager concatenates the three PID-3-Patient Identifier List values using therepetition separator:

1120|999994452^^^USSSA&1.2.mm.nnnnn.555.6666&ISO~99998410^^^99A
BCLIFE&www.abclife.com&DNS~999099497^^^99MMC&99MMC&|

E.2: HL7 V3 II Data Type

1130

The Health Level Seven Standard Version 3 (HL7 V3) uses data type II to express an identifierthat uniquely identifies a thing or object (see HL7 Version 3 Standard Data Types), including
medical record number or other patient identifiers. We discuss here how IHE IT Infrastructure
profiles the use of II data type to express patient identifiers in HL7 V3 messages and HL7 V3
CDA Document Templates defined or referenced in this Technical Framework. In the following
text of this section, all requirements for the II data type are specified solely in the context ofpatient identifier expression.

1135

Since IHE adds additional constraints to the II data type, requirements for populating its
elements vary slightly, depending on what actor is originating a transaction (or create a CDA
document), in which Patient ID is expressed. If the Patient Identifier Cross-reference Manager isthe source of the Patient ID in a message, the requirements (specifically, with respect topopulating the assigningAuthorityName elements) are more rigorous than otherwise.

1125

1140

The IHE IT Infrastructure Technical Framework adds constraints to the II data type for Patient
ID expression in HL7 V3 messages or CDA documents, in order to maintain compatibility withthe explicit relationship between a Patient ID Domain (assigning authority) and a Patient ID
issued in the Domain present in the HL7 V2 CX data type. In HL7 V2 messages defined in the
IHE IT Infrastructure Technical Framework, Patient ID is expressed in the form of an identifier
value (CX.ID) issued in a domain (CX.AssigningAuthority) (see ITI TF-2x: E.1). Even though
HL7 V3 provides additional mechanisms for an explicit expression of the key concept of Patient
ID Domain (via scoping organizations), the constraints added to the II data type in this section
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

37

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1145

enable a seamless interoperability among HL7 V2 messages, HL7 V3 messages, as well as CDA
documents, which may participate in the same IHE IT Infrastructure Integration Profile.
At the same time, it is also important to represent the RIM-based association between assigningauthority and patient identifiers, which is expected by systems using the rich semantics of the
RIM. In order to achieve that IHE imposes several constraints regarding patient IDs on the HL7
V3 models used in IHE transactions:

1150

1155

1. Identifiers for the patient are class attributes of a specific role, and never of the Personclass of the patient.
2. When the Patient role is scoped by a Provider organization, only patient IDs assigned by
the provider organization are allowed in the Patient class, the root element of the patient
IDs shall match the root element of the provider organization ID, and the provider
organization ID shall have no extension element.
3. When any other role associated with the Person class of the patient is scoped by anorganization, the root element of the role IDs shall match the root element of the scoping
organization ID, and the scoping organization ID shall have no extension element.

1160

4. A receiver of an HL7 v3 message shall consider the IDs in all roles associated with the
Person class of the patient as valid patient IDs.
5. A receiver of an HL7 v3 message shall not be required to maintain the various roles
associated with the Person class of the patient, as long as, when becoming a sender, it canappropriately send all relevant patient IDs according to the requirements of a particulartransaction.

1165

E.2.1: Patient Identifier Cross-reference Manager requirements

1170

The Patient Identifier Cross-reference Manager is expected to have access to complete
information for a Patient ID value and its issuing Patient ID Domain (assigning authority). To
facilitate interoperability, it is required that the Patient Identifier Cross-reference Manager
provide all this information in an instance of II the data type to express Patient ID. Table E-2.1-1
specifies the requirements of the II data type to the Patient Identifier Cross-reference Manager.
Table E.2.1-1: Usage of HL7 V3 II Data Type by the PIX Manager
Type

Opt

Name

Root

Name

OID

R

An ISO OID of the Patient ID Domain (assigningauthority) that guarantees the global uniqueness ofthe patient identifier.

Extension

STR+

A character string as a unique identifier within thescope of the Patient ID Domain (assigningauthority) represented by the identifier root.

assigningAuthorityName

STR+

A human readable name or mnemonic for theassigning authority. The Assigning Authority
Name has no computational value. The purpose ofan Assigning Authority Name is to assist an

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

38

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Name

Displayable

1175

1180

1185

Type

Opt

Name
unaided human interpreter of an II value tointerpret the authority. Note: no automatedprocessing must depend on the assigning authority
name to be present in any form.

BL

O

Specifies if the identifier is intended for human
display and data entry (displayable = true) as
opposed to pure machine interoperation(displayable = false).

IHE specifies that the Patient Identifier Cross-reference Manager must populate both elements
root and extension for Patient ID Domain and Patient ID value, respectively, and element root
must be an ISO OID. If the same patient identifier is populated in a HL7 V2 message, element
root and extension shall correspond to CX.4.2 and CX.1, respectively, and CX.4.3 shall be ISO(see Section E.1).
In addition, IHE requires that the Patient Identifier Cross-reference Manager populates element
assigningAuthorityName. Though there is no additional requirement for the data type of thiselement than a text string in a HL7 V3 message or CDA document, it shall be the same value as
populated in CX.4.1, if the actor participates in transactions of both HL7 V3 and HL7 V2
messages. In this case, element assigningAuthorityName shall contain a value of HL7 V2 data
type IS, a code taken from user-defined Table 0363, Assigning Authority, see Section E.1.
E.2.2: Other actor requirements
The patient identifier information may also appear in HL7 V3 messages or CDA documents
generated by other IHE Actors, including the Patient ID Cross-reference Consumer, the Patient
Information Source, XDS Document Source. Table E.2.2-1 specifies requirements for these
actors when populating a value of the II data type to express a patient identifier.

1190
Table E.2.2-1: Usage of HL7 Data Type CX by other IHE Actors
Name

Type

Opt

Name

Root

OID

R

An ISO OID of the Patient ID Domain (assigningauthority) that guarantees the global uniqueness ofthe patient identifier.

Extension

STR+

A character string as a unique identifier within thescope of the Patient ID Domain (assigningauthority) represented by the identifier root.

assigningAuthorityName

STO

A human readable name or mnemonic for theassigning authority. The Assigning Authority
Name has no computational value. The purpose ofan Assigning Authority Name is to assist an
unaided human interpreter of an II value tointerpret the authority. Note: no automatedprocessing must depend on the assigning authority
name to be present in any form.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

39

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Name
Displayable

1195

Type

Opt

Name

BL

O

Specifies if the identifier is intended for human
display and data entry (displayable = true) as
opposed to pure machine interoperation(displayable = false).

These actors are not required to provide a value for element assigningAuthorityName. However,if they choose to provide a value of this element and generate both HL7 V2 messages and HL7
V3 messages or CDA documents, the same requirement for the Patient Identifier Cross-referenceManager (ITI TF-2x: E.2.1) applies.
E.2.3: Examples of use

1200

The similar case of Metropolitan Medical Center in Section E.1.2 is used to provide HL7 V3 II
data type for patient identifier expression in this section. Since element root of the II data type isalways required and must be an ISO OID, the example case is adopted (compared to Section
E.1.2).
E.2.3.1:

Data sent by source systems

The source systems provide data to the Patient Identifier Cross-reference Manager. These data
are sent in a Patient Identity Feed HL7 V3 transaction [ITI-44].
1205•

Patient Smith’s Social Security number is 999-99-4452. This number is assigned by the
U.S. Social Security Administration, which uses a known ISO Object Identifier for
issuing the Social Security Numbers, 2.16.840.1.113883.4.1. 5•

Patient Smith’s medical record number is 9990-99497. This number is assigned byMetropolitan Medical Center. The ISO OID of its medical record number domain is
1.2.xx.yyyyy.123.45672.

•

Patient Smith’s medical insurance number is 99998410. This number is assigned by
MLH Life & Casualty Company, whose ISO OID for issuing insurance numbers is
1.2.xxx.yyyyy.987.65432

1210

1215

The source system will include the patient identifier information of the II data type in a HL7 V3
message generated for the Patient Identity Feed transaction or Patient Identity Cross-Referenceor Patient Demographics Query Request as shown in the following:

5

As registered in the HL7 OID registry at http://www.hl7.org/oid/index.cfm

2

These OIDs are fictitious, which is emphasized by the incorrect formatting using letters

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

40

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________<identifiedPerson><id root="2.16.840.1.113883.4.1"

1220

extension="999-99-4452"/><id

root="1.2.xx.yyyyyy.123.4567"

extension="9990-99497"<id:

root="1.2.xx.yyyyy.987.6543"

extension="99998410" />

/>

1225

:
</identifiedPerson>1230

E.2.3.2:

Data sent by the Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager implements HL7 V2 Table 0363, Assigning
Authority, which includes the names of identifier domains (assigning authorities) used in theexample of Section E.2.3.1:

1235

•

US Social Security Administration: USSSA•

Medical record number domain of Metropolitan Medical Center: 99MMC•

Insurance number domain of MLH Life & Casualty Company: 99MLHLIFE

To send the patient identifiers, the Patient Identifier Cross-reference Manager builds a HL7 V3
message as follows:
1240

1245

<identifiedPerson><id root="2.16.840.1.113883.4.1" extension="999-99-4452"
assigningAuthorityName=”USSSA”/><id root="1.2.xx.yyyyyy.123.4567" extension="9990-99497"
assigningAuthorityName=”99MMC”/><id root="1.2.xx.yyyyy.987.6543" extension="99998410"
assigningAuthorityName=”99MLHLIFE”/>::</identifiedPerson>

1250

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

41

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix F:

1255

Character String Comparisons

All metadata character string comparisons shall be done in conformance with the rules of theUnicode standard (http://www.unicode.org/versions/latest/) using the normalized form C definedin Unicode Technical Report 15 (http://unicode.org/reports/tr15).
All XML ID comparisons and OID comparisons shall be compared in a case sensitive way.
Note:

1260

Latin alphabet case-sensitive NFC matching corresponds to byte string matching. The primary impact of this isfor non-Latin alphabets. They need to be converted into normalized form before comparison. The TR 15
approach is consistent with the working documents of W3C, although W3C has not yet issued a balloted
recommendation that Unicode normalized form C be used. See http://www.w3.org/TR/WD-charreq,
http://www.w3.org/International/charlint/, and the current W3C draft (http://www.w3.org/TR/charmod-norm).

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

42

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix G:

Transition from Radiology Basic Security to ATNA

Retired.
1265

The previous Appendix G was an XSLT that demonstrated the format translation from the BasicRadiology Schema to the RFC 3881 Schema. It did not generate the correct controlled
vocabulary terms. This caused confusion. A variety of techniques can be used to perform thisconversion. The IHE ITI Technical Framework does not specify any particular technique thatshould be used or will be maintained.

1270

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

43

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix H:

Intentionally Left Blank

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

44

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix I:

Intentionally Left Blank

1275

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

45

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix J:

Intentionally Left Blank

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

46

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix K:
1280

1285

1290

XDS Security Environment

This Appendix expands on the summary provided in the XDS specification (ITI TF-1: 10.8).
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 K.1 and K.2 below. Only a
few of these have issues that are unique to the XDS application.
Section K.3 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
1295

Specific threats to the overall XDS system are listed below. These threats are identified using theCommon Criteria nomenclature defined by ISO 17799. Most of these are mitigated by policies,
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.

1300

T.ADMIN_ERROR Improper administration may result in defeat of specific security features.
T.ADMIN_ROGUE Authorized administrator’s intentions may become malicious resulting in
TSF data to be compromised.

1305

T.AUDIT_CORRUPTA malicious process or user may cause audit records to be lost or
modified, or prevent future records from being recorded by taking actions to exhaust audit
storage capacity, thus masking an attacker’s actions.
T.CONFIG_CORRUPTA malicious process or user may cause configuration data or othertrusted data to be lost or modified.
T.DISASTER System or network may failure due to disaster (e.g., fire, earthquake).

1310

T.DOS
A malicious process or user may block others from system resources via a
resource exhaustion denial of service attack.
T.EAVESDROP
A malicious process or user may intercept transmitted data inside oroutside of the enclave. Some of the XDS environments are not concerned with eavesdrop
exposure. They may employ external protective mechanisms such as physical network security
or VPNs to protect against eavesdropping.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

47

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1315

T.HARDWARE

Hardware may malfunction.

T.IMPROPER_INSTALLATION XDS components may be delivered, installed, orconfigured in a manner that undermines security.
T.INSECURE_START
T.INTRUSION
1320

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.

1325

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.

1330

T.POOR_TEST
Incorrect system behavior may result from inability to demonstrate that allfunctions and interactions within the XDS operation are correct.
T.REPLAY A malicious process or user may gain access by replaying authentication (orother) information.

1335

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

1340

1345

1350

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

T.UNKNOWN_STATE
Upon failure of XDS components, the security of the XDS
environment may be unknown.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

48

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
T.USER_CORRUPT

User data may be lost or tampered with by other users.

K.1.2: Security and Privacy Policy

1355

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.

1360

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)

1365

1370

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.
P.I_AND_A All users must be identified and authenticated prior to accessing any controlled
resources with the exception of public objects.

1375

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.

1380

1385

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.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

49

Copyright © 2015: 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
1390

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:

1395

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.

1400

A.OPERATION
It is assumed that networks, firewalls, etc. are deployed andmaintained to meet appropriate network security levels.
A.PERSONNEL
It is assumed that the organization can assure IT user & otherworkforce personal integrity/trustworthiness.

1405

A.PKI It is assumed that there will be a facility to provide signed certificates as needed for nodeand user authentication. The key management maybe done manually or automatically dependingon the availability of appropriate technology.

K.2: Security Objectives

1410

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)

1415

1420

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. Additional roles
can be defined. These roles are collectively called Administrators.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

50

Copyright © 2015: 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.

1425

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.

1430

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.

1435

1440

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)

1445

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.

1450

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.

1455

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.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

51

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
O.PROTECT
resources.
1460

The XDS components will provide means to protect user data andO.RECOVERY
Procedures and/or mechanisms will be provided to assure that recovery is
obtained without a protection compromise, such as from system failure or discontinuity.
O.REMOTE_SERVICEThe XDS components will provide the means for remote service
without sacrificing security or privacy policy.

1465

O.RESIDUAL_INFORMATION The XDS components will ensure that any information
contained in a protected resource is not released when the resource is reallocated. Information on
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.
1470

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

1475

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

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

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.

1490

OE.PERSONNEL
integrity/trustworthiness.

Assure IT user & other workforce personal

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

52

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
OE.PKI
There will be a facility to provide signed certificates as needed for node and user
authentication.

K.3: Functional Environment
1495

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:

1500

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.

1505

Registry - This functional organization is responsible for providing query services to readers.
The creator has delegated responsibility 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.

1510

There are three levels of difficulty in delegation.

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

1520

1525

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

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

53

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1530

1535

1540

1545

1550

“Hard” delegation is that where the two organizations have different policies orinconsistent/incompatible mitigation strategies. These are likely to occur for the following
policies, where organizations often disagree on the details of the policy goals, and where policies
often change:
P.Authorization – The authorized access policies and authorized modification policies often
differ, and are often subject to change. The changes that occur are often at a detailed level, e.g.,access rights to a particular patient information may change. This means that either there is anagreed mechanism to 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:

1555

1560

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.

1565

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 of

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

54

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
policy combinations between creators, repositories, registries, and readers into a linear growth incomplexity.
1570

1575

1580

The “approved delegation” may go further into identification of persons, but this is only a viable
path when all parties have policies the easily support delegation of personal responsibility.
Persons are usually required to comply with organizational policies, and organizations generally
use roles rather than persons to establish policies. The often viable exception is the special caseof the “deny access to person X”. This can be a viable means of dealing with situations involving
a conflict of interest. This kind of access denial may be applicable to just a particular subset 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.

Appendix L:
Relationship of Document Entry Attributes andDocument Headers
1585

For DocumentEntry relationship to Document Content, please see the IHE PCC TF-2: 4; or a
specific Document Content Profile.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

55

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix M:
Environment
M.1:
1590

Using Patient Demographics Query in a Multi-Domain

HL7 QBP^Q22 Conformance Model

The HL7 Find Candidates Query (QBP^Q22) defines a patient demographics query between aclient application and an MPI system (HL7 V2.5, Page 3-64). This implies that the server
maintains a master record of the patient demographics, but may know a number of patient
identifiers from other domains.

1595

In the QBP^Q22 Conformance Statement, QPD-8 (What Domains Returned) is defined as “theset of domains for which identifiers are returned in PID-3” (HL7 V2.5, Page 3-66, second table).
Note that this field does not cite “demographics information in some domains”, but about“identifiers issued in some domains”, and explicitly specifies that these identifiers are returned in
PID-3 (Patient ID List).

1600

In the example following the Conformance Statement in HL7 2.5, three patient records areincluded in the query response; each returned patient record includes two identifiers in PID-3(domains METRO HOSPITAL and SOUTH LAB) as requested in the query. However, one setof demographic information is returned in the remainder of the PID segment. The example does
not illustrate or assume a mechanism for returning multiple sets of demographic information.
Thus it appears that QBP^Q22 is not intended to provide a way to issue a single query for patient
demographics maintained in multiple different patient registration systems (domains).

1605

M.2:

IHE PDQ Architecture

In the PDQ Integration Profile, the supplier is characterized as a Patient Demographics Supplier.
The supplier is not assumed nor required to be an MPI system. It may be holding informationfrom only a single patient identification domain, or may instead hold information from multiple
identification domains.
1610

1615

The latter case would apply if, for example, the Patient Demographics Supplier is grouped withan actor accepting ADT feeds from multiple patient registration systems in different domains.
Equivalently, the Patient Demographics Supplier Actor (or some other Actor with which it isgrouped) may manage a set of patient demographics sources, but is not expected to crossreference them (as a PIX Actor or an MPI system). A conceptual model embracing both multidomain concepts is shown in the following picture.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

56

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1620

Figure M.2-1: Patient Demographics Supplier in a Multi-domain Environment

1625

Because of the definition of QBP^Q22, it must be determined which patient demographics
source a QBP^Q22 query is asking for, before any processing of the query request can proceed.
The identification of a need for such determination is the key difference between the IHE PDQ
transactions and the original HL7 QBP^Q22 definitions.
Three obvious alternatives exist for determining the patient demographics source.
1. The supplier advertises different application entities for each of the patient demographics
sources it manages. By addressing its query to a particular application entity in MSH-5Receiving Application, the consumer explicitly selects a source it is asking for.

1630

2. The consumer is required to populate PID-3.4 in QPD-3 (Query Parameter) with thedomain name administered by the corresponding source (patient identifier domain) it isasking for.
3. The consumer includes in QPD-8 (What Domains Returned) the domain name of thecorresponding patient information source it is asking for.

1635

1640

In selecting among these alternatives for the PDQ Profile, IHE-ITI took into account the need toconstrain the current HL7 QBP^Q22 definition while maintaining the integrity of the HL7
standard query and at the same time to model the IHE PDQ Profile properly to satisfy its realworld purpose. Based on these considerations, alternative 1 is the best selection, althoughalternative 2 is acceptable. Alternative 3 is not acceptable because it violates the definition of
QPD-8 that is stated in the HL7 Standard.

M.3:

Implementing PDQ in a multi-domain architecture

There are three possible approaches in using PDQ in a multi-domain environment:
1. Group the PDQ Patient Demographics Supplier Actor with a PIX Patient Identifier Crossreference Manager Actor. This allows the use of QPD-8 to request patient identifiers
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

57

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1645

1650

from other domains to be returned in the demographics query response to the PDQ
Patient Demographics Consumer.
2. Group the PDQ Patient Demographics Supplier Actor with a PIX Patient Identifier Crossreference Consumer Actor. This allows the use of QPD-8 to request patient identifiers
from other domains to be returned in the demographics query response to the PDQ
Patient Demographics Consumer.
3. Group the PDQ Patient Demographics Consumer Actor with a PIX Patient Identifier
Cross-reference Consumer Actor. This obliges the Patient Demographics Consumer touse separate query requests to obtain patient demographics information (PDQ query) andpatient identifiers from the domains in which it is interested (PIX query).

1655

1660

1665

Approach 3 is not recommended if Approach 1 or 2 is feasible. To require the Patient
Demographics Consumer to issue a separate PIX query increases complexity and might not be
permissible in the actual implementation architecture.
When Approach 1 or 2 is implemented, QPD-8 may be used by the Patient Demographics
Consumer to ask for patient identifiers from the single domain used to identify patients in the
Affinity Domain.. The patient demographics information returned comes from the patient
demographics source that is associated with MSH-5-Receiving Application; the patient
demographics source may or may not be associated with the patient identifier domain.
In Approach 2, note that the PDQ Patient Demographics Supplier is grouped with the PIX
Patient Identifier Cross-reference Consumer. This combined actor will use a PIX Query to satisfy
the request of the client from additional patient identifiers and return them in PID-3.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

58

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix N:

Common Data Types

This section describes IHE constraints of commonly used HL7 data types.

N.1:
1670

CX Data Type

This data type definition is not used in ITI-8, ITI-9, or ITI-10. See Appendix E for the rules for
those transactions.
CX: Extended Composite ID with check digit
SEQ

LEN

DT

Usage

CARD

TBL#

COMPONENT NAME

1

15

ST

R

[1..1]

ID Number

2

1

ST

O

[0..1]

Check Digit

3

3

ID

O

[0..1]

0061

Check Digit Scheme

4

227

HD

R

[1..1]

0363

Assigning Authority

5

5

ID

RE

[0..1]

0203

Identifier Type Code

6

227

HD

O

[0..1]

Assigning Facility

7

8

DT

O

[0..1]

Effective Date

8

8

DT

O

[0..1]

Expiration Date

9

705

CWE

O

[0..1]

Assigning Jurisdiction

10

705

CWE

O

[0..1]

Assigning Agency or Department

The constraints above particularly apply to the Patient Identifiers carried in the PID segment.
1675

The data type has been constrained because the IHE Framework regards the Assigning Authority
and the Identifier Type Code as essential components.
A common value of the Identifier Type Code for a Patient Identifier assigned by the healthcareorganization (PID-3) is “PI”. Other values are defined in Table 0203 of HL7 2.5 Section
2.A.17.5.

1680

Example: 12345^^^Saint-John Hospital^PI

The Identifier Type Code for Patient Account Number (PID-18) is “AN”.

N.2:

EI Data TypeEI: Entity Identifier
SEQ

LEN

DT

Usage

CARD

1

16

ST

R

[1..1]

2

20

IS

C

[0..1]

3

199

ST

C

[0..1]

4

6

ID

C

[0..1]TBL#

COMPONENT NAME
Entity Identifier

0363

Namespace ID
Universal ID

0301

Universal ID Type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

59

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1685

Component 1 is required. Either component 2 or both components 3 and 4 are required.
Components 2, 3 and 4 may be all present.
The EI is appropriate for machine or software generated identifiers. The generated identifier goesin the first component. The remaining components, 2 through 4, are known as the assigningauthority; they can also identify the machine/system responsible for generating the identifier incomponent 1.

1690

Example 1: AB12345^RiversideHospital

Example 2: AB12345^^1.2.840.45.67^ISO

Example 3: AB12345^RiversideHospital^1.2.840.45.67^ISO
1695

IHE constrains the length of the first component to 16 characters. National extensions can extend
this length up to a maximum of 199.
IHE recommends that Component 2, “Namespace ID,” always be populated. Particularly when
there are several concurrent assigning authorities within the healthcare enterprise, thisNamespace ID will indicate which assigning authority provided the identifier in Component 1.

N.3:
1700

HD Data Type

This data type definition is not used in ITI-8, ITI-9, or ITI-10. See Appendix E for the rules for
those transactions.
HD: Hierarchic designator
SEQ

LEN

DT

Usage

CARD

TBL#

R

[1..1]

0300

Namespace ID

0301

Universal ID Type

1

20

IS

2

199

ST

C

3

6

ID

C

COMPONENT NAME
Universal ID

This Integration Profile requires that a field of Data Type HD be populated with:
1705

1710

•

Either the first component “Namespace ID” alone, which in this case contains a local
identifier of the object.

•

Or with all three components, “Namespace ID” containing the name of the object,“Universal ID” containing its universal OID, and “Universal ID Type” containing thevalue ISO.

This data type is particularly used in this profile to identify facilities, applications and assigningauthorities: sending and receiving applications, sending and receiving facilities, last update
facility, assigning authority of an identifier, etc.

N.4:

PL data Type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

60

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
PL: Person Location
SEQ

LEN

DT

Usage

CARD.

TBL#

COMPONENT NAME

1

20

IS

O

[0..1]

0302

Point of Care

2

20

IS

O

[0..1]

0303

Room

3

20

IS

O

[0..1]

0304

Bed

4

227

HD

O

[0..1]

5

20

IS

O

[0..1]

0306

Location Status

6

20

IS

C

[0..1]

0305

Person Location Type

7

20

IS

O

[0..1]

0307

Building

8

20

IS

O

[0..1]

0308

Floor

9

199

ST

O

[0..1]

Location Description

10

427

EI

O

[0..1]

Comprehensive Location Identifier

11

227

HD

O

[0..1]

Assigning Authority for Location

Facility

1715
Comments on some components:
Component 1: Point of Care (IS):1720

HL7 definition: This component specifies the code for the point where patient care isadministered. It is conditional on PL.6 Person Location Type (e.g., nursing unit or
department or clinic). After floor, it is the most general patient location designation.
HL7 user-defined Table 0302 does not suggest any value. The codification of point ofcares will be defined at the site level in acute care settings.
Component 4: Facility (HD):1725

HL7 definition: This component is subject to site interpretation but generally describes thehighest level physical designation of an institution, medical center or enterprise. It is themost general person location designation.
The codification of facilities will be defined at the highest level, according to the context ofuse of the PAM Profile (community affinity domain, acute care setting, ambulatory
domain, etc.).

1730

1735

Component 6: Person Location Type (IS):HL7 definition: Person location type is the categorization of the person’s location definedby facility, building, floor, point of care, room or bed. Although not a required field, whenused, it may be the only populated field. It usually includes values such as nursing unit,
department, clinic, SNF, physician’s office. Refer to User-defined Table 0305 - Person
location type for suggested values.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

61

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
User-defined Table 0305 – Person location type
Value

1740

Description

C

ClinicD

Department

H

Home

N

Nursing Unit

O

Provider’s Office

P

Phone

S

SNF

Comment

National extensions of this profile may further constrain on extend this table.

N.5:

TS Data Type

TS: Time Stamp
SEQ

1745

LEN

DT

Usage

CARD

1

24

DTM

R

[1..1]

2

1

ID

X

[0..0]TBL#

COMPONENT NAME
Time

0529

Degree of Precision

The first subfield is required. It specifies a point in time.
Maximum length: 24.
HL7 Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]
Constrained format in the PAM Profile: YYYY[MM[DD[HH[MM[SS]]]]][+/-ZZZZ]The least precise date possible is YYYY (only the year).

1750

The most precise date possible is YYYYMMDDHHMMSS (up to the second).
The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time
(UTC), (formerly Greenwich Mean Time (GMT)), where +0000 or -0000 both represent UTC(without offset).

1755

Note that if the time zone is not included, the time zone defaults to the local time zone of thesender.
The second subfield is deprecated in HL7 v2.5, therefore not supported by the PAM Profile.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

62

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________N.6:

XPN Data Type1760
XPN: Extended Person Name
SEQ

LEN

DT

USAGE

CARD

TBL#

COMPONENT NAME

1

194

FN

RE

[0..1]

Family Name

2

30

ST

O

[0..1]

Given Name

3

30

ST

O

[0..1]

Second and Further Given Namesor Initials Thereof

4

20

ST

O

[0..1]

Suffix (e.g., JR or III)

5

20

ST

O

[0..1]

6

6

IS

X

[0..0]

0360

Degree (e.g., MD)

7

1

ID

R

[1..1]

0200

Name Type Code

8

1

ID

O

[0..1]

0465

Name Representation Code

9

483

CE

O

[0..1]

0448

Name Context

10

53

DR

X

[0..0]

11

1

ID

O

[0..1]

12

26

TS

O

[0..1]

Effective Date

13

26

TS

O

[0..1]

Expiration Date

14

199

ST

O

[0..1]

Professional Suffix

Prefix (e.g., DR)

Name Validity Range
0444

Name Assembly Order

This data type is usually in a repeatable field, to allow a list of names. Examples: Legal name,display name.
1765

Subfield 1 “Family Name” is required if known to the sender.
Subfield 7 “Name Type Code” is required. The PAM Profile allows these values from HL7 Table
0200 – Name type:
HL7 Table 0200: Name type
Value

Description

A

Alias NameB

Name at BirthC

Adopted Name

D

Display NameI

Licensing Name

L

Legal Name

M

Maiden NameN

Nickname /”Call me” Name/Street NameR

Registered Name (animals only)S

Coded Pseudo-Name to ensure anonymity

Comment

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

63

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Value

Description

T

Indigenous/Tribal/Community NameU

Unspecified

Comment

1770
This table may be further defined and restrained in national extensions of this profile.
Subfields 6 (Degree) and 10 (Name Validity Range) are deprecated in HL7 v2.5, therefore notsupported by the PAM Profile
1775

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

64

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix O:
Wrappers

HL7 v3 Transmission and Trigger Event Control Act

An HL7 Version 3 Interaction is composed of 2 parts:
1. An "HL7 Transmission wrapper(s)" (always)
1780

2. The "HL7 Transmission Content" (optional)

O.1: HL7 V3 Transmission Wrappers

1785

An "HL7 Transmission wrapper" includes information needed by a sending application ormessage handling service to package and route the V3 interaction to the designated receiving
application(s) and/or message handling service(s). This wrapper also includes attributes that
influence the message handling behavior of the receiving application that is consistent with the
HL7 defined messaging interaction for which the interaction has been created.
NOTE: These wrappers loosely equate to the MSH, MSA, and ERR segments in HL7 v2.5.
All HL7 Version 3 interactions have an appropriately configured "HL7 Transmission wrapper".
The HL7 Transmission Wrapper exists in two different forms:

1790

1795

1. The Message Transmission Wrapper. This wrapper contains zero or one instances of HL7
Transmission Content.
2. The Batch Transmission Wrapper. This wrapper contains zero or more Message
Transmission Wrappers. Each Message Transmission Wrapper contains zero or one
instances of HL7 Transmission Content. The Batch wrapper is occasionally used to group
Message Transmissions.
An interaction that has the Message Transmission Wrapper as its "outermost" wrapper iscommonly referred to as a "message" or a "message-based interaction". An interaction that has
the Batch Transmission Wrapper as its "outermost" wrapper is commonly referred to as a "batch"or a "batch-based interaction".

1800

For the Refined Message Information Models, Hierarchical Message Definitions and Message
Type Table Views, refer to:
http://hl7.org/v3ballot2007may/html/domains/uvci/uvci_GenericMessageTransmission.htm
O.1.1: Send Message Payload Information Model (MCCI_RM000100IHE)

1805

Below is the Message Information Model for this transmission wrapper. The purpose of themodel is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Send Message Payload (MCCI_RM000100UV01) RMIM,
which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvci/editable/MCCI_RM000100UV.htm
The following restrictions were made on the original RMIM to arrive at the restricted model:
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

65

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1810

•

1815

•

1820

1825

The following optional class attributes have been omitted:•

Message.profileId•

Message.responseCode•

Message.attachmentText•

Sender.telecom•

Receiver.telecom•

Device.desc•

Device.existenceTime

The following optional classes have been omitted:•

AttentionLine•

RespondTo•

LocatedEntity•

scopedRole(Organization)

Figure O.1.1-1: Message Information Model

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

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

66

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Table O.1.1-1: Model Attributes
MCCI_HD000100IHE
Send Message Payload

This HMD extract defines the transmission wrapper used to send HL7 V3
Message Payload.
Derived from Figure O.1.1-1 (MCCI_RM000100IHE)

Message

The transmission focal class. According of the XML ITS, the root XML element
representing this class will be the HL7 interaction ID

id [1..1] (M)Transmission (II)Unique message ID

creationTime [1..1] (M)Transmission (TS)Time stamp representing the time the message was created. Note that this is different
from the time when the event which triggered the message occurred.

versionCode [0..1]
Message (CS)
{CNE:HL7StandardVersionCode,default= "V3PR1"}

The HL7 Version used in this message

interactionId [1..1] (M)Message (II)The HL7 Interaction ID represented by this message

processingCode [1..1] (M)Message (CS) {CNE:ProcessingID}

This attribute defines whether the message is part of a production, training, ordebugging system. Valid values are D (Debugging), T (Testing), P (Production) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingID.htm

processingModeCode [1..1] (M)Message (CS)
{CNE:ProcessingMode}

This attribute defines whether the message is being sent in current processing, archivemode, initial load mode, restore from archive mode, etc. Valid values are A (Archive),
T (Current processing), I (Initial Load), R (Restore from archive) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingMode.htm

acceptAckCode [1..1] (M)Message (CS)
{CNE:AcknowledgementCondition}

Acknowledgement Condition codes describe the conditions under which accept orapplication level acknowledgements are required to be returned in response to themessage send operation. Valid values are AL (Always), ER (Error/reject only), NE(Never).

sequenceNumber [0..1]
Message (INT)

An optional sequence number.

Sender
typeCode [1..1] (M)CommunicationFunction (CS)
{CNE:SND, fixed value= "SND"}

Structural attribute; this is a "Sender" communication function

ReceivertypeCode [1..1] (M)CommunicationFunction (CS)
{CNE:RCV, fixed value= "RCV"}

Structural attribute; this is a "Receiver” communication function

DeviceclassCode [1..1] (M)Entity (CS) {CNE:DEV, default="DEV"}

Structural attribute; this entity is a “Device”

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE,
fixed value= "INSTANCE"}

Structural attribute; this is a specific device

id [1..*] (M)Entity (SET<II>)

The application ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

name [0..*]
Entity (BAG<EN>)

Optional Sender or Receiver name

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

67

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________MCCI_HD000100IHE
Send Message Payload

This HMD extract defines the transmission wrapper used to send HL7 V3
Message Payload.
Derived from Figure O.1.1-1 (MCCI_RM000100IHE)

telecom [0..*]
Entity (BAG<TEL>)

Optional network address of the application

manufacturerModelName [0..1]
Device (SC)

Optional application brand namesoftwareName [0..1]
Device (SC)

Optional software name

Agent

This role links the application with the organization to which it belongs

classCode [1..1] (M)Role (CS) {CNE:AGNT, default="AGNT"}

Structural attribute; this is the Agent role

Organization

The sender or receiver organization

classCode [1..1] (M)Entity (CS) {CNE:ORG, default="ORG"}

Structural attribute; this entity is an organization

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE,
fixed value= "INSTANCE"}

Structural attribute; this is a specific organization

id [1..*] (M)Entity (SET<II>)

The organization ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

name [0..*]
Entity (BAG<EN>)

Optional organization nametelecom [0..*]
Entity (BAG<TEL>)

Optional telecommunications address

ControlActProcessThis is the stub where the focal class of the transmission content will be placed in themessage.

1830

O.1.2: Send Accept Acknowledgement Information Model (MCCI_RM000200IHE)

1835

Below is the Message Information Model for the accept acknowledgment. The purpose of themodel is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Send Accept Acknowledgement (MCCI_RM000200UV01)
RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvci/editable/MCCI_RM000200UV.htm
The following restrictions were made on the original RMIM to arrive at the restricted model:•

1840

The following optional class attributes have been omitted:•

Message.profileId•

Message.attachmentText•

Sender.telecom•

Receiver.telecom

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

68

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1845
•

1850
•

•

Device.desc•

Device.existenceTime•

Acknowledgement.messageWaitingNumber•

Acknowledgement.messageWaitingPriorityCode

The following optional classes have been omitted:•

AttentionLine•

RespondTo•

LocatedEntity•

scopedRole(Organization)

The following constraints have been applied:•

Message.acceptAckCode is fixed to NE (don't ack an ack)•

Acknowledgment is a required class1855
Figure O.1.2-1: Message Information Mode;

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

69

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
The attributes of this model are described in the following table:
1860

Table O.1.2-1: Model Attributes
MCCI_HD000200IHE
Send Accept Acknowledgement

This HMD extract defines the transmission wrapper used to send HL7 V3
Accept Acknowledgement.
Derived from Figure O.1.2-1 (MCCI_RM000200IHE)

Message

The transmission focal class. According of the XML ITS, the root XML element
representing this class will be the HL7 interaction ID

id [1..1] (M)Transmission (II)Unique message ID of the acknowledgment

creationTime [1..1] (M)Transmission (TS)Time stamp representing the time the message was created. Note that this is different
from the time when the event which triggered the message occurred.

versionCode [0..1]
Message (CS)
{CNE:HL7StandardVersionCode,default= "V3PR1"}

The HL7 Version used in this message

interactionId [1..1] (M)Message (II)The HL7 Interaction ID represented by this message

processingCode [1..1] (M)Message (CS) {CNE:ProcessingID}

This attribute defines whether the message is part of a production, training, ordebugging system. Valid values are D (Debugging), T (Testing), P (Production) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingID.htm

processingModeCode [1..1] (M)Message (CS)
{CNE:ProcessingMode}

This attribute defines whether the message is being sent in current processing, archivemode, initial load mode, restore from archive mode, etc. Valid values are A (Archive),
T (Current processing), I (Initial Load), R (Restore from archive) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingMode.htm

acceptAckCode [1..1] (M)Message (CS)
{CNE:AcknowledgementCondition,
fixed="NE"}

Acknowledgement Condition codes describe the conditions under which accept orapplication level acknowledgements are required to be returned in response to themessage send operation. Fixed to NE (Never) as this is an acknowledgment itself.

Sender

The sender is the one which is acknowledging the receipt of a message

typeCode [1..1] (M)CommunicationFunction (CS)
{CNE:SND, fixed value= "SND"}

Structural attribute; this is a "Sender" communication function

ReceiverThe receiver in the one which sent the message being acknowledged

typeCode [1..1] (M)CommunicationFunction (CS)
{CNE:RCV, fixed value= "RCV"}

Structural attribute; this is a "Receiver” communication function

DeviceclassCode [1..1] (M)Entity (CS) {CNE:DEV, default="DEV"}

Structural attribute; this entity is a “Device”

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE, fixedvalue= "INSTANCE"}

Structural attribute; this is a specific device

id [1..*] (M)Entity (SET<II>)

The application ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

name [0..*]
Entity (BAG<EN>)

Optional Sender or Receiver name

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

70

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________MCCI_HD000200IHE
Send Accept Acknowledgement

This HMD extract defines the transmission wrapper used to send HL7 V3
Accept Acknowledgement.
Derived from Figure O.1.2-1 (MCCI_RM000200IHE)

telecom [0..*]
Entity (BAG<TEL>)

Optional network address of the application

manufacturerModelName [0..1]
Device (SC)

Optional application brand namesoftwareName [0..1]
Device (SC)

Optional software name

Agent

This role links the application with the organization to which it belongs

classCode [1..1] (M)Role (CS) {CNE:AGNT, default="AGNT"}

Structural attribute; this is the Agent role

Organization

The sender or receiver organization

classCode [1..1] (M)Entity (CS) {CNE:ORG, default="ORG"}

Structural attribute; this entity is an organization

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE, fixedvalue= "INSTANCE"}

Structural attribute; this is a specific organization

id [1..*] (M)Entity (SET<II>)

The organization ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

name [0..*]
Entity (BAG<EN>)

Optional organization nametelecom [0..*]
Entity (BAG<TEL>)

Optional telecommunications address

Acknowledgement
typeCode [1..1] (M)Acknowledgement (CS)
{CNE:AcknowledgementType}The acknowledgement type. Since this is an Accept Acknowledgement, the possible
values are CA (Accept Acknowledgement Commit Accept), CE (Accept
Acknowledgement Commit Error), or CR (Accept Acknowledgement Commit
Reject).

expectedSequenceNumber [0..1]
Acknowledgement (INT)
TargetMessage

The message being acknowledged

id [1..1] (M)Transmission (II)Unique message ID of the message being acknowledged

AcknowledgementDetail

Describes the error(s) contained in the target message

typeCode [0..1]
AcknowledgementDetail (CS)
{CNE:AcknowledgementDetailType}

Optional detail type indicating if the problem was an error (E), a warning (W), or
informational (I).

code [0..1]
AcknowledgementDetail (CE){CWE:AcknowledgementDetailCode}An optional coded value, representing the acknowledgement detail being transmitted.

text [0..1]
AcknowledgementDetail (ED)Optional description of the acknowledgement detail being transmitted

location [0..*]AcknowledgementDetail (SET<ST>)

The location within the message where the problem occurred. It is recommended that
this is represented via an XPath expression.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

71

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________The Accept Acknowledgement does not contain any additional content defined elsewhere. It willbe transmitted using Web Services, according to the requirements specified in Appendix V.
The following WSDL naming conventions SHALL apply:
accept acknowledgment

1865

1870

1875

1880

1885

-> "MCCI_IN000002UV01_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/MCCI_IN000002UV01.xsd"/><xsd:element name="MCCI_IN000002UV01"/></xsd:schema></types>…
The message is described by the following snippet:…
<message name="MCCI_IN000002UV01_Message"><part element="hl7:MCCI_IN000002UV01" name="Body"/></message>…

Various WSDL examples describing IHE transactions as web services are found in thetransaction definitions in ITI TF-2a and 2b, together with the expected actions of the actors
which provide these services.
O.1.3: Send Application Acknowledgement Information Model(MCCI_RM000300IHE)

1890

Below is the Message Information Model for the application acknowledgment. The purpose of
the model is to describe the data elements relevant for use with IHE transactions based on HL7
V3 messages. It is a strict subset of the Send Application Acknowledgement(MCCI_RM000300UV01) RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvci/editable/MCCI_RM000300UV.htm

1895

The following restrictions were made on the original RMIM to arrive at the restricted model:•

1900

The following optional class attributes have been omitted:•

Message.profileId•

Message.attachmentText•

Sender.telecom•

Receiver.telecom

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

72

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1905

1910

•

•

•

Device.desc•

Device.existenceTime•

Acknowledgement.messageWaitingNumber•

Acknowledgement.messageWaitingPriorityCode

The following optional classes have been omitted:•

AttentionLine•

RespondTo•

LocatedEntity•

scopedRole(Organization)

The following constraints have been applied:•

Message.acceptAckCode is fixed to NE (don't ack an ack)•

Acknowledgment is a required class

1915
Figure O.1.3-1: Message Information Model

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

73

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

The attributes of this model are described in the following table:
1920

Table O.1.3-1: Model Attributes
MCCI_HD000300IHE
Send Application
Acknowledgement

This HMD extract defines the transmission wrapper used to send HL7 V3Application Acknowledgement.
Derived from Figure O.1.3-1 (MCCI_RM000300IHE)

Message

The transmission focal class. According of the XML ITS, the root XML element
representing this class will be the HL7 interaction ID

id [1..1] (M)Transmission (II)Unique message ID of the acknowledgment

creationTime [1..1] (M)Transmission (TS)Time stamp representing the time the message was created. Note that this is different
from the time when the event which triggered the message occurred.

versionCode [0..1]
Message (CS)
{CNE:HL7StandardVersionCode,default= "V3PR1"}

The HL7 Version used in this message

interactionId [1..1] (M)Message (II)The HL7 Interaction ID represented by this message

processingCode [1..1] (M)Message (CS) {CNE:ProcessingID}

This attribute defines whether the message is part of a production, training, ordebugging system. Valid values are D (Debugging), T (Testing), P (Production) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingID.htm

processingModeCode [1..1] (M)Message (CS)
{CNE:ProcessingMode}

This attribute defines whether the message is being sent in current processing, archivemode, initial load mode, restore from archive mode, etc. Valid values are A (Archive),
T (Current processing), I (Initial Load), R (Restore from archive) – see
http://hl7.org/v3ballot2007may/html/infrastructure/vocabulary/ProcessingMode.htm

acceptAckCode [1..1] (M)Message (CS)
{CNE:AcknowledgementCondition,
fixed="NE"}

Acknowledgement Condition codes describe the conditions under which accept orapplication level acknowledgements are required to be returned in response to themessage send operation. Fixed to NE (Never) as this is an acknowledgment itself.

Sender

The sender is the one which is acknowledging the receipt of a message

typeCode [1..1] (M)CommunicationFunction (CS)
{CNE:SND, fixed value= "SND"}

Structural attribute; this is a "Sender" communication function

ReceiverThe receiver in the one which sent the message being acknowledged

typeCode [1..1] (M)CommunicationFunction (CS)
{CNE:RCV, fixed value= "RCV"}

Structural attribute; this is a "Receiver” communication function

DeviceclassCode [1..1] (M)Entity (CS) {CNE:DEV, default="DEV"}

Structural attribute; this entity is a “Device”

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE, fixedvalue= "INSTANCE"}

Structural attribute; this is a specific device

id [1..*] (M)Entity (SET<II>)

The application ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

74

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________MCCI_HD000300IHE
Send Application
Acknowledgement

This HMD extract defines the transmission wrapper used to send HL7 V3Application Acknowledgement.
Derived from Figure O.1.3-1 (MCCI_RM000300IHE)

name [0..*]
Entity (BAG<EN>)

Optional Sender or Receiver nametelecom [0..*]
Entity (BAG<TEL>)

Optional network address of the application

manufacturerModelName [0..1]
Device (SC)

Optional application brand namesoftwareName [0..1]
Device (SC)

Optional software name

Agent

This role links the application with the organization to which it belongs

classCode [1..1] (M)Role (CS) {CNE:AGNT, default="AGNT"}

Structural attribute; this is the Agent role

Organization

The sender or receiver organization

classCode [1..1] (M)Entity (CS) {CNE:ORG, default="ORG"}

Structural attribute; this entity is an organization

determinerCode [1..1] (M)Entity (CS) {CNE:INSTANCE, fixedvalue= "INSTANCE"}

Structural attribute; this is a specific organization

id [1..*] (M)Entity (SET<II>)

The organization ID(s). IHE restriction:
id.root SHALL be an ISO OID, and id.extension SHALL NOT have a value.

name [0..*]
Entity (BAG<EN>)

Optional organization nametelecom [0..*]
Entity (BAG<TEL>)

Optional telecommunications address

Acknowledgement
typeCode [1..1] (M)Acknowledgement (CS)
{CNE:AcknowledgementType}The acknowledgement type. Since this is an Accept Acknowledgement, the possible
values are CA (Accept Acknowledgement Commit Accept), CE (Accept
Acknowledgement Commit Error), or CR (Accept Acknowledgement Commit
Reject).

expectedSequenceNumber [0..1]
Acknowledgement (INT)
TargetMessage

The message being acknowledged

id [1..1] (M)Transmission (II)Unique message ID of the message being acknowledged

AcknowledgementDetail

Describes the error(s) contained in the target message

typeCode [0..1]
AcknowledgementDetail (CS)
{CNE:AcknowledgementDetailType}

Optional detail type indicating if the problem was an error (E), a warning (W), or
informational (I).

code [0..1]
AcknowledgementDetail (CE){CWE:AcknowledgementDetailCode}An optional coded value, representing the acknowledgement detail being transmitted.

text [0..1]
AcknowledgementDetail (ED)Optional description of the acknowledgement detail being transmitted

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

75

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________MCCI_HD000300IHE
Send Application
Acknowledgement

This HMD extract defines the transmission wrapper used to send HL7 V3Application Acknowledgement.
Derived from Figure O.1.3-1 (MCCI_RM000300IHE)

location [0..*]AcknowledgementDetail (SET<ST>)

The location within the message where the problem occurred. It is recommended that
this is represented via an XPath expression.

ControlActProcess

The transmission content sent as part of the application acknowledgement.

O.2: HL7 V3 Transmission Content
The HL7 Transmission Content is comprised of 2 parts:
1925

1. A "Trigger Event Control Act" (required for all messages except accept-level
acknowledgements, for which it is not permitted)
2. The "HL7 Domain Content" specified by an HL7 domain specific technical committee(required for each Trigger Event Control Act)

1930

The "Trigger Event Control Act" contains administrative information related to the "controlled
act" which is being communicated as a messaging interaction. It is also the part of HL7 messages
that can convey status or commands for logical operations being coordinated between healthcare
applications, e.g., the coordination of query specification/query response interactions and registry
act interactions.
Note: The Trigger Event Control Act loosely equates to the EVN segment in HL7 v2.5.

1935

1940

The "HL7 Domain Content" is the primary domain content of the messaging interaction (when it
is present). It contains domain specific content that is specified by an HL7 technical committee
to satisfy a use case driven requirement for an HL7 messaging interaction. If an interaction
contains HL7 Domain Content, then it also contains a Trigger Event Control Act.
For the Refined Message Information Models, Hierarchical Message Definitions and Message
Type Table Views, refer to the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvai/uvai_TriggerEventControlAct.htm andEdition2008/domains/uvmi/uvmi_MasterFile-Registry.htm
O.2.1: Master File/Registry Event Notification Control Act (Role Subject)
Information Model (MFMI_MT700701IHE)

1945

Below is the Message Information Model for this control act wrapper. The purpose of the model
is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Master File / Registry Event Notification(MFMI_RM700700UV01) RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvmi/editable/MFMI_RM700700UV.htm
The following restrictions were made on the original RMIM to arrive at the restricted model:

1950

•

The following optional class attributes have been omitted:•

ControlActProcess.text

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

76

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

1955

•

ControlActProcess.priorityCode•

ControlActProcess.reasonCode•

All participations related to the ControlActProcess have been omitted•

The following act relationships to the RegistrationEvent have been omitted:•

inFulfillmentOf•

definition•

subject2

1960
Figure O.2.1-1: Message Information Model

The attributes of this model are described in the following table.
Table O.2.1-1: Model Attributes
MFMI_HD700701IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry messages with the subject being a role.
Derived from Figure O.2.1-1 (MFMI_RM700701IHE)

Control Act Process

The entry point from the transmission wrapper

classCode [1..1] (M)Act (CS) {CNE:CACT, default="CACT"}

Structural attribute; this is a Control Act

moodCode [1..1] (M)Act (CS){CNE:x_ActMoodIntentEvent}

Structural attribute; possible values are INT (intent), RQO (request), EVN (event,occurrence), PRP (proposal), RMD (recommendation), APT (appointment), ARQ(appointment request), or PRMS (promise).

id [0..*]Act (SET<II>)

Optional Control Act ID

code [0..1]
Act (CD){CWE:HL7TriggerEventCode}The HL7 Trigger Event code

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

77

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
MFMI_HD700701IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry messages with the subject being a role.
Derived from Figure O.2.1-1 (MFMI_RM700701IHE)

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or time interval indication when the ControlActProcess took placelanguageCode [0..1]
Act (CE) {CWE:HumanLanguage}

Optional language code

reasonOf

Act relationship linking the ControlActProcess to a detected issue

typeCode [1..1] (M)ActRelationship (CS)
{CNE:V:ActRelationshipReason, root="RSON"}

Structural attribute; this act relationship is “ReasonOf”

contextConductionInd [0..1]
ActRelationship (BL)The context conduction Indicator value in this control act wrapper

detectedIssueEvent [1..1](A_DetectedIssueDeprecated)

The detected issue related to this event

subject

Act relationship linking the ControlActProcess to the Registration event

typeCode [1..1] (M)ActRelationship (CS) {CNE:SUBJ,
fixed value= "SUBJ"}

Structural attribute; this act relationship is “Subject”

contextConductionInd [1..1] (M)ActRelationship (BL){default= "false"}

The context conduction Indicator value in this control act wrapper SHALL be ‘false’

RegistrationEvent

Although this part of the model has been included in a specialization of the Trigger
Event Control Act wrapper for reasons of consistency, it is conceptually part of the
payload of a HL7 interaction. The Focal Act of all interactions that use this model is theRegistrationEvent act, not the subject Role.

classCode [1..1] (M)Act (CS) {CNE:REG, fixed value="REG"}

Structural attribute; this act is a registration

moodCode [1..1] (M)Act (CS) {CNE:EVN, fixed value="EVN"}

Structural attribute; this is an occurrence of the act

id [0..*]Act (SET<II>)

Optional registration event identifier(s).

statusCode [1..1] (M)Act (CS) {CNE:ActStatus, default="active"}

The status of the registration event. The default is “active”.

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or interval indicating when the registration event took place. IHE
constraint: it this attribute is valued, the author.time SHALL be valued with the sametime expression.

subject

The participation linking the Registration Event to the payload focal role (usually
Patient).

typeCode [1..1] (M)Participation (CS) {CNE:SBJ, default="SBJ"}

Structural attribute; this is a "subject" participation

RegisteredRole

The payload stub. Replaced by a role-based payload from the domain content

authorThis participation represents the entity which authored the registration. The Assigned
Entity SHOULD be a person, MAY be a device or an organization, and SHALL NOT
be a non-person living subject.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

78

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
MFMI_HD700701IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry messages with the subject being a role.
Derived from Figure O.2.1-1 (MFMI_RM700701IHE)

typeCode [1..1] (M)Participation (CS) {CNE:AUT, fixedvalue= "AUT"}

Structural attribute; this participation is of type “Author”

contextControlCode [0..1]
Participation (CS)
{CNE:ContextControl, default= "AP"}

Optional contextControlCode, the default is “AP”

time [0..1]
Participation (IVL<TS>)

Time of creation or performance. IHE constraint: If this attribute is valued, theRegistrationEvent.effectiveTime SHALL be valued with the same time expression

modeCode [0..1]
Participation (CE){CWE:ParticipationMode}

This is the optional participation mode

custodian

The application or organization responsible for the patient identity source. Thisparticipation is required. IHE restriction: the assigned entity SHALL be either anorganization or a device.

typeCode [1..1] (M)Participation (CS) {CNE:CST, fixedvalue= "CST"}

Structural attribute; this participation id of type “Custodian”

contextControlCode [0..1]
Participation (CS)
{CNE:ContextControl, default= "AP"}

Optional contextControlCode, the default is “AP”

ReplacementOf

The relationship between the current Registration Event and other registration events
which are being replaced by the current one.

typeCode [1..1] (M)ActRelationship (CS) {CNE:RPLC,
fixed value= "RPLC"}

Structural attribute; this is a “Replace” relationship

PriorRegistration

The previous registration event, which is being replaced by the current one. An example
is the Resolve Duplicates message, where the prior registration contains the subject rolewith the identifiers which have been merged into the role of the current registration
event.

classCode [1..1] (M)Act (CS) {CNE:REG, fixed value="REG"}

Structural attribute; this act is a registration

moodCode [1..1] (M)Act (CS) {CNE:EVN, fixed value="EVN"}

Structural attribute; this is an occurrence of the act

id [0..*]Act (SET<II>)

Optional prior registration event identifier(s).

statusCode [1..1] (M)Act (CS) {CNE:ActStatus, default="obsolete"}

The status of the registration event. The default is “obsolete”.

PriorRegisteredRole

The role subject of the prior registration.

classCode [1..1] (M)Act (CS) {CNE:ROL, fixed value="ROL"}

Structural attribute; this class is a roleid [1..*] (M)Role (SET<II>)

Identifiers of the role subject of the prior registration. Usually contains the merged ID
of a patient after duplicate resolution.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

79

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
1965
O.2.2: Master File/Registry Query Response Control Act (Role Subject)
Information Model (MFMI_MT700711IHE)

1970

Below is the Message Information Model for this control act wrapper. The purpose of the model
is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Master File / Registry Query Response(MFMI_RM700710UV01) RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvmi/editable/MFMI_RM700710UV.htm. The following restrictions weremade on the original RMIM to arrive at the restricted model:
•

1975

1980

The following optional class attributes have been omitted:•

ControlActProcess.text•

ControlActProcess.priorityCode•

ControlActProcess.reasonCode•

All participations related to the ControlActProcess have been omitted•

The reasonOf act relationship has been omitted•

The following act relationships to the RegistrationEvent have been omitted:•

inFulfillmentOf•

definition•

subject2

1985
Figure O.2.2-1: Message Information Model

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

80

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

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

Table O.2.2-1: Model Attributes
MFMI_HD700711IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry query responses with the subject being a role.
Derived from Figure O.2.2-1 (MFMI_RM700711IHE)

Control Act Process

The entry point from the transmission wrapper

classCode [1..1] (M)Act (CS) {CNE:CACT, default="CACT"}

Structural attribute; this is a Control Act

moodCode [1..1] (M)Act (CS){CNE:x_ActMoodIntentEvent}

Structural attribute; possible values are INT (intent), RQO (request), EVN (event,occurrence), PRP (proposal), RMD (recommendation), APT (appointment), ARQ(appointment request), or PRMS (promise).

id [0..*]Act (SET<II>)

Optional Control Act ID

code [0..1]
Act (CD){CWE:HL7TriggerEventCode}The HL7 Trigger Event code

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or time interval indication when the ControlActProcess took placelanguageCode [0..1]
Act (CE) {CWE:HumanLanguage}

Optional language code

subject

Act relationship linking the ControlActProcess to the Registration event. Note that in
the event of a query for which there are no results, the ControlActProcess will still be
returned, but no RegistrationEvent will be present.

typeCode [1..1] (M)ActRelationship (CS) {CNE:SUBJ,
fixed value= "SUBJ"}

Structural attribute; this act relationship is “Subject”

contextConductionInd [1..1] (M)ActRelationship (BL){default= "false"}

The context conduction Indicator value in this control act wrapper SHALL be ‘false’

RegistrationEvent

Although this part of the model has been included in a specialization of the Trigger
Event Control Act wrapper for reasons of consistency, it is conceptually part of the
payload of a HL7 interaction. The Focal Act of all interactions that use this model is theRegistrationEvent act, not the subject Role. In cases where a query response has norecords to return, there will be no RegistrationEvent being returned.

classCode [1..1] (M)Act (CS) {CNE:REG, fixed value="REG"}

Structural attribute; this act is a registration

moodCode [1..1] (M)Act (CS) {CNE:EVN, fixed value="EVN"}

Structural attribute; this is an occurrence of the act

id [0..*]Act (SET<II>)

Optional registration event identifier(s).

statusCode [1..1] (M)Act (CS) {CNE:ActStatus, default="active"}

The status of the registration event. The default is “active”.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

81

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
MFMI_HD700711IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry query responses with the subject being a role.
Derived from Figure O.2.2-1 (MFMI_RM700711IHE)

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or interval indicating when the registration event took place. IHE
constraint: it this attribute is valued, the author.time SHALL be valued with the sametime expression.

subject

The participation linking the Registration Event to the payload focal role (usually
Patient).

typeCode [1..1] (M)Participation (CS) {CNE:SBJ, default="SBJ"}

Structural attribute; this is a "subject" participation

RegisteredRole

The payload stub. Replaced by a role-based payload from the domain content

authorThis participation represents the entity which authored the registration. The Assigned
Entity SHOULD be a person, MAY be a device or an organization, and SHALL NOT
be a non-person living subject.

typeCode [1..1] (M)Participation (CS) {CNE:AUT, fixedvalue= "AUT"}

Structural attribute; this participation is of type “Author”

contextControlCode [0..1]
Participation (CS)
{CNE:ContextControl, default= "AP"}

Optional contextControlCode, the default is “AP”

time [0..1]
Participation (IVL<TS>)

Time of creation or performance. IHE constraint: If this attribute is valued, theRegistrationEvent.effectiveTime SHALL be valued with the same time expression

modeCode [0..1]
Participation (CE){CWE:ParticipationMode}

This is the optional participation mode

custodian

The application or organization responsible for the patient identity source. Thisparticipation is required. IHE restriction: the assigned entity SHALL be either anorganization or a device.

typeCode [1..1] (M)Participation (CS) {CNE:CST, fixedvalue= "CST"}

Structural attribute; this participation id of type “Custodian”

contextControlCode [0..1]
Participation (CS)
{CNE:ContextControl, default= "AP"}

Optional contextControlCode, the default is “AP”

ReplacementOf

The relationship between the current Registration Event and other registration events
which are being replaced by the current one.

typeCode [1..1] (M)ActRelationship (CS) {CNE:RPLC,
fixed value= "RPLC"}

Structural attribute; this is a “Replace” relationship

PriorRegistration

The previous registration event, which is being replaced by the current one. An example
is the Resolve Duplicates message, where the prior registration contains the subject rolewith the identifiers which have been merged into the role of the current registration
event.

classCode [1..1] (M)Act (CS) {CNE:REG, fixed value="REG"}

Structural attribute; this act is a registration

moodCode [1..1] (M)Act (CS) {CNE:EVN, fixed value="EVN"}

Structural attribute; this is an occurrence of the act

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

82

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
MFMI_HD700711IHE
Master File / Registry Event
Notification (Role Subject)This HMD extract defines the control act wrapper used to send HL7 V3
master file or registry query responses with the subject being a role.
Derived from Figure O.2.2-1 (MFMI_RM700711IHE)

id [0..*]Act (SET<II>)

Optional prior registration event identifier(s).

statusCode [1..1] (M)Act (CS) {CNE:ActStatus, default="obsolete"}

The status of the registration event. The default is “obsolete”.

PriorRegisteredRole

The role subject of the prior registration.

classCode [1..1] (M)Act (CS) {CNE:ROL, fixed value="ROL"}

Structural attribute; this class is a roleid [1..*] (M)Role (SET<II>)

Identifiers of the role subject of the prior registration. Usually contains the merged ID
of a patient after duplicate resolution.

QueryAck

Information about the query to which this message is a response

queryId [1..1] (R)QueryEvent (II)The query ID to which this message is a response.

statusCode [1..1] (R)QueryEvent (CS)
{CNE:QueryStatusCode, default="deliveredResponse"}

The status of the query event. The default is “deliveredResponse”. Possible values are"aborted", "executing", "new", "waitContinuedQueryResponse"

queryResponseCode [1..1] (M)QueryAck (CS) {CNE:QueryResponse}

Code representing the content of the response. Possible values are AE (application
error), OK (data found), NF (no data found), QE (query parameter error).

resultTotalQuantity [0..1]
QueryAck (INT)

Total number of results found.

resultCurrentQuantity [0..1]
QueryAck (INT)The number of results in this message.

resultRemainingQuantity [0..1]
QueryAck (INT)The number of results not transmitted yet.

queryByParameter

The stub to an optional copy of the Query By Parameter payload of the original query.

O.2.3: Query Control Act Request: Query By Parameter Information Model(QUQI_MT021001IHE)
1995

2000

Below is the Message Information Model for this control act wrapper. The purpose of the model
is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Query Specification Control Act: Query By Parameter(QUQI_RM021000UV01) RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvqi/editable/QUQI_RM021000UV.htm. The following restrictions weremade on the original RMIM to arrive at the restricted model:•

The following optional class attributes have been omitted:•

ControlActProcess.text•

ControlActProcess.priorityCode

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

83

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
•
•
2005

•

ControlActProcess.reasonCode

The following participations related to the ControlActProcess have been omitted:•

overseer•

dataEnterer•

informationRecipient

The reasonOf act relationship has been omitted

2010
Figure O.2.3-1: Message Information Model

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

Table O.2.3-1: Model Attributes
QUQI_HD021000IHE
Query Control Act Request:
QueryByParameter

This HMD extract defines the control act wrapper used to send HL7 V3query by parameter messages.
Derived from Figure O.2.3-1 (QUQI_RM021000IHE)

Control Act Process

The entry point from the transmission wrapper

classCode [1..1] (M)Act (CS) {CNE:CACT, default="CACT"}

Structural attribute; this is a Control Act

moodCode [1..1] (M)Act (CS){CNE:x_ActMoodIntentEvent}

Structural attribute; possible values are INT (intent), RQO (request), EVN (event,occurrence), PRP (proposal), RMD (recommendation), APT (appointment), ARQ(appointment request), or PRMS (promise).

id [0..*]

Optional Control Act ID

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

84

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________QUQI_HD021000IHE
Query Control Act Request:
QueryByParameter

This HMD extract defines the control act wrapper used to send HL7 V3query by parameter messages.
Derived from Figure O.2.3-1 (QUQI_RM021000IHE)

Act (SET<II>)code [0..1]
Act (CD){CWE:HL7TriggerEventCode}The HL7 Trigger Event code

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or time interval indication when the ControlActProcess took placelanguageCode [0..1]
Act (CE) {CWE:HumanLanguage}

Optional language code

authorOrPerformer

This optional participation represents the entity which made the query. The author of
the query SHOULD be a person, or it MAY be a device.

typeCode [1..1] (M)Participation (CS)
{CNE:x_ParticipationAuthorPerformer}

Structural attribute; this participation is of type "AUT" or “PRF”

contextControlCode [0..1]
Participation (CS)
{CNE:ContextControl, default= "AP"}

Optional contextControlCode, the default is “AP”

time [0..1]
Participation (IVL<TS>)

Time of creation or performance.

modeCode [0..1]
Participation (CE){CWE:ParticipationMode}

This is the optional participation modequeryByParameter

The stub to the Query By Parameter payload.

O.2.4: Query Control Act Request Continue/Cancel Information Model(QUQI_MT000001IHE)
2020

Below is the Message Information Model for this control act wrapper. The purpose of the model
is to describe the data elements relevant for use with IHE transactions based on HL7 V3
messages. It is a strict subset of the Query Continuation/Cancel Control Act(QUQI_RM000001UV01) RMIM, which can be found on the HL7 V3 2008 Edition CD at:
Edition2008/domains/uvqi/editable/QUQI_RM000001UV.htm
The following restrictions were made on the original RMIM to arrive at the restricted model:

2025

2030

•

The following optional class attributes have been omitted:•

ControlActProcess.text•

ControlActProcess.priorityCode•

ControlActProcess.reasonCode•

All participations related to the ControlActProcess have been omitted•

The reasonOf act relationship has been omitted

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

85

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________•

ControlActProcess.moodCode is fixed to EVN•

QueryContinuation.queryId is Mandatory•

QueryContinuation.statusCode is defaulted to "waitContinuedQueryResponse"

2035

Figure O.2.4-1: Message Information Model

The attributes of this model are described in the following table.
Table O.2.4-1: Model Attributes
QUQI_HD000001IHE
Query Control Act Request
Continuation/Cancelation Control
ActThis HMD extract defines the control act of the query continuation
request. Note that there is no payload.
Derived from Figure O.2.4-1 (QUQI_RM021000IHE)

Control Act Process

The entry point from the transmission wrapper

classCode [1..1] (M)Act (CS) {CNE:CACT, default="CACT"}

Structural attribute; this is a Control Act

moodCode [1..1] (M)Act (CS) {CNE:x_ActMoodIntentEvent,
fixed="EVN"}

This is a request

id [0..*]Act (SET<II>)

Optional Control Act ID

code [0..1]
Act (CD) {CWE:HL7TriggerEventCode}The HL7 Trigger Event code

effectiveTime [0..1]
Act (IVL<TS>)

Optional time stamp or time interval indication when the ControlActProcess tookplace

languageCode [0..1]
Act (CE) {CWE:HumanLanguage}

Optional language code

QueryContinuation

The information about the query, which is being continued

queryId [1..1](M)QueryEvent (II)The query identifier, which links this continuation request with the original query.

statusCode [1..1] (M)The query status. The only other possible value is "aborted", indicating that no more

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

86

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________QUQI_HD000001IHE
Query Control Act Request
Continuation/Cancelation Control
Act
QueryEvent (CS)
{CNE:QueryStatusCode,default="waitContinuedQueryResponse"}

This HMD extract defines the control act of the query continuation
request. Note that there is no payload.
Derived from Figure O.2.4-1 (QUQI_RM021000IHE)
results are needed from the query fulfiller.

startResultNumber [0..1]
QueryContinuation (INT)

Optionally, the query placer may request that the list of responses starts from aparticular unit (based on the total number of responses returned by the query fulfiller
to the original query)continuationQuantity [0..1]
QueryContinuation (INT)

Optionally, the query placer may specify the maximum number of responses to be
returned by the query fulfiller. If 0 is specified, this is an indication that the query iscancelled. If this attributed is not valued, the query fulfiller shall use the quantity
specified in the most recent query or continuation request.

2040

O.3: IHE Transactions and Corresponding Transmission and Control
Act Wrappers
The following table lists the wrappers for the currently defined IHE transactions, which use HL7
V3 messages.
2045
Table O.3-1: IHE Transactions and Corresponding Transmission and Control Act
Wrappers
Transaction Reference

Transmission Wrapper

Control Act Wrapper

3.44.4 – Patient Add or Revise

MCCI_MT000100UV01

MFMI_MT700701UV01

3.44.4 – Resolve Duplicates

MCCI_MT000100UV01

MFMI_MT700701UV01

3.44.4 – Acknowledgement

MCCI_MT000200UV01

None

3.45.4 – Get Corresponding Identifiers

MCCI_MT000100UV01

QUQI_MT021001UV01

3.45.4 – Get Corresponding Indenters
Response

MCCI_MT000300UV01

MFMI_MT700711UV01

3.46.4 – Revise Demographic Data

MCCI_MT000100UV01

MFMI_MT700701UV01

3.46.4 – Acknowledgement

MCCI_MT000200UV01

None

3.47.4 – Find Candidates Query

MCCI_MT000100UV01

QUQI_MT021001UV01

3.47.4 – Find Candidates Response

MCCI_MT000300UV01

MFMI_MT700711UV01

3.47.4 – Query Continuation

MCCI_MT000300UV01

QUQI_MT000001UV01

3.47.4 – Acknowledgement

MCCI_MT000200UV01

None

2050

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

87

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix P:

Examples of messages

P.1: Example of transaction ITI-31: Admit for Surgical Procedure
This example illustrates the use of ITI-31 with the following options:
2055•

Inpatient/Outpatient Encounter Management•

Advanced Encounter Management•

Temporary Patient Transfer Track•

Historic Movement Management

P.1.1: Storyboard
2060

2065

Robert LAW arrives from home to Saint-Louis Hospital. Operator Janine WHITE registers
Robert in the administrative systems and creates a new account for billing. The reason ofadmission is a surgery of the heart, and Robert is under the responsibility of Cardiology. Before
the surgery, a chest X-Ray and an electrocardiogram have to be performed. After the surgery,
Robert is transferred to the Intensive Care Unit for 2 days. The transfer to the ICU is enteredwith two errors (wrong bed, wrong time). This transfer is corrected with the appropriate values.
Then Robert is transferred back to Cardiology. Two weeks after admission, Robert is sent backhome. Later on, his last movement in cardiology is corrected.
Table P.1.1-1: Storyboard Attribute Values
Objects

Attributes

Patient

Legal name: Robert LAW
ID: 12345
Sex: male
Date of birth: October 2nd 1946
Billing Account Number: 987654

Administrative Operator

Legal name: Janine WHITE, ID: 1001
Legal name: Eva STRAW, ID: 1002
Legal name: Betty GARDNER, ID: 1003
Legal name: Jana BLACKMORE, ID: 1004

Assigning Facility

Saint-Louis Hospital

Attending Doctors

Legal name: Charles BROWN, ID: 2001
Legal name: Ray JOHNSON, ID: 2002

Family Doctor

Legal name: Bob FAMILY, ID 7777

Medical Departments

Name: Cardiology, Code: 6043, Bed: 1, Room: 200
Name: Cardiology, Code: 6043, Bed: 3, Room: 202
Name: Radiology, Code: 5001
Name: ICU, Code: 5050, Bed: 1, Room: 4302070
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

88

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
P.1.2: Interaction Diagram
The following diagram illustrates the interactions used in this Example. The acknowledgement
messages are not shown.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

89

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Patient Encounter Consumer

Patient Encounter Source

An Inpatient is admitted: ADT^A01
Room and bed assigned in Cardiology:
ADT^A02
Patient leaves Cardiology (Tracking):
ADT^A09
Patient arrives in Radiology (Tracking):
ADT^A10
Patient leaves Radiology (Tracking):
ADT^A09
Patient arrives in Cardiology (Tracking):
ADT^A10
Change attending Doctor: ADT^A54
Room and bed assigned in ICU:
ADT^A02
Update current Movement: ADT^Z99

Room and bed assigned in Cardiology:
ADT^A02:Change attending Doctor
ADT^A54

Patient discharge: ADT^A03
Update Historic Movement: ADT^Z99

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

90

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2075

P.1.3: Messages
Operator Janine White admits Robert Law as an Inpatient in the administrative system of SaintLouis Hospital. She creates a new billing account number (987654). The attending doctor ofRobert Law is Doctor Charles Brown, during Robert’s stay in the Cardiology department.

2080

2085

2090

2095

2100

2105

2110

2115

2120

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A01^ADT_A01|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530082000|||1001^WHITE^Janine|20050530082000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
ROL||AD|FHCP|7777^FAMILY^Bob
PV1|1|I|||||2001^BROWN^Charles
ZBE|mvt1|20050530082000||INSERT|N

Robert LAW arrives in Cardiology and a secretary (Eva STRAW) validates the arrival by
assigning a room and a bed to the Patient. Had the bed been assigned at admission time, thepatient location would have been part of the ADT^A01 message.
MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A02^ADT_A02|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530082500|||1002^STRAW^Eva|20050530082500
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|6043^200^1^Saint-LouisZBE|mvt2|20050530082500||INSERT|N

The electrocardiogram is performed in the Cardiology department. However, Robert needs to betransferred to Radiology for the chest X-Ray. This move to a temporary location is tracked by
two messages: A09 when departing the cardiology, A10 when arrived in Radiology. These
tracking events are not Movements, and don’t use the ZBE segment.
MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A09^ADT_A09|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530123000|||1002^STRAW^Eva|20050530122500
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I||||6043^200^1^Saint-Louis|||||5001^^^Saint-Louis

MSH|^~\&| ?|Saint-Louis| ?|SaintLouis|20050530082015||ADT^A10^ADT_A09|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530123000|||1003^GARDNER^Betty|20050530123000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I||||6043^200^1^Saint-Louis|||||5001^^^Saint-LouisWhen the X-Ray is performed, Robert leaves the Radiology department and comes back to
Cardiology. Two other movement-tracking messages are generated.
MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A09^ADT_A09|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530123000|||1002^STRAW^Eva|20050530125000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

91

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
987654^^^Saint-Louis^AN
PV1|1|I|6043^200^1^Saint-Louis||||||||||||||||||||||||||||||||||||||||5001^^^Saint-Louis

2125

2130

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A10^ADT_A09|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530123000|||1002^STRAW^Eva|20050530125500
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|6043^200^1^Saint-Louis||||||||||||||||||||||||||||||||||||||||5001^^^Saint-LouisThe surgery is planned for the next day. When the surgery is completed, Robert LAW istransferred to the Intensive Care Unit for 2 days. Ray JOHNSON is the new attending physician
during these 2 days.
2135

2140

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A54^ADT_A54|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050531114000|||1002^STRAW^Eva|20050531114000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|||||2002^JOHNSON^Ray
ZBE|mvt3|20050531114000||INSERT|N

When Robert LAW arrives in ICU, a secretary (Jana BLACKMORE) validates the arrival by
assigning a room and a bed. She makes two typing mistakes (wrong bed, wrong time)
2145

2150

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A02^ADT_A02|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050531114400|||1004^BLACKMORE^Jana|20050531114400
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|5050^430^11^Saint-Louis|||6043^200^1^Saint-LouisZBE|mvt4|20050531114400||INSERT|N

After Robert LAW is moved to his new bed, Jana B BLACKMORE corrects the two mistyping
in the movement.
2155

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^Z99^ADT_A01|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050531114400|||1004^BLACKMORE^Jana|20050531115800
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|5050^430^1^Saint-Louis|||6043^200^1^Saint-LouisZBE|mvt4|20050531104400||UPDATE|N|A022160

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

92

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
After 2 days, Robert LAW leaves the ICU and comes back to Cardiology. A new room and bed
are assigned to the Patient.
2165

2170

2175

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A02^ADT_A02|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050601161200|||1002^STRAW^Eva|20050601161200
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|6043^202^2^Saint-Louis|||5050^430^1^Saint-LouisZBE|mvt5|20050601161200||INSERT|N

MSH|^~\&| ?|Saint-Louis| ?|SaintLouis|20050530082015||ADT^A54^ADT_A54|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050601161000|||1004^BLACKMORE^Jana|20050601161200
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|||||2001^BROWN^Charles
ZBE|mvt6|20050601161200||INSERT|N

After 12 days, Robert LAW is discharged and sent back home.
2180

2185

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A03^ADT_A03|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050613180000|||1001^WHITE^Janine|20050613180000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|6043^200^1^Saint-Louis|||||||||||||||||||||||||||||||||1
ZBE|mvt7|20050613180000||INSERT|N

One hour later the Cardiology corrects an error of both time and bed in the last patient assigned
location in cardiology, triggering an update of the Historic Movement identified as mvt5:
2190

2195

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^Z99^ADT_A01|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050601161200|||1002^STRAW^Eva|20050613190000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|6043^202^3^Saint-Louis|||5050^430^1^Saint-LouisZBE|mvt5|20050601161233||UPDATE|Y|A02

P.2:

Example of transaction ITI-31: Admit and cancel admit

This example uses transaction ITI-31 without any option, to illustrate a cancellation message:
P.2.1: Storyboard
2200

Operator Janine WHITE registers an admission for patient Robert LAW in the administrative
system of Saint-Louis Hospital. After a while it turns out that the patient has been directed to thewrong hospital. The patient is redirected to another hospital and the admission is cancelled.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

93

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Table P.2.1-1: Storyboard Attribute Values
Objects

Attributes

Patient

Legal name: Robert LAW
ID: 12345
Sex: male
Date of birth: October 2nd 1946
Billing Account Number: 987654

Administrative Operator

Legal name: Janine WHITE, ID: 1001

Assigning Facility

Saint-Louis Hospital

Attending Doctors

Legal name: Charles BROWN, ID: 2001
Legal name: Ray JOHNSON, ID: 2002

Family Doctor

Legal name: Bob FAMILY, ID 7777

2205
P.2.2: Interaction Diagram
The following diagram illustrates the interactions used in this Example. The acknowledgement
messages are not shown.
Patient Encounter Source

Patient
admission

Patient admitted: ADT^A01^ADT_A01

Cancelpatient
admission

2210

Patient Encounter Consumer

Admission cancelled: ADT^A11^ADT_A09

Figure P.2.2-1: Interaction Diagram

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

94

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
P.2.3: Messages

2215

2220

2225

Operator Janine White admits Robert Law as an Inpatient in the administrative system of SaintLouis Hospital. She creates a new billing account number (987654). The attending doctor ofRobert Law is Doctor Charles Brown.
MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530082015||ADT^A01^ADT_A01|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530082000|||1001^WHITE^Janine|20050530082000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
ROL||AD|FHCP|7777^FAMILY^Bob
PV1|1|I|||||2001^BROWN^Charles
ZBE|mvt1|20050530082000||INSERT|N
OBX||NM|3142-7^BODY WEIGHT (STATED)^LN||62|kg|||||F
OBX||NM|8303-0^BODY HEIGHT^LN||1.70|m|||||F

The patient is redirected afterwards to another hospital. Janine White cancels the admission.
2230

MSH|^~\&|?|Saint-Louis|?|SaintLouis|20050530084400||ADT^A11^ADT_A09|000001|T|2.5|||||FRA|8859/15|EN
EVN||20050530084350|||1001^WHITE^Janine|20050530082000
PID|1||12345^^^Saint-Louis^PI||LAW^Robert^^^^^L|||M||||||||||
987654^^^Saint-Louis^AN
PV1|1|I|||||2001^BROWN^Charles
ZBE|mvt1|20050530082000||CANCEL|N2235

P.3: HL7 V3 Sample Messages
The following examples are available for information purposes on the IHE ftp site at
ftp://ftp.ihe.net. See ITI TF-2x: Appendix W. The examples are organized by transactions.
P.3.1: ITI-44 Patient Identity Feed HL7 V3 – Sample Messages
2240•

Patient Registry Record Added message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/01_PatientRegistryRe
cordAdded1.xml•

Patient Registry Record Revised message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/04_PatientRegistryRe
cordRevised2.xml•

Patient Registry Duplicates Resolved message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/05_PatientRegistryD
uplicatesResolved.xml•

HL7 V3 Accept Acknowledgement message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/02_PatientRegistryRe
cordAdded1Ack.xml

2245

2250

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

95

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
P.3.2: ITI 45 PIXV3 Query – Sample Messages

2255

•

Patient Registry Get Identifiers Query message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/06_PIXQuery1.xml•

Patient Registry Get Identifiers Query Response message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/07_PIXQuery1Respo
nse.xml

P.3.3: ITI 46 PIXV3 Update Notification – Sample Messages•

Patient Registry Record Revised message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/04_PatientRegistryRe
cordRevised2.xml•

HL7 V3 Accept Acknowledgement message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PIXV3/02_PatientRegistryRe
cordAdded1Ack.xml

2260

2265

P.3.4: ITI 47 Patient Demographics Query HL7 V3 – Sample Messages•

Patient Registry Find Candidates Query message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/01_PDQQuery1.xml•

Patient Registry Find Candidates Query Response message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/02_PDQQuery1Res
ponse.xml•

General Query Activate Query Continue message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/03_PDQQuery1Cont
inuation.xml•

General Query Activate Query Continue Response message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/04_PDQQuery1Cont
inuationResponse.xml•

General Query Activate Query Cancel message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/05_PDQQuery1Can
cel.xml•

General Query Activate Query Cancel Acknowledgment message:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/PDQV3/06_PDQQuery1Can
celAck.xml

2270

2275

2280

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

96

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix Q:
2285

HL7 V3 Sample Payload XML Schemas

The following examples are available for information purposes on the IHE ftp site at
ftp://ftp.ihe.net. See Appendix W. The examples are organized by transactions.

Q.1: ITI-44 Patient Identity Feed HL7 V3 – Sample Schemas•

Patient Registry Record Added schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201301UV02.xsd•

Patient Registry Record Revised schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201302UV02.xsd•

Patient Registry Duplicates Resolved schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201304UV02.xsd•

HL7 V3 Accept Acknowledgment schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/MCCI_IN000002UV01.xsd

2290

2295

2300

Q.2: ITI-45 PIXV3 Query – Sample Schemas•

Patient Registry Get Identifiers Query schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201309UV02.xsd•

Patient Registry Get Identifiers Query Response schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201310UV02.xsd

2305

Q.3: ITI-46 PIXV3 Update Notification – Sample Schemas•

Patient Registry Record Revised schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201302UV02.xsd•

HL7 V3 Accept Acknowledgment schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/MCCI_IN000002UV01.xsd

2310

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

97

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Q.4: ITI-47 Patient Demographics Query HL7 V3 – Sample Schemas
2315•

Patient Registry Find Candidates Query schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201305UV02.xsd•

Patient Registry Find Candidates Query Response schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/PRPA_IN201306UV02.xsd•

General Query Activate Query Continue schema:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/QUQI_IN000003UV01.xsd•

HL7 V3 Accept Acknowledgment schema:•

ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/HL7V3/NE2008/multicachesch
emas/MCCI_IN000002UV01.xsd

2320

2325

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

98

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2330

Appendix R:

Mapping of HL7v2.5 to HL7v3 for PIX and PDQ

R.1: Data Types
The following table describes the mapping between HL7 v2.5 and HL7 v3 data types:
HL7 v2.5 Data TypeHL7 v3 Data TypeHD (on the field level)

Instance Identifier (II)Namespace ID

Assigning Authority Name (optional)

Universal ID

root

Universal ID TypeNot mapped – the universal ID/root must be an ISO OID
extension is not used

CX

Instance Identifier (II)ID (ST)

extension

Check digit (ST)Not mapped

Code identifying the check digit (ST)Not mappedassigning authority (HD)Namespace ID(IS)

Assigning Authority Name (optional)

Universal ID (ST)root

Universal ID Type(IS)
(required to be“ISO”)

Not mapped – the universal ID/root must be an ISO OID

identifier type code (ID)Not mappedassigning facility (HD)Not mapped

effective date (DT)ValidTimeexpiration date (DT)ValidTime

XPN

Person Name (PN)

ID Number (ST)Family Name (FN)

Family Part typegiven name (ST)Given Part type

Second or other given names or initials thereof (ST)Given Part type – order of parts matterssuffix (e.g., JR or III) (ST)

Suffix Part typeprefix (e.g., DR) (ST)

Prefix Part type

degree (e.g., MD) (IS)Suffix Part type

Name Representation code (ID)name context (CE)name validity range (DR)ValidTime

name assembly order (ID)
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

99

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
HL7 v2.5 Data TypeHL7 v3 Data Type

Name type code (ID)Name Use Code

XTN

Telecom (TEL)[999-] 999-9999 [x99999][C any text] (TN)telecommunication use code (ID)Telecom Use Codetelecommunication equipment type (ID)

Reflected in the URL scheme of the URI (e.g., fax:) – see
RFC 2806

Email address (ST)URL Scheme code = mailto

Country Code (NM)Part of the tel: URI (see RFC 3966)

Area/city code (NM)Part of the tel: URI (see RFC 3966)

Phone Number (NM)Part of the tel: URI (see RFC 3966)

Extension (NM)Use of ";ext=" in the URI (see RFC 3966)

any text (ST)Not mapped

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

100

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

R.2: Add New Person Message
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Message
Information
Model

Data
Type

Conf

Field
Separator

ST

R

Not
Applicable

Encoding
Character
s

ST

R

Not
ApplicableComponents

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

Comments

MSH

Sending
Application

MCCI_RM000100IHE Send
Message
Payload

SET
<II>

HD

R

Namespace ID

IS

O

Y

R

Universal ID

ST

O

Y

R

Universal ID
Type

ID

O

Y

R

Sending
Facility

MCCI_RM000100IHE Send
Message
PayloadDevice.id

Organization.
id

R

SET
<II>

HD

R

R

Namespace ID

IS

O

Y

R

Universal ID

ST

O

Y

R

Universal ID

ID

O

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

101

Copyright © 2015: IHE International, Inc.

MappedSET<II> data
type components
to v2.5 HD
components. See
table above.

MappedSET<II> data
type components
to v2.5 HD
components. See
table above.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Data Type
Component
Mapping
Req'd?

Conf

Message
Information
Model

HD

R

MCCI_RM000100IHE Send
Message
PayloadNamespace ID

IS

O

Y

Universal ID

ST

O

Y

Universal ID
Type

ID

O

Y

Components
Type

Receiving
Applicati
onReceiving Facility

Data
Type

MCCI_RM000100IHE Send
Message
PayloadAttribute
Name

Data
Type

SET
<II>

Device.id

Organization.
id

SET
<II>

HD

R

Namespace ID

IS

O

Y

Universal ID

ST

O

Y

Universal ID
Type

ID

O

Date/Time Of
MessageTS
Date/Time

NM

Conf

R

MappedSET<II> data
type components
to v2.5 HD
components. See
table above.

R

MappedSET<II> data
type components
to v2.5 HD
components. See
table above.

Y

R

MCCI_RM000100IHE Send
Message
PayloadMessage.crea
tionTime

TS

Y

R

O

MCCI_RM000100IHE -Message.crea

TS

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

102

Comments

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Components

Data
Type

Conf

Degree ofPrecision

ST

O

R

MCCI_RM000100IHE Send
Message
PayloadMessage.inte
ractionId

II

Y

R

R

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.code

CD
CWE

Y

R

Message
Type

CM_
MSG

R

Messagestructure

ID

ID

Conf

ST

O

Trigger event

Data
Type

Message.sec
urityText

ST

ID

Attribute
NametionTime

Data Type
Component
Mapping
Req'd?

MCCI_RM000100IHE Send
Message
PayloadSecurity

Message typeMessage
Information
Model
Send
Message
PayloadO

Not mappedasinteraction.Id
expresses
both message
type andmessagestructureR

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

103

Copyright © 2015: IHE International, Inc.

Comments

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

Message
Control
ID

Processin
g ID

Processing Mode

VersionID

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Message.id

II

Y

R

MCCI_RM000100IHE Send
Message
PayloadMessage.pro
cessingCode

CS
CNE

R

O

MCCI_RM000100IHE Send
Message
PayloadMessage.pro
cessingCode

CS
CNE

R

O

MCCI_RM000100IHE Send
Message
PayloadMessage.pro
cessingMode
Code

CS
CNE

R

R

MCCI_RM000100IHE Send
Message
PayloadMessage.vers
ionCodeCS
CNE

O

MCCI_RM000100IHE Send
Message
PayloadMessage.vers
ionCode

CS
CNE

O

Data
Type

Conf

ST

R

PT

Processing ID

Version 3 Message

ID

ID

VID

Version ID

ID

OInternationalizati

CEO

Message
Information
Model

Conf

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

104

Copyright © 2015: IHE International, Inc.

Comments
Only the id.root
is valued

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components
on CodeInternationalversion ID

Version 3 Message

Attribute
Name

Data
Type

XCCI_RM00
0100 - Send
Message
PayloadMessage.seq
uenceNumbe
r

INT

R

O

XCCI_RM00
0100 - Send
Message
PayloadMessage.acc
eptAckCode

CS
CNE

R

O

XCCI_RM00
0100 - Send
Message
PayloadMessage.acc
eptAckCode

CS
CNE

R

Data
Type

Conf

CE

O

Sequence
NumberNM

O

Continuat
ion
PointerST

O

AcceptAcknowl
edgment
Type
AcceptAcknowl
edgment
Type

ID

ID

Data Type
Component
Mapping
Req'd?

Message
Information
Model

Conf

Comments

Country
Code

ID

O

Mapped Country
Code to AD data
type. See Table
Below.

Character
Set

ID

O

Part of the XML
preamble

Principal
LanguageofMessage

CE

O

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.langua
geCode

CE
CWE

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

105

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Message
Information
Model

Data
Type

Conf

Y

R

Components

Data
Type

Identifier

ST

Text

ST

O

Y

R

Name of coding
system

IS

O

Y

R

Alternate
Character
Set
Handling
SchemeID

O

ConformanceStatement
ID

ID

O

Conf

Attribute
Name

Data Type
Component
Mapping
Req'd?

EVN
Event
Type
Code

ID

Recorded
Date/TimeTS

R

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.code

CD
CWE

O

R

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.effectiv
eTime

IVL<
TS>

O

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.effectiv
eTime

IVL<
TS>

O

Date/TimeNMO

Degree ofPrecision

STO

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

106

Copyright © 2015: IHE International, Inc.

Comments

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Message
Information
Model

Attribute
Name

Data
Type

RE

MFMI_RM700200 Registry
Control Act

ControlActPr
ocess.reason
Code

SET
<CE>
CWE

R

MFMI_RM700200 Registry
Control Act

dataEnterer.t
ypeCode

CE
CWE

Data
Type

Conf

TS

O

Date/TimeNMO

Degree ofPrecision

ST

O

Components

Date/Time Of
Planned
Event

Event
ReasonCode

IS

OperatorID

XCN

ID Number (ST)Family Name

ST

FN

R

O

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

Data Type
Component
Mapping
Req'd?

Conf

O

Y

Y

Y

R

R

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
00

R

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

107

Comments

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

given name

Second or othergiven names or
initials thereofsuffix (e.g., JR orIII)

prefix (e.g., DR)degree (e.g.,
MD)

Data
Type

ST

ST

ST

ST

IS

Version 3 Message

Conf

O

O

O

O

O

Message
Information
Model

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Y

Y

Y

Y

Y

Conf

R

R

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

108

Comments
Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
01 - PN data type

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

source tableassigningauthority

name type code

Identifier check
digit

Code identifying
the check digit
schemeemployed

Data
Type

IS

HD

ID

ST

ID

Version 3 Message

Conf

O

R

O

O

O

Message
Information
Model

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Y

Y

Y

Y

Y

Conf

R

R

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

109

Comments
Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data type

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

identifier typecode (IS)assigning facility

Name
Representation
code

name context

name validity
range

Data
Type

IS

HD

ID

CE

DR

Version 3 Message

Conf

R

R

O

O

O

Message
Information
Model

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

MFMI_RM700200 Registry
Control Act

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Y

Y

Y

Y

Y

Conf

R

R

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeR

Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

110

Comments
Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data type

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

name assembly
order

Data
Type

Version 3 Message

Conf

ID

O

TS

O

Date/TimeNMO

Degree ofPrecision

ST

O

Event
Occurred

Event
Facility

Message
Information
Model

Attribute
Name

Data
Type

MFMI_RM700200 Registry
Control Act

MCCI_RM000100 - Send
Message
PayloadData Type
Component
Mapping
Req'd?

SET
<II>

R

Y

R

MappedSET<II> data
type components
to v2.5 HD
components. See
table above.

HD

O

Namespace ID

IS

O

Y

R

Universal ID

ST

O

Y

R

Universal ID
type

ID

O

Y

R

PID

Patient
Identifier
List

CX

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

111

Comments
Map to CMET(ASSIGNED)
R_AssignedPerson (universal)
COCT_MT0901
07 - II data typeY

Organization.
id

Conf

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

ID

Data
Type

ST

Version 3 Message

Conf

Message
Information
Model

Attribute
Name

R

Patient.id
OtherIDs.id

Data
Type

SET<
II>

Data Type
Component
Mapping
Req'd?

Y

Check digit

ST

O

Not
applicable

Code identifying
the check digit

ID

O

Not
applicableassigningauthority

HD

R

Y

identifier typecode (ID)

ID

R

Y

assigning facility

HD

R

Y

effective date
(DT)

DT

RE

expiration dateDT

RE

Patient
Name

XPN

Family NameFN

RE

Patient.effectiveTime

IVL<
TS>

N

Conf

R

O

Y
PRPA_RM2
01301IHE Patient
Activate/Rev
ise

R

Person.name

LIST
<PN>

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

Comments
Mapped II data
type components
to v2.5 CX
components. See
table above.

112

Copyright © 2015: IHE International, Inc.

MappedLIST<PN> andII data types
components tov2.5 XPN
components. See

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Mother's
MaidenName

Version 3 Message

Message
Information
Model

Components

Data
Type

Conf

given name

ST

O

Y

Second or othergiven names or
initials thereof

ST

O

Y

suffix (e.g., JR or
III)

ST

O

Y

prefix (e.g., DR)

ST

O

Y

degree (e.g.,
MD)

IS

O

Y

name type code

ID

R

Y

Name
Representation
code

ID

O

Y

name validity
range

DR

O

Y

name assembly
order

ID

O

Y

XPN

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

ParentClient.
id

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

113

Copyright © 2015: IHE International, Inc.

Comments
Table Below.

Reference
CMET
COCT_MT0302
00. Map
LIST<PN> andII data types
components tov2.4 CXIHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Date/Time of Birth

Version 3 Message

Message
Information
Model

Components

Data
Type

Conf

Family Name

FN

R

Y

given name

ST

O

Y

Second or othergiven names or
initials thereof

ST

O

Y

suffix (e.g., JR or
III)

ST

O

Y

prefix (e.g., DR)

ST

O

Y

degree (e.g.,
MD)

IS

O

Y

name type code

ID

R

Y

Name
Representation
code

ID

O

Y

name context

CE

O

Y

name validity
range

DR

O

Y

name assembly
order

ID

O

Y

TS

RE

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

PRPA_RM2
01301IHE Patient
Activate/Rev

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

114

Copyright © 2015: IHE International, Inc.

Comments
components.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Components

Data
Type

Conf

Date/Time

NMR

Degree ofPrecision

ST

O

Message
Information
Model
ise

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

XPN

O

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Family Name

FN

O

given name

ST

Second or othergiven names or
initials thereof

Administ
rativeSex

IS

Patient
Alias

Data Type
Component
Mapping
Req'd?

Attribute
Name

Data
Type

Person.birthT
ime

TS

O

Person.admin
istrativeGend
erCode

CS
CNE

R

Conf

Mapped PN and
II data types
components tov2.5 XPN
components. See
table above.
Person.name

BAG
<PN>

Y

R

O

Y

R

ST

O

Y

R

suffix (e.g., JR or
III)

ST

O

Y

R

prefix (e.g., DR)

ST

O

Y

R

degree (e.g.,

IS

O

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

115

Comments

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Message
Information
Model

Conf

name type code

ID

O

Y

R

Name
Representation
code

ID

O

Y

R

name context

CE

O

Y

R

name validity
range

DR

O

Y

R

name assembly
order

ID

O

Y

R

Patient
Address

XAD

REstreet address
(SAD)

SAD

R

city

ST

state or provinceST

zip or postal
code
country
address type

Data
Type

Conf

Data
Type

Components
MD)

Attribute
Name

Data Type
Component
Mapping
Req'd?

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Person.addr

BAG
<AD
>

Y

R

R

Y

R

R

Y

R

ST

R

Y

R

ID

R

Y

R

ID

R

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

Comments

116

Copyright © 2015: IHE International, Inc.

Mapped AD data
type components
to v2.5 XAD
components. See
table below.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Components

Data
Type

Conf

address
representation
code

ID

O

address validity
range

DR

O

Phone
Number Home

XTN

RE

TN

R

telecommunicati
on use codeIDtelecommunicati
on equipment
type (ID)
Email address

Message
Information
Model

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

Y

R

Y

R

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Person.teleco
m

BAG
<TEL
>

Y

R

R

Y

R

ID

O

Y

R

ST

O

Y

R

Country Code

NM

O

Y

R

Area/city code

NM

O

Y

R

Phone Number

NM

O

Y

R

Extension

NM

O

Y

R

any text

ST

O

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

Comments

117

Copyright © 2015: IHE International, Inc.

Mapped TEL
data typecomponents tov2.5 XTN
components. See
table above.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

Phone
Number Business

Data
Type

Version 3 Message

Conf

Message
Information
Model

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

XTN

RE

TN

R

Y

R

telecommunicati
on use code

ID

R

Y

R

telecommunicati
on equipment
type (ID)

ID

O

Y

R

Email address

ST

O

Y

R

Country Code

NM

O

Y

R

Area/city code

NM

O

Y

R

Phone Number

NM

O

Y

R

Extension

NM

O

Y

R

any text

ST

O

Y

R

Primary
LanguageCE

Identifier

ST

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise
LanguageCo
mmunication.languageCo

O

CE
CWE

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

Comments
Mapped TEL
data typecomponents tov2.5 XTN
components. See
table above.

118

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Message
Information
Model

Data
Type

Conf

text

ST

O

R

Name of coding
system

IS

O

R

ST

Driver's
LicenseNumber Patient

DLN

Attribute
Name
de

Data
Type

Data Type
Component
Mapping
Req'd?

Components

SSN
Number Patient

Mother's
Identifier

Version 3 Message

Conf

O

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

OtherIDs.id

SET
<II>

R

O

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

OtherIDs.id

SET
<II>

R

Driver's License
Number

ST

O

Y

R

Issuing State,province,
country

IS

O

Y

R

expiration date

DT

O

Y

R

CX

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

PersonalRela
tionship.relat
ionshipHolde
r.id

II

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

119

Copyright © 2015: IHE International, Inc.

Comments

Mapped II data
type for DLN
data type. See
table above.

Mapped II data
type for CX data
type. See table
above.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Ethnic
Group

Birth
Order
Patient
Death
Date andTime

Version 3 Message

Message
Information
Model

Data
Type

Conf

ID

ST

R

Y

R

Check digit

ST

O

Y

R

check identifying
the check digit
schemeemployed

ID

O

Y

R

assigningauthority

HD

O

Y

R

identifier type
code(ID)

ID

R

Y

R

assigning facility

HD

O

Y

R

effective date
(DT)

DT

O

Y

R

expiration date

DT

O

Y

R

CE

O

NM

TS

RE

RE

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Data
Type

Conf

Components

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Attribute
Name

Data Type
Component
Mapping
Req'd?

Person.multi
pleBirthOrde
rNumberR

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

120

Copyright © 2015: IHE International, Inc.

Comments

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Components

Data
Type

Version 3 Message

Data Type
Component
Mapping
Req'd?

Conf

Message
Information
Model

Attribute
Name

Data
Type

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Person.decea
sedTimeTS

O

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Person.decea
sedIndBL

O

Date/TimeNMO

Degree ofPrecision

ST

O

Conf

Comments

Patient
Death
Indicator

ID

RE

Last
UpdateDate/TimeTS

O

Metadata

Date/TimeNMO

Metadata

Degree ofPrecision

ST

O

HD

O

Metadata

Namespace ID

ISOMetadata

Universal ID

STO

Metadata

Universal ID
type

ID

O

Metadata

Last
UpdateFacility

NK1

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

121

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Data Type
Component
Mapping
Req'd?

Conf

Message
Information
Model

Attribute
Name

R

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

PersonalRela
tionship.id

XPNO

COCT_MT030207UV –E_Person(informational) CMETY

R

family name

FN

O

Y

R

given name

ST

O

Y

R

Second or othergiven names or
initials thereof

ST

O

Y

R

suffix (e.g., JR or
III)

ST

O

Y

R

prefix (e.g., DR)

ST

O

Y

R

degree (e.g.,
MD)

IS

Y

R

name type code

ID

O

Y

R

Name
Representation
code

ID

O

Y

R

name context

CE

O

Y

R

name validity
range

DR

O

Y

R

Components

Set ID NK1

Data
Type

SI

Name

Person.name

Data
Type

LIST
<PN>

Conf

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

122

Copyright © 2015: IHE International, Inc.

Comments

Mapped PN data
type components
to v2.5 XPN
components. See
table above.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Components

Data
Type

Conf

name assembly
order

ID

O

Relationship

Message
Information
Model

PRPA_RM2
01301IHE Patient
Activate/Rev
ise

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

Y

R

PersonalRela
tionship.codeCER

identifier

ST

O

text

ST

O

Name of coding
system

IS

O

TS

O

Date/Time

NM

O

Y

R

Degree ofPrecision

ST

O

Y

R

Date/Time of Birth

Next of
Kin/Asso
ciatedParty's
Identifiers

R

R

COCT_MT030207UV –E_Person(informational) CMET

Person.id

Mapped II data
type to CX data
components. See
table above.

SET<
II>

CX

R

ID

ST

R

Y

R

Check digit

ST

O

Y

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

Comments

123

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Version 2.5 Conformance Profile

Message
Segment

Field
Name

Version 3 Message

Message
Information
Model

Attribute
Name

Data
Type

Data Type
Component
Mapping
Req'd?

Conf

Components

Data
Type

Conf

check identifying
the check digit
schemeemployed

ID

O

Y

R

assigningauthority

HD

R

Y

R

identifier type
code(ID)

ID

R

Y

R

assigning facility

HD

R

Y

R

2335

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

124

Copyright © 2015: IHE International, Inc.

Comments

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix S:

Intentionally Left Blank

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

125

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix T:

2340

2345

Use of eMail (Informative)

The off-line mode protocol uses the classical email exchange, based on SMTP server(s) as well
as a POP3 server storing the recipient mailbox. The different steps of the exchange are described
below, depending on the success or failure status of the exchange. The mechanism may besimilar and use the evolution of these protocols (ESMTP, EMAP4). The Document Source andthe Document Recipient shall at least support SMTP and POP3, but they may also support
ESMTP and EMAP or similar. The example may also apply for a Document Repository when
the off-line protocol binding is used.
In case the message cannot reach the Document Recipient POP3 server, the diagram is thefollowing:

SMTP
Server

SMTP
Server3

1

POP3Server

2

Pb

mail
box

Document
SourcePOP3ServerDocument
Recipient

45SMTP
Servermailbox

Figure T-1: Exchange diagram when the message is sent with error

2350
Where the steps are:
1. Initial message sent by the Document Source to its SMTP server2355

2. Transfer of this message to the Document Recipient POP3 server, potentially through anumber of other SMTP servers acting as relays, but with a problem arising (which could
be also at the POP3 Server level as “user email unknown” or “over quota exceeded in thedestination mailbox”). An error message “Delivery Status Notification” (DSN) is
generated by the server where the problem occurs, and sent back to the sender (using its“reply to” address if present, its “from” address otherwise)
3. Reception of the negative DSN message by the Document Source POP3 server

2360

4. Store of the received message by the POP3 server in the mail box dedicated to theDocument Source
5. Query and retrieve of the message by the Document Source from its mailbox (andnormally deletion of this message).
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

126

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
In case the message reaches the Document Recipient POP3 server, the diagram is the following:
SMTP
ServerPOP3Server2

SMTP
Server

1

3

mail
box

Document
SourcePOP3Server9

5

4Document
Recipient

6

8

7
SMTP
Server

mail
box

2365
Figure T-2: Exchange diagram when the message is successfully sent

Where the steps are:
1. Initial message sent by the Document Source to its SMTP server
2370

2. Transfer of this message to the Document Recipient POP3 server, potentially through anumber of other SMTP servers acting as relays
3. Store of the received message by the POP3 server in the mail box dedicated to theDocument Recipient2375

4. Query and retrieve of the message by the Document Recipient from its mailbox (andnormally deletion of this message).
5. Local confirmation of the success (or failure) when it “processes” the message inside theDocument Recipient (which could be that the user has read the message or at least that it
has been correctly imported in the EHR)

2380

6. Generation by the Document Recipient of a “Message Delivery Notification” message,
that can be positive (respectively negative with the status)
7. Reception of the positive MDN message by the Document Source POP3 server
8. Store of the received message by the POP3 server in the mailbox dedicated to theDocument Source

2385

9. Query and retrieve of the message by the Document Source from its mailbox (andnormally deletion of this message).

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

127

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Document
SourcePOP3Server

SMTP
Server

SMTP
ServerPOP3ServerDocument
RecipientCreate themetadata,
the MIME
body, sign
& encrypt it
Send RFC822 message

Route RFC822 message
Store inmail box

Route MDN message

Retrieve mails
Decrypt,verify thesignature,
extract &process
metadata, &document(s)Send MDN message

Store inmail box
Retrieve mails
CheckstatusFigure T-3: Sequence diagram of a secured message exchange

2390

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

128

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix U:

Intentionally Left Blank

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

129

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

Appendix V:

Web Services for IHE Transactions

2395

V.1: Introduction

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

V.2: Relevant Standards

2405

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

2410

2415

The Web Services for IHE transactions will be based on SOAP 1.2, and as such they takeadvantage of the guidelines expressed in the WS-I Basic Profile 2.0 (BP 2.0). Some IHE
transactions may also take advantage of the WS-I Basic Security Profile 1.1 (BSP 1.1) and WS-I
Reliable Secure Profile 1.0 (RSP 1.0) where applicable.
For the rare cases, where IHE transactions may need to support SOAP 1.1 in addition to therequired SOAP 1.2 version, the appendix provides the corresponding requirements following theguidelines from WS-I Basic Profile 1.2 (BP 1.2).
V.2.2: WS-* Specifications
Based on the requirements of the current WS-I profiles, the Web Services for IHE transactions
support the following Web Services standards:

2420

•

WS-Addressing

•

MTOM

•

XOP

•

WS-Security

The WS-I Reliable Secure Profile combines several of the above WS-* standards, as well as
including:
2425•

WS-SecureConversation•

WS-Trust

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

130

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2430

•

WS-Policy•

WS-ReliableMessaging

In the future, the Web Services for IHE transactions will consider support for this new WS-I
profile, or particular WS-* standards as needed by specific use cases.
V.2.3: HL7 Web Services Profile

2435

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

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

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:
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

131

Copyright © 2015: 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.
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 replacedwith 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 replacedwith a string corresponding to the specific transaction, or shall be completely omitted.

2450

V.3.1: Requirements for Transactions using HL7 V3 Messages
2455

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:

2460

HL7 WS Basic Profile Constraints

The Sender and Receiver shall conform to the HL7 WS Basic Profile with five 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).

2465

2470

2475

2480

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).
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).
The fifth modification is to HL7-WSP208, which specifies that “WSDL messages forInteractions SHOULD use wsdl:operation/wsdl:input/@wsa:Action = "urn:hl7org:v3:{Interaction_Artifact_Id}”. IHE extends the “should” to support situations where one
HL7 message is being used within two transactions for significantly different purposes. For thiscase the second use of the message shall extend the HL7 specified Action string with“:[transaction-name]” where [transaction-name] is the name of the second transaction.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

132

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
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.
2485

2490

V.3.1.3:

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:

2495

HL7 WS Security Profile Constraints

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

2500

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.

2505

The numbering scheme for the individual requirements uses the following convention:
•

2510

2515

IHE-WS[P|A|S|RM]nnn[.e]) text

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.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

133

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
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

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.
SOAP message consumers shall ignore any soapAction value
found in a SOAP message.

Determines the valueof soapAction

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

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

134

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Requirement
Identifier

2520

2525

Requirement text

SOAP message
format affected?

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” or“true”)

Ensures that web
services frameworks
are configured toproperly generate andprocess WSAddressing headers

IHE_WSA102

The <wsa:ReplyTo> element of the initiating message
shall be present. (See Note 1)

Ensures that responses
are routed to theappropriate webservices end point, oras an immediate
response

Note 1: There may be web services toolkits which implement the WS-Addressing features improperly and may haveproblems processing a wsa:ReplyTo header with a mustUnderstand attribute set to true. Implementers of SOAP
clients are advised to plan for mitigating the impact of toolkits with deficient implementation of WS-Addressing
by putting the mustUnderstand attribute only on other header(s).

V.3.2.1:

Basic Requirements

V.3.2.1.1.

Naming conventions and namespaces

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.

2530

IHE-WSP201)
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 (e.g., DocumentRegistry is the NAME value for the XDS.b
Document Registry Actor). Specifically, NAME is the value of the/wsdl:definitions/@name attribute 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 (e.g., RegistryStoredQuery is the
TRANSACTION_for the XDS.b Registry Stored Query Transaction)

2535

2540

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

135

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________WSDL Artifact

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

message request-> "RegistryStoredQuery_Message"

message response-> RegistryStoredQueryResponse_Message

portType-> "DocumentRegistry_PortType"operation-> "DocumentRegistry_RegistryStoredQuery_Request"

SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port

2550-> "DocumentRegistry_Port_Soap12"

SOAP 1.1 binding -> "DocumentRegistry_Binding_Soap11"
SOAP 1.1 port-> "DocumentRegistry_Port_Soap11"

IHE-WSP202)
IHE requires the use of the following naming convention for targetNamespace of example
WSDL.
2555

•

DOMAIN – represents the acronym of the IHE domain who authored this web-service
transaction (e.g., iti)•

PROFILE – represents the acronym of the IHE profile which references this web-service
transaction (e.g., 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

2560

The targetNamespace of the example WSDL shall beurn:ihe:{DOMAIN}:{PROFILE}:{YEAR} and may be extended to2565

urn:ihe:{DOMAIN}:{PROFILE}:{YEAR}:{TYPE}
As an example the namespace for the 2008 XDS.b Integration Profile is urn:ihe:iti:xdsb:2007.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

136

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
IHE-WSP203) The example WSDL shall include XML Schema Definition references for thetransactions payloads.
2570

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:

2575

Message and portType Definitions

IHE-WSP205) Two WSDL messages shall be defined for a request-response transaction.
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.

2580

IHE-WSP207) For each input and output message defined in the WSDL portType operation an
attribute wsaw:Action SHALL be included.
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.

2585

2590

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

2595

V.3.2.1.3:

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.

2600

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.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

137

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2605

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.

2610

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.

2615

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

2620

2625

2630

2635

2640

2645

<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"/>HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

138

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2650

2655

2660

2665

2670

2675

2680

2685

2690

2695

2700

</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"
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">
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

139

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2705

2710

2715

2720

2725

2730

2735

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

2740

2745

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

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

140

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2750

response), 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.
IHE-WSA101) All <wsa:Action> elements shall have the mustUnderstand attribute set(mustUnderstand=”1” or “true”)

2755

IHE-WSA102) The <wsa:ReplyTo> element of the initiating message shall be present.
Note: There may be web services toolkits which implement the WS-Addressing features improperly and may haveproblems processing a wsa:ReplyTo header with a mustUnderstand attribute set to true. Implementers of SOAP
clients are advised to plan for mitigating the impact of toolkits with deficient implementation of WS-Addressing
by putting the mustUnderstand attribute only on other header(s).

2760

Example 2: Request Message
Example 2.a: Request Message using Synchronous Web Services Exchange

2765

2770

2775

2780

2785

2790

2795

<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-b41b-7a15f4f46fb9</wsa:MessageID><wsa:ReplyTo ><wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address></wsa:ReplyTo><wsa:To>
http://localhost:2647/XdsService/IHEXDSRepository.svc</wsa:To></soap12:Header><soap12:Body><ProvideAndRegisterDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"/></soap12:Body></soap12:Envelope>

Example 2.b: Request Message using Asynchronous Web Services Exchange<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-b41b-7a15f4f46fb9</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://example.com:2647/XdsService/DocumentSourceReceiver.svc</wsa:Address></wsa:ReplyTo><wsa:To soap12:mustUnderstand="1">
http://example.com:2647/XdsService/DocumentRepositoryReceiver.svc</wsa:To></soap12:Header><soap12:Body><ProvideAndRegisterDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"/></soap12:Body></soap12:Envelope>

Example 3: Response Message
Example 3.a: Response Message using Synchronous Web Services Exchange
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

141

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2800

2805

2810

<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-b41b-7a15f4f46fb9</wsa:RelatesTo></soap12:Header><soap12:Body><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></soap12:Body></soap12:Envelope>

Example 3.b: Response Message using Asynchronous Web Services Exchange
2815

2820

2825

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"><soap:Header><wsa:Action soap12:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSetbResponse</wsa:Action><wsa:MessageID>urn:uuid:d6c21225-8e7b-454e-9750-821622c099db</wsa:MessageID><wsa:RelatesTo>urn:uuid:1600bc1a-10fd-4c3a-b41b-7a15f4f46fb9</wsa:RelatesTo><a:To
s:mustUnderstand="1">http://example.com:2647/XdsService/DocumentSourceReceiver.svc</a:To></soap12:Header><soap12:Body><rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/></soap12:Body></soap12:Envelope>

V.3.2.3:

2830

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.

2835

V.4: Web Services for specific IHE Transactions

2840

The Web Services specification is provided in three parts. The first part will be in Volumes 2a,2b and 2c, where a separate subsection shall be added for each affected IHE transaction at theend of the “Message Semantics” section. This subsection shall detail the types and message partsof 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.

2845

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, 2b and 2c
described above. There will be one WSDL contract per actor per profile. Each transaction isrepresented by a port type, where the operations names and message names follow the

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

142

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
requirements specified in SectionV.3.2.1.1. The complete WSDL is for reference purposes for
implementers.

V.5: Synchronous and Asynchronous Web Services Exchange
V.5.1: Overview
2850

When two actors, later referred to as Requestor and Provider, need to exchange web services
messages using a request-response message exchange pattern, they can do so synchronously or
asynchronously.

2855

With synchronous message exchange, the Requestor sends a request and blocks waiting for a
response from the Provider. The Requestor receives the response on the same connection that theRequestor initially established to send the request. Synchronous exchange is usually easier toimplement and requires that the Provider be available when the Requestor needs to send arequest.

2860

With asynchronous message exchange, the Requestor is only concerned with sending the request,
knowing that it will ‘eventually’ receive a response. The Provider may not be available at thetime the request is sent. When the Provider receives and processes the message it sends a
response back to the Requestor over a new connection. Asynchronous Web Services Exchange
enables support for network infrastructures where:

2865

2870

•

Transports are unreliable•

Systems are not always available•

Variable or high communication latency is present

Asynchronous Web Services Exchange opens the option for using intermediaries for store andforward or offline communication modes, and leveraging reliable messaging mechanisms toaddress the reliability and availability challenges that these types of network infrastructures
present. Asynchronous Web Services Exchange enables support for clinical use cases that canbenefit from asynchronous infrastructure capabilities such as offline mode.
V.5.2: Considerations for using Asynchronous Web Services Exchange

2875

Asynchronous Web Services Exchange opens the option for using intermediaries for store andforward or offline communication modes, and leveraging reliable messaging mechanisms toaddress the reliability and availability challenges that these types of network infrastructures
present. Asynchronous Web Services Exchange enables support for clinical use cases that canbenefit from asynchronous infrastructure capabilities such as offline mode.
Adding support for asynchronous exchange should take into consideration the fact that:•

The request and response messages are decoupled and transmitted on separate
connections as shown in Figure V.5.2-1 below.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

143

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2880

2885

•

The Requestor will ‘unblock’ before it receives the response. The response will bereceived asynchronously at a later time. Having decoupled request/response exchange
should draw attention to the following:•

The Requestor should have response timeout capability to handle the case when a
response has not been received within expected time interval•

The Requestor should be able to match request/response pairs
Synchronous

Requestor

Request-Response

ProviderAsynchronous
RequestRequestor

Response

ProviderFigure V.5.2-1: Request and Response Messages

V.5.3: Specification of the use of Asynchronous Web Services Exchange
2890

Volume 2a, 2b and 2c transaction specifications will identify whether asynchronous support isrequired or optional on the transaction level. If nothing is specified in Volume 2a/2b/2c, only
synchronous exchange is expected. When optional asynchronous support is applicable to atransaction, the profile specification in ITI TF-1 will identify that support as required for actors
in that profile or as a named option.

2895

V.6: Web Services Standards Evolution
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.7: Web Services References2900

WS-I: http://ws-i.org/
WS-I Basic Profile 1.2: http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html
WS-I Basic Profile 2.0: http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

144

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
SOAP 1.1: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
SOAP 1.2: http://www.w3.org/TR/soap12-part0/2905

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

2910

WS-I Basic Security Profile 1.1: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html
WS-I Reliable Secure Profile: http://www.ws-i.org/Profiles/ReliableSecureProfile-1.0-2010-1109.html
MTOM: http://www.w3.org/TR/soap12-mtom/
XOP: http://www.w3.org/TR/xop10/

2915

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

WS-Secure Conversation: http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/wssecureconversation.html
WS-Trust: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-oscomplete.html
WS-Policy: http://www.w3.org/TR/ws-policy/
WS-Reliable Messaging: http://docs.oasis-open.org/ws-rx/wsrm/200702

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

145

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________

2925

Appendix W:

Implementation Material

Implementation material for ITI profiles such as XDS, XCA, RFD, and others 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.
2930

Appendix X: Basic Unstructured Workflow Definition Example
This is a Workflow Definition example that is intended to be used in conjunction with XDWProfile.

X.1 Workflow definition identifier
2935

Basic Unstructured Workflow is a very simple workflow in which a group ofphysicians/organizations act on the same patient in an a priori unpredictable way.
This workflow is performed to allow the continuity of care for a patient in a generic and flexible
way.

2940

We expect actual deployment to modify this example when developing basic workflows. It has
two simple types of Tasks: the first one is useful for recording and sharing single user actions (“Idid this task”) and the second one used to request that a task be performed by anotherorganization and reporting its completion (“please do this, I did it”).
Any specific workflow can include any combination of these two types of tasks. This example
shows no dependencies among the tasks that are explicitly managed.

2945

The catalog of task that maybe used in this workflow definition is not specified by this profile,and remains to be agreed in the affinity domain where the workflow is been deployed. Thisdefinition will result in a list of names and codes for any potential task.

X.2 Workflow definition identifier
The workflow definition identifier shall be inserted into the workflowDefinitionReference
element of the Workflow Document.
2950
Workflow Definition name
Basic Unstructured Workflow

workflowDefinitionReference
An “urn:oid” reference to a Workflow definition
Document

X.3 Workflow opening and closing
The workflow should be opened by a physician or an Organization that participate in theworkflow (e.g., continuity of care process). Any participant may choose to close the workflow.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

146

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
2955

X.4 Tasks descriptions
X.4.1 Task type “born completed”

2960

Tasks of the type “born completed” are used by any workflow participant when the workflow is
open or at any later point in time. This type is used for a workflow in which a participant want toshare some actions perform in his enterprise on the patient. Typical examples can be a visit, or an
emergency admission, or a patient self-monitoring event.
Task attributes

Rules for the task “born completed”

Task dependencies

noneStates allowed

COMPLETEDStates transactions

None

input

Zero or more clinical document of unconstrained types

outputZero or more clinical document of unconstrained types

ownerevery physician/organization

owner changes

No<taskEvent>

Only one

X.4.2 Task type “two states task”
2965This type of task is used by any workflow participant when the workflow is open or at any later
point in time. This task type is used for a workflow in which a participant wants to share someactions performed in his enterprise on the patient. Typical examples can be a visit, or an
emergency admission, or a patient self-monitoring event.
Task attributes

Rules for the task “two states task”

Task dependencies

NoneStates allowed

CREATEDCOMPLETEDStates transactions

When a workflow participant request that this task be performed byanother workflow participant he places the task in a Workflow
Document with CREATED status (no owner). When the requested
task is performed by a participant the task status shall be
COMPLETED.

input

Zero or more clinical document of unconstrained types (e.g.,eReferral Document, ePrescription)

outputZero or more clinical document of unconstrained types (e.g., reports,
radiological images, advice documents, dispensation documents)

owner

any physician/organization that process this task in CREATED state

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

147

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________
Task attributes

Rules for the task “two states task”

changes of task owner

Allowed<taskEvent>At least two

2970

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

148

Copyright © 2015: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 2x (ITI TF-2x): Appendices______________________________________________________________________________GLOSSARY
See IHE Technical Frameworks Appendix D: Glossary

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

_____________________________________________________________________________
Rev. 12.0 Final Text – 2015-09-18

149

Copyright © 2015: IHE International, Inc.