Integrating the Healthcare Enterprise

5

10

IHE Radiology (RAD)Technical Framework
Volume 3
IHE RAD TF-3
Transactions (continued)

15

20

Revision 13.0 Final Text
July 30, 201425

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________CONTENTS
30

35

40

45

50

55

60

65

70

1 Introduction .............................................................................................................................. 14
1.1 Overview of Technical Framework .................................................................................. 14
1.2 Overview of Volume 3...................................................................................................... 15
4 IHE Transactions ...................................................................................................................... 16
4.32 Authenticate Node - Deprecated ....................................................................................... 16
4.33 Maintain Time - Deprecated ............................................................................................. 16
4.34 Record Audit Event - Deprecated ..................................................................................... 16
4.35 Charge Posted ................................................................................................................... 16
4.35.1
Scope .................................................................................................................. 16
4.35.2
Use Case Roles ................................................................................................... 174.35.3
Referenced Standards ......................................................................................... 174.35.4
Interaction Diagram ............................................................................................ 174.35.4.1
Financial Transaction Message ................................................................. 174.35.4.1.1 Trigger Events ........................................................................................... 174.35.4.1.2 Message Semantics ................................................................................... 18
4.35.4.1.2.1 MSH Segment .................................................................................... 19
4.35.4.1.2.2 EVN Segment .................................................................................... 19
4.35.4.1.2.3 PID Segment ...................................................................................... 19
4.35.4.1.2.4 PV1 Segment ..................................................................................... 19
4.35.4.1.2.5 FT1 Segment ...................................................................................... 20
4.35.4.1.2.6 PR1 Segment – Procedures ................................................................ 21
Sources of Information ............................................................................. 21
4.35.4.2
4.35.4.2.1.1 Expected Actions ............................................................................... 26
4.36 Account Management ....................................................................................................... 26
4.36.1
Scope .................................................................................................................. 26
4.36.2
Use Case Roles ................................................................................................... 27
Referenced Standards ......................................................................................... 27
4.36.34.36.4
Interaction Diagram ............................................................................................ 27
4.36.4.1
Account Management - New Account ...................................................... 27
4.36.4.1.1 Trigger Events ........................................................................................... 27
4.36.4.1.2 Message Semantics ................................................................................... 28
4.36.4.1.2.1 MSH Segment .................................................................................... 28
4.36.4.1.2.2 EVN Segment .................................................................................... 29
4.36.4.1.2.3 PID Segment ...................................................................................... 29
4.36.4.1.2.4 PV1 Segment ..................................................................................... 29
4.36.4.1.2.5 DG1 Segment..................................................................................... 29
4.36.4.1.2.6 GT1 Segment ..................................................................................... 30
4.36.4.1.2.7 IN1 Segment ...................................................................................... 32
4.36.4.1.3 Expected Actions ...................................................................................... 33
4.36.4.2
Account Management – Update Account ................................................. 33
4.36.4.2.1 Trigger Events ........................................................................................... 33
4.36.4.2.2 Message Semantics ................................................................................... 33
4.36.4.2.2.1 MSH Segment .................................................................................... 34
2Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

75

80

85

90

95

100

105

110

115

4.36.4.2.2.2 EVN Segment .................................................................................... 34
4.36.4.2.2.3 PID Segment ...................................................................................... 34
4.36.4.2.2.4 PV1 Segment ..................................................................................... 35
4.36.4.2.2.5 DG1 Segment..................................................................................... 35
4.36.4.2.2.6 GT1 Segment ..................................................................................... 35
4.36.4.2.2.7 IN1 Segment ...................................................................................... 35
4.36.4.2.3 Expected Actions ...................................................................................... 35
4.36.4.3
Account Management – End Account ...................................................... 36
4.36.4.3.1 Trigger Events ........................................................................................... 36
4.36.4.3.2 Message Semantics ................................................................................... 36
4.36.4.3.2.1 MSH Segment .................................................................................... 36
4.36.4.3.2.2 EVN Segment .................................................................................... 36
4.36.4.3.2.3 PID Segment ...................................................................................... 36
4.36.4.3.2.4 PV1 Segment ..................................................................................... 37
4.36.4.3.3 Expected Actions ...................................................................................... 37
4.37 Query Post-Processing Worklist ....................................................................................... 37
4.37.1
Scope .................................................................................................................. 37
4.37.2
Use Case Roles ................................................................................................... 38
4.37.3
Referenced Standards ......................................................................................... 38
4.37.4
Interaction Diagram ............................................................................................ 38
4.37.4.1
Query General Purpose Worklist Message ............................................... 38
4.37.4.1.1 Trigger Events ........................................................................................... 38
4.37.4.1.2 Message Semantics ................................................................................... 39
4.37.4.1.2.1 Matching Keys and Return Keys ....................................................... 39
4.37.4.1.2.2 Examples for the Use of Matching Key Attributes ........................... 40
4.37.4.1.2.3 Matching Keys and Return Keys ....................................................... 40
4.37.4.1.3 Expected Actions ...................................................................................... 44
4.37.4.2
Receive General Purpose Worklist Message ............................................ 44
4.37.4.2.1 Trigger Events ........................................................................................... 44
4.37.4.2.2 Message Semantics ................................................................................... 44
4.37.4.2.3 Expected Actions ...................................................................................... 45
4.38 Workitem Claimed ............................................................................................................ 45
4.38.1
Scope .................................................................................................................. 45
4.38.2
Use Case Roles ................................................................................................... 45
4.38.3
Referenced Standards ......................................................................................... 46
4.38.4
Interaction Diagram ............................................................................................ 46
4.38.4.1
General Purpose Scheduled Procedure Step In Progress/Suspend Message
46
4.38.4.1.1 Trigger Events ........................................................................................... 46
4.38.4.1.2 Message Semantics ................................................................................... 47
4.38.4.1.3 Expected Actions ...................................................................................... 47
4.39 Workitem Performed Procedure Step In Progress ............................................................ 47
4.39.1
Scope .................................................................................................................. 47
4.39.2
Use Case Roles ................................................................................................... 48
4.39.3
Referenced Standards ......................................................................................... 48
3Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

120

125

130

135

140

145

150

155

160

4.39.4
Interaction Diagram ............................................................................................ 48
4.39.4.1
General Purpose Performed Procedure Step In Progress Message ........... 49
4.39.4.1.1 Trigger Events ........................................................................................... 49
4.39.4.1.2 Message Semantics ................................................................................... 49
4.39.4.1.3 Expected Actions ...................................................................................... 49
4.39.4.1.3.1 Relationship between Scheduled and Performed Procedure Steps.... 49
4.39.4.1.3.1.1
Simple Case ......................................................................... 49
4.39.4.1.3.1.2
Unscheduled Case ............................................................... 50
4.39.4.1.3.1.3
Append Case ....................................................................... 50
4.39.4.1.3.1.4
Abandoned Case .................................................................. 50
4.40 Workitem Performed Procedure Step Completed............................................................. 51
4.40.1
Scope .................................................................................................................. 51
4.40.2
Use Case Roles ................................................................................................... 51
4.40.3
Referenced Standards ......................................................................................... 51
4.40.4
Interaction Diagram ............................................................................................ 52
4.40.4.1
General Purpose Performed Procedure Step Completed Message ........... 52
4.40.4.1.1 Trigger Events ........................................................................................... 52
4.40.4.1.2 Message Semantics ................................................................................... 52
4.40.4.1.3 Reporting Message Semantics .................................................................. 52
4.40.4.1.4 Expected Actions ...................................................................................... 53
4.41 Workitem Completed ........................................................................................................ 53
4.41.1
Scope .................................................................................................................. 53
4.41.2
Use Case Roles ................................................................................................... 53
Referenced Standards ......................................................................................... 54
4.41.34.41.4
Interaction Diagram ............................................................................................ 54
4.41.4.1
General Purpose SPS Completed Message ............................................... 54
4.41.4.1.1 Trigger Events ........................................................................................... 54
4.41.4.1.2 Message Semantics ................................................................................... 54
4.41.4.1.3 Expected Actions ...................................................................................... 55
4.42 Performed Work Status Update ........................................................................................ 55
4.42.1
Scope .................................................................................................................. 55
4.42.2
Use Case Roles ................................................................................................... 56
4.42.3
Referenced Standards ......................................................................................... 56
4.42.4
Interaction Diagram ............................................................................................ 57
4.42.4.1
Post-Processing Performed Procedure Step Created/Updated Message... 57
4.42.4.1.1 Trigger Events ........................................................................................... 57
4.42.4.1.2 Message Semantics ................................................................................... 58
4.42.4.1.3 Expected Actions ...................................................................................... 59
4.43 Evidence Document Stored............................................................................................... 59
4.43.1
Scope .................................................................................................................. 59
4.43.2
Use Case Roles ................................................................................................... 60
4.43.3
Referenced Standards ......................................................................................... 60
4.43.4
Interaction Diagram ............................................................................................ 60
4.43.4.1
Evidence Document Stored....................................................................... 61
4.43.4.1.1 Trigger Events ........................................................................................... 61
4Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

165

170

175

180

185

190

195

200

205

4.43.4.1.2 Message Semantics ................................................................................... 61
4.43.4.1.3 Expected Actions ...................................................................................... 61
4.43.4.1.3.1 Mammography Image Profile ......................................................... 62
4.44 Query Evidence Documents ............................................................................................. 62
4.44.1
Scope .................................................................................................................. 62
4.44.2
Use Case Roles ................................................................................................... 62
4.44.3
Referenced Standards ......................................................................................... 62
4.44.4
Interaction Diagram ............................................................................................ 63
4.44.4.1
Query Evidence Documents ..................................................................... 63
4.44.4.1.1 Trigger Events ........................................................................................... 63
4.44.4.1.2 Message Semantics ................................................................................... 63
4.44.4.1.3 Expected Actions ...................................................................................... 64
4.44.4.1.3.1 Mammography Image Profile ......................................................... 64
4.45 Retrieve Evidence Documents .......................................................................................... 64
4.45.1
Scope .................................................................................................................. 64
4.45.2
Use Case Roles ................................................................................................... 65
4.45.3
Referenced Standards ......................................................................................... 65
4.45.4
Interaction Diagram ............................................................................................ 65
4.45.4.1
Retrieve Evidence Documents .................................................................. 65
4.45.4.1.1 Trigger Events ........................................................................................... 66
4.45.4.1.2 Message Semantics ................................................................................... 66
4.45.4.1.3 Expected Actions ...................................................................................... 66
4.45.4.2
Render Evidence Documents .................................................................... 66
4.45.4.2.1 Trigger Events ........................................................................................... 66
4.45.4.2.2 Invocation Semantics ................................................................................ 66
4.45.4.2.3 Expected Actions ...................................................................................... 67
4.45.4.2.3.1 Mammography Image Profile ......................................................... 67
4.46 Query Reporting Worklist................................................................................................. 67
4.46.1
Scope .................................................................................................................. 67
4.46.2
Use Case Roles ................................................................................................... 68
4.46.3
Referenced Standards ......................................................................................... 68
4.46.4
Interaction Diagram ............................................................................................ 68
4.46.4.1
Query General Purpose Worklist Message ............................................... 68
4.46.4.1.1 Trigger Events ........................................................................................... 69
4.46.4.1.2 Message Semantics ................................................................................... 69
4.46.4.1.2.1 Matching Keys and Return Keys ....................................................... 69
4.46.4.1.2.2 Examples for the Use of Matching Key Attributes ........................... 70
4.46.4.1.2.3 Matching Keys and Return Keys ....................................................... 70
4.46.4.1.3 Expected Actions ...................................................................................... 74
4.46.4.2
Receive General Purpose Worklist Message ............................................ 74
4.46.4.2.1 Trigger Events ........................................................................................... 74
4.46.4.2.2 Message Semantics ................................................................................... 74
4.46.4.2.3 Expected Actions ...................................................................................... 75
4.47 Distribute Imaging Information on Media ........................................................................ 75
4.47.1 Scope ........................................................................................................................ 75
5Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

210

215

220

225

230

235

240

245

250

4.47.2 Use Case Roles ......................................................................................................... 75
4.47.3 Referenced Standard ................................................................................................ 76
4.47.4 Interaction Diagram.................................................................................................. 76
4.47.4.1 Distribute Imaging Information on Media ....................................................... 76
4.47.4.1.1 Trigger Events .......................................................................................... 77
4.47.4.1.2 Message Semantics ................................................................................... 77
4.47.4.1.2.1 Media Filesystem and File Naming Restrictions .............................. 77
4.47.4.1.2.2 Content Organization Overview ...................................................... 77
4.47.4.1.2.2.1
DICOM Content .................................................................. 78
4.47.4.1.2.2.2 Web Content Option ................................................................ 78
4.47.4.1.2.2.3 Optional Content ...................................................................... 80
4.47.4.1.2.2.4 Media Identification ................................................................. 80
4.47.4.1.2.3 Content Organization Detail ............................................................ 80
4.47.4.1.2.3.1 DICOM Content ....................................................................... 80
4.47.4.1.2.3.2 Web Content Option ................................................................ 83
4.47.4.1.3 Expected Actions ...................................................................................... 84
4.47.4.1.3.2 Image Display ................................................................................... 85
4.47.4.1.3.3 Report Reader ................................................................................... 85
4.47.4.1.3.4 Portable Media Importer ................................................................... 85
4.47.4.1.3.5 Print Composer ................................................................................. 86
4.47.4.1.3.6 Display .............................................................................................. 86
4.48 Appointment Notification ................................................................................................ 86
4.48.1 Scope ........................................................................................................................ 86
4.48.2 Use CaseRoles .......................................................................................................... 86
4.48.3 Referenced Standard ................................................................................................ 87
4.48.4 Interaction Diagram.................................................................................................. 87
4.48.4.1 Appointment Notification -New Bookings ...................................................... 87
4.48.4.1.1 Trigger Events .......................................................................................... 87
4.48.4.1.2 Message Semantics ................................................................................... 88
4.48.4.1.2.1 MSH Segment ................................................................................... 88
4.48.4.1.2.2 SCH Segment .................................................................................... 88
4.48.4.1.2.3 RGS Segment .................................................................................... 89
4.48.4.1.2.4 AIS Segment ..................................................................................... 90
4.48.4.1.2.5 NTE Segment .................................................................................... 91
4.48.4.1.3 Expected Actions ...................................................................................... 92
4.48.4.2 Appointment Notification - Reschedule Bookings........................................... 92
4.48.4.2.1 Trigger Events .......................................................................................... 92
4.48.4.2.2 Message Semantics ................................................................................... 92
4.48.4.2.2.1 MSH Segment ................................................................................... 92
4.48.4.2.2.2 SCH, RGS, NTE Segments ............................................................... 93
4.48.4.2.2.2 AIS Segment ..................................................................................... 93
4.48.4.2.3 Expected Actions ...................................................................................... 93
4.48.4.3 Appointment Notification - Cancel Bookings .................................................. 93
4.48.4.3.1 Trigger Events .......................................................................................... 93
4.48.4.3.2 Message Semantics .................................................................................. 93
6
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

255

260

265

270

275

280

285

290

295

4.48.4.3.2.1 MSH Segment ................................................................................... 93
4.48.4.3.2.2 SCH, RGS, NTE Segments ............................................................... 94
4.48.4.3.2.3 AIS Segment ..................................................................................... 94
4.48.4.3.3 Expected Actions ...................................................................................... 94
4.49 Instance Availability Notification .................................................................................... 94
4.49.1 Scope ........................................................................................................................ 94
4.49.2 Use Case Roles ......................................................................................................... 94
4.49.3 Referenced Standard ................................................................................................ 95
4.49.4 Interaction Diagram.................................................................................................. 95
4.49.4.1 Instance Availability Notification .................................................................... 95
4.49.4.1.1 Trigger Events .......................................................................................... 95
4.49.4.1.2 Message Semantics ................................................................................... 96
4.49.4.1.3 Expected Actions ...................................................................................... 97
4.50 Store Instances ................................................................................................................. 97
4.50.1
Scope .................................................................................................................. 97
4.50.2
Use Case Roles ................................................................................................... 97
4.50.3
Referenced Standard ........................................................................................... 98
4.50.4
Interaction Diagram ............................................................................................ 98
4.50.4.1 Store Instances .................................................................................................. 98
4.50.4.1.1 Trigger Events .......................................................................................... 98
4.50.4.1.2 Message Semantics ................................................................................... 98
4.50.4.1.3 Expected Actions ...................................................................................... 98
4.51 Store Export Selection ..................................................................................................... 99
Scope .................................................................................................................. 99
4.51.1
4.51.2
Use Case Roles ................................................................................................... 99
4.51.3
Referenced Standard ........................................................................................... 99
4.51.4
Interaction Diagram .......................................................................................... 100
4.51.4.1 Store Export Selection .................................................................................... 100
4.51.4.1.1 Trigger Events ........................................................................................ 100
4.51.4.1.2 Message Semantics ................................................................................. 100
4.51.4.1.3 Expected Actions .................................................................................... 102
4.51.4.1.4 De-identification and Pseudonymization ................................................ 103
4.51.4.1.4.1 Baseline De-identification and Pseudonymization Requirements .. 103
4.51.4.1.4.2 Manifest Coercion ........................................................................... 104
4.51.4.1.4.3 Remap Identifiers Option ................................................................ 105
4.51.4.1.4.4 De-identify Pixel Data Option ........................................................ 106
4.51.4.1.4.5 De-identification of Non-Image Instances ...................................... 106
4.51.4.1.5 Delay for Reason .................................................................................... 107
4.52 Store Additional Teaching File Information .................................................................. 107
4.52.1
Scope ................................................................................................................ 107
4.52.2
Use Case Roles ................................................................................................. 107
4.52.3
Referenced Standard ......................................................................................... 107
4.52.4
Interaction Diagram .......................................................................................... 108
4.52.4.1 Store Additional Teaching File Information .................................................. 108
4.52.4.1.1 Trigger Events ........................................................................................ 108
7
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

300

305

310

315

320

325

330

335

340

4.52.4.1.2 Message Semantics ................................................................................. 108
4.52.4.1.3 Expected Actions .................................................................................... 108
4.53 Export Instances ............................................................................................................. 109
4.53.1
Scope ................................................................................................................ 109
4.53.2
Use Case Roles ................................................................................................. 109
4.53.3
Referenced Standard ......................................................................................... 109
4.53.4
Interaction Diagram .......................................................................................... 110
4.53.4.1 Export Instances ............................................................................................. 110
4.53.4.1.1 Trigger Events ........................................................................................ 110
4.53.4.1.2 Message Semantics ................................................................................. 110
4.53.4.1.3 Expected Actions .................................................................................... 110
4.54 Provide and Register Imaging Document Set - DEPRECATED................................... 111
4.55 WADO Retrieve............................................................................................................. 111
4.55.1 Scope ...................................................................................................................... 111
4.55.2 Use Case Roles ....................................................................................................... 111
4.55.3 Referenced Standard .............................................................................................. 112
4.55.4 Interaction Diagram................................................................................................ 112
4.55.4.1 WADO Retrieve ............................................................................................. 112
4.55.4.1.1 Trigger Events ........................................................................................ 112
4.55.4.1.2 Message Semantics ................................................................................. 112
4.55.4.1.2.1 Example of WADO Request-URI .................................................. 114
4.55.4.1.3 Expected Actions .................................................................................... 115
4.55.4.1.4 Audit Trail Trigger Events...................................................................... 115
4.59 Import Procedure Step In Progress ................................................................................ 116
4.59.1
Scope ................................................................................................................ 116
4.59.2
Use Case Roles ................................................................................................. 116
4.59.3
Referenced Standards ....................................................................................... 117
4.59.4
Interaction Diagram .......................................................................................... 117
Procedure Step In Progress Message ...................................................... 118
4.59.4.1
4.59.4.1.1 Trigger Event .......................................................................................... 118
4.59.4.1.2 Message Semantics ................................................................................. 118
4.59.4.1.2.1 Patient/Procedure/Scheduled Procedure Step Information .............. 118
4.59.4.1.2.2 Required Attributes .......................................................................... 118
4.59.4.1.2.3 Relationship between Scheduled and Performed Procedure Steps andthe Imported DICOM Composite Object ........................................ 119
4.59.4.1.2.3.1
Scheduled Import .............................................................. 119
4.59.4.1.2.3.2
Unscheduled Import .......................................................... 119
4.59.4.1.2.3.3
Performed Protocol Sequence for Import .......................... 120
4.59.4.1.3 Expected Actions .................................................................................... 120
4.60
Import Procedure Step Completed/Discontinued .................................................... 120
4.60.1
Scope ................................................................................................................ 120
4.60.2
Use Case Roles ................................................................................................. 121
4.60.3
Referenced Standards ....................................................................................... 121
4.60.4
Interaction Diagram .......................................................................................... 121
4.60.4.1
Procedure Step Completed/Discontinued ............................................... 122
8Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

345

350

355

360

365

370

375

380

385

4.60.4.1.1 Trigger Event .......................................................................................... 122
4.60.4.1.2 Message Semantics ................................................................................. 122
4.60.4.1.2.1 Retrieve AE Title ............................................................................. 123
4.60.4.1.2.2 Import PPS Exception Management ................................................ 123
4.60.4.1.2.3 Billing and Material Management Option ....................................... 124
4.60.4.1.3 Expected Actions .................................................................................... 125
4.60.4.1.3.1 Import PPS Exception Management ................................................ 126
4.60.4.1.3.2 Billing and Material Management Information Option ................... 126
4.61 Imported Objects Stored ................................................................................................ 126
4.61.1Scope ....................................................................................................................... 126
4.61.2
Use Case Roles ................................................................................................. 127
4.61.3
Referenced Standards ....................................................................................... 127
4.61.4
Interaction Diagram .......................................................................................... 127
4.61.4.1
Evidence Objects Stored ......................................................................... 128
4.61.4.1.1 Trigger Events ......................................................................................... 128
4.61.4.1.1.1 UIDs ................................................................................................. 128
4.61.4.1.2 Message Semantics ................................................................................. 128
4.61.4.1.2.1 Original Attributes Sequence ........................................................... 128
4.61.4.1.2.2 Contributing Equipment Sequence .................................................. 129
4.61.4.1.3 Expected Actions .................................................................................... 130
4.61.4.1.3.1 DICOM Storage SOP Classes ......................................................... 131
4.62 Store Dose Information ................................................................................................... 131
4.62.1 Scope ...................................................................................................................... 131
4.62.2 Use Case Roles ....................................................................................................... 131
4.62.3 Referenced Standard .............................................................................................. 132
4.62.4 Interaction Diagram................................................................................................ 132
4.62.4.1 Store Dose Information .................................................................................. 132
4.62.4.1.1 Trigger Events ........................................................................................ 132
4.62.4.1.1.1 Digitization ...................................................................................... 133
4.62.4.1.2 Message Semantics ................................................................................. 133
4.62.4.1.2.1 Cross-referencing Dose Objects and Image Objects ....................... 135
4.62.4.1.3 Expected Actions .................................................................................... 136
4.63 Submit Dose Information ............................................................................................... 136
4.63.1 Scope ...................................................................................................................... 136
4.63.2 Use Case Roles ....................................................................................................... 136
4.63.3 Referenced Standard .............................................................................................. 137
4.63.4 Interaction Diagram................................................................................................ 137
4.63.4.1 Submit Dose Information ............................................................................... 137
4.63.4.1.1 Trigger Events ........................................................................................ 137
4.63.4.1.2 Message Semantics ................................................................................. 137
4.63.4.1.2.1 De-identification ............................................................................. 139
4.63.4.1.3 Expected Actions .................................................................................... 140
4.64 Query Dose Information ................................................................................................. 141
4.64.1 Scope ...................................................................................................................... 141
4.64.2 Use Case Roles ....................................................................................................... 141
9Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

390

395

400

405

410

415

420

425

430

4.64.3 Referenced Standard .............................................................................................. 141
4.64.4 Interaction Diagram................................................................................................ 142
4.64.4.1 Query Dose Information ................................................................................. 142
4.64.4.1.1 Trigger Events ........................................................................................ 142
4.64.4.1.2 Message Semantics ................................................................................ 142
4.64.4.1.2.1 Filtering Strategies .......................................................................... 144
4.64.4.1.3 Expected Actions .................................................................................... 145
4.65 Retrieve Dose Information.............................................................................................. 145
4.65.1 Scope ...................................................................................................................... 145
4.65.2 Use Case Roles ....................................................................................................... 146
4.65.3 Referenced Standard .............................................................................................. 146
4.65.4 Interaction Diagram................................................................................................ 146
4.65.4.1 Retrieve Dose Information ............................................................................. 147
4.65.4.1.1 Trigger Events ........................................................................................ 147
4.65.4.1.2 Message Semantics ................................................................................. 147
4.65.4.1.3 Expected Actions .................................................................................... 147
4.66 Rejection Note Stored .................................................................................................... 148
4.66.1 Scope ...................................................................................................................... 148
4.66.2 Use Case Roles ....................................................................................................... 148
4.66.3 Referenced Standards ............................................................................................. 149
4.66.4 Interaction Diagram................................................................................................ 149
4.66.4.1
Rejection Note Stored (for Quality Reasons) ......................................... 150
4.66.4.1.1 Trigger Events ........................................................................................ 150
4.66.4.1.2 Message Semantics ................................................................................ 150
4.66.4.1.3 Expected Actions .................................................................................... 150
4.66.4.1.3.1 Access to Rejected Instances ........................................................... 151
4.66.4.2 Rejection Note Stored (for Patient Safety Reasons)...................................... 151
4.66.4.2.1 Trigger Events ....................................................................................... 151
4.66.4.2.2 Message Semantics ................................................................................ 151
4.66.4.2.3 Expected Actions .............................................................................. 152
4.66.4.2.3.1 Additional Requirements for Image Manager / Archive in IOCM.. 152
4.66.4.3 Rejection Note Stored (for Incorrect Modality Worklist) .............................. 152
4.66.4.3.1 Trigger Events ........................................................................................ 152
4.66.4.3.2 Message Semantics ................................................................................. 152
4.66.4.3.3 Expected Actions .................................................................................... 153
4.66.4.4 Rejection Note Stored (for Data Retention Expiry) ....................................... 153
4.66.4.4.1 Trigger Events ........................................................................................ 153
4.66.4.4.2 Message Semantics ................................................................................. 153
4.66.4.4.3 Expected Actions .................................................................................... 153
4.68 Provide and Register Imaging Document Set – MTOM/XOP ....................................... 154
4.68.1 Scope ...................................................................................................................... 154
4.68.2 Use Case Roles ....................................................................................................... 155
4.68.3 Referenced Standards ............................................................................................. 155
4.68.4 Interaction Diagram................................................................................................ 155

10
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

435

440

445

450

455

460

465

470

475

4.68.4.1 Provide and Register Imaging Document Set – MTOM/XOP Request message.......................................................................................................................... 156
4.68.4.1.1 Trigger Events ........................................................................................ 156
4.68.4.1.2 Message Semantics ................................................................................. 156
4.68.4.1.2.1 Sharing of Set of DICOM Instances ................................................ 157
4.68.4.1.2.1.1 Manifest KOS Document ........................................................ 157
4.68.4.1.2.2 Sharing of Report ............................................................................. 158
4.68.4.1.2.3 Metadata .......................................................................................... 159
4.68.4.1.2.3.1 Metadata Attributes: Author Information and Document
Creation Time ........................................................................... 159
4.68.4.1.2.3.2 XDSDocumentEntry Metadata ............................................... 160
4.68.4.1.2.3.3 Transformation of DICOM VR to XDS Document Metadata
Data Types ................................................................................ 163
4.68.4.1.2.3.4 XDS/XDS-I.b Metadata Values represented as HL7 v2.5 Data
Types ........................................................................................ 166
4.68.4.1.2.3.5 CDA Wrapper – CDA Wrapped Text Report Option ............. 167
4.68.4.1.2.4 Use of XDS Submission Set ............................................................ 171
4.68.4.1.2.4.1 Linking Report to Set of DICOM Instances ........................... 171
4.68.4.1.2.4.2 Linking Report to prior report ................................................. 172
4.68.4.1.3 Expected Actions .................................................................................... 172
4.68.4.2 Provide and Register Imaging Document Set – MTOM/XOP Response
message............................................................................................................. 172
4.69 Retrieve Imaging Document Set ..................................................................................... 173
4.69.1 Scope ...................................................................................................................... 173
4.69.2 Use Case Roles ....................................................................................................... 174
4.69.3 Referenced Standards ............................................................................................. 174
4.69.4 Interaction Diagrams .............................................................................................. 175
4.69.4.1 Retrieve Imaging Document Set Request message ........................................ 175
4.69.4.1.1 Trigger Events ........................................................................................ 175
4.69.4.1.2 Message Semantics ................................................................................. 176
4.69.4.1.3 Expected Actions .................................................................................... 176
4.69.4.2 Retrieve Imaging Document Set Response message...................................... 177
4.69.4.2.1 Trigger Events ........................................................................................ 177
4.69.4.2.2 Message Semantics ................................................................................. 177
4.69.4.2.3 Expected Actions .................................................................................... 177
4.69.4.3 Asynchronous Web Services Exchange Method ............................................ 178
4.69.5 Protocol Requirements ........................................................................................... 178
4.69.5.1
Sample SOAP Messages ......................................................................... 182
4.69.5.1.1 Sample Retrieve Imaging Document Set SOAP Request....................... 182
4.69.5.1.1.1 Synchronous Web Services Exchange ............................................ 182
4.69.5.1.1.2 Asynchronous Web Services Exchange.......................................... 183
4.69.5.1.2 Sample Retrieve Document Set SOAP Response .................................. 183
4.69.5.1.2.1 Synchronous Web Services Exchange ............................................ 183
4.69.5.1.2.2 Asynchronous Web Services Exchange.......................................... 184
4.70 – 4.73 Temporarily, intentionally, left blank ................................................................. 184
11
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

480

485

490

495

500

505

510

515

520

4.74 Replacement Instances Stored........................................................................................ 184
4.74.1 Scope ...................................................................................................................... 184
4.74.2 Use Case Roles ....................................................................................................... 185
4.74.3 Referenced Standard .............................................................................................. 185
4.74.4 Interaction Diagram................................................................................................ 185
4.74.4.1 Instances Stored .............................................................................................. 185
4.74.4.1.1 Trigger Events ........................................................................................ 185
4.74.4.1.2 Message Semantics ................................................................................. 185
4.74.4.1.2.1 Correction of Scheduled Procedure Information ............................ 187
4.74.4.1.2.2 Maintenance of Instance Reference Integrity ................................. 188
4.74.4.1.3 Expected Actions .................................................................................... 188
4.75 Cross Gateway Retrieve Imaging Document Set ........................................................... 188
4.75.1 Scope ...................................................................................................................... 189
4.75.2 Use Case Roles ....................................................................................................... 189
4.75.3 Referenced Standard .............................................................................................. 189
4.75.4 Interaction Diagram................................................................................................ 190
4.75.4.1 Cross Gateway Retrieve Imaging Document Set ........................................... 190
4.75.4.1.1 Trigger Events ........................................................................................ 190
4.75.4.1.2 Message Semantics ................................................................................. 190
4.75.4.1.3 Expected Actions .................................................................................... 190
4.75.4.2 Asynchronous Web Service Method .............................................................. 191
4.75.5 Protocol Requirements ........................................................................................... 191
4.75.5.1 Sample SOAP Messages ................................................................................ 193
4.75.5.1.1 Sample Cross Gateway Retrieve Imaging Document Set SOAP Request................................................................................................................. 193
4.75.5.1.1.1 Synchronous Web Services Exchange ............................................ 193
4.75.5.1.1.2 Asynchronous Web Services Exchange.......................................... 193
4.75.5.1.2 Sample Cross Gateway Retrieve Imaging Document Set SOAP Response................................................................................................................. 194
4.75.5.1.2.1 Synchronous Web Services Exchange ............................................ 194
4.75.5.1.2.2 Asynchronous Web Services Exchange.......................................... 195
5 Transaction Options on Other Domain Profiles ..................................................................... 196
5.1 ITI-20 Record Audit Event ............................................................................................. 196
5.1.1 Trigger Events and Message semantics.................................................................... 196
Appendix A: Deprecated ........................................................................................................ 202
Appendix B: Deprecated ........................................................................................................ 203
Appendix C: Attribute Consistency between General Purpose Worklist, SPS, PPS and
Resulting Composite IODs in Post-Processing Workflow ................................................... 204
C.1: Integration-critical Attributes.......................................................................................... 204
Appendix D: Attribute Consistency between General Purpose Worklist, SPS, PPS and
Resulting Composite IODs In Reporting Workflow.............................................................. 207
D.1: Integration-critical Attributes.......................................................................................... 207
Appendix E:
DICOM Media Interchange – Critical DICOM Compatibility Tips ................ 209
Appendix F:
Example Created Media Instance Content ....................................................... 211

12
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

525

530

Appendix G: Configuration for Accessing DICOM, WADO and Web Services Retrieve
Services
213
G.1: Mapping DICOM AE Title to DICOM AE Network Address ....................................... 213
G.2: Mapping DICOM AE Title to WADO Service Network Address ................................. 213
G.3: Mapping DICOM AE Title to Web Services Address.................................................... 214
Appendix H: Example Template for Teaching File Structured Report Manifests ................. 215
Appendix I:
De-identification, Re-identification, Pseudonymization, Persistence of
Identification and Clinical Trial Attributes (Informative) ..................................................... 219
I.1: De-identification ............................................................................................................. 219
I.2: Consistency of Identifiers on Repeated Export .............................................................. 219
I.3: Addition of Clinical Trial Attributes............................................................................... 220
GLOSSARY ............................................................................................................................... 221

13
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

535

540

545

550

555

560

1 Introduction
Integrating the Healthcare Enterprise (IHE) is an initiative that promotes the use of standards toachieve interoperability of health information technology (HIT) systems and effective use ofelectronic health records (EHRs). IHE provides a forum for volunteer committees of careproviders, HIT experts and other stakeholders in several clinical and operational domains toreach consensus on standards-based solutions to critical interoperability issues. IHE publishes theimplementation guides they produce (called IHE profiles), first to gather public comment andthen for trial implementation by HIT vendors and other system developers.
IHE provides a process for developers to test their implementations of IHE profiles, including
regular testing events called Connectathons. After a committee determines that a profile has
undergone sufficient successful testing and deployment in real-world care settings, it isincorporated in the appropriate IHE Technical Framework, of which the present document is a
volume. The Technical Frameworks provide a unique resource for developers and users of HIT
systems: a set of proven, standards-based solutions to address common interoperability issues
and support the convenient and secure use of EHRs.
Purchasers can specify conformance with appropriate IHE profiles as a requirement in requests
for proposal. Vendors who have successfully implemented IHE profiles in their products canpublish conformance statements (called IHE Integration Statements) in the IHE Product Registry(http://product-registry.ihe.net).
The current versions of this and all IHE Technical Framework documents are available at
http://www.ihe.net/Technical_Frameworks/. Comments may be submitted at
http://www.ihe.net/Radiology_Public_Comments.
IHE domain committees are responsible for developing and publishing Technical Framework
documents. This document is published by the IHE Radiology committees. Information on theactivities of this domain, including its committee rosters and how to participate, is available at
http://wiki.ihe.net/index.php?title=Domains.
General information about IHE, including its governance structure, sponsorship, member
organizations and work process, is available at www.ihe.net.

1.1 Overview of Technical Framework
565

570

This document, the IHE Technical Framework, defines specific implementations of establishedstandards to achieve integration goals that promote appropriate sharing of medical information to
support optimal patient care. It is expanded annually, after a period of public review, andmaintained regularly through the identification and correction of errata. The latest version of the
document is always available via the Internet at http://www.ihe.net/Technical_Frameworks/.
The IHE Technical Framework defines a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,
standards-based transactions. It defines this body of transactions in progressively greater depth.
Volume 1 provides a high-level view of IHE functionality, showing the transactions organized
4into functional units called Integration Profiles that highlight their capacity to address specificclinical needs. Volume 2 provides detailed technical descriptions of IHE transactions RAD-1-31,
14
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
575

defined and implemented in the first three years of the IHE initiative (1999-2001), along with adescription of the conventions used to define IHE transactions and an overview of the concepts
of IHE Actors and transactions. The present volume provides detailed technical descriptions of
IHE transactions RAD-32-69, defined and implemented in the 2002-2012 cycle of work.

1.2 Overview of Volume 3
580

585

The body of this volume is a continuation of Section 4 of volume 2. It defines transactions RAD32-69 in detail, specifying the roles for each actor, the standards employed, the informationexchanged, and in some cases, implementation options for the transaction. For a description of
the conventions used to define the standards-based transactions implemented under IHE and an
overview of the concepts of IHE actors and transactions, see volume 2 of the Technical
Framework. The appendices following the main body of this volume provide clarification oftechnical details of the IHE data model and transactions. The final section of the volume is a
glossary of terms and acronyms used in the IHE Technical Framework, including those fromrelevant standards (such as HL7, DICOM, IETF, W3C, ISO/CCITT, etc.).

15
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4 IHE Transactions
590

This section continues the definition of each IHE transaction in detail, specifying the standards
used, the information transferred, and the conditions under which the transaction is required or
optional. See Volume 2, Section 4 of the IHE Radiology Technical Framework fordescription of Transactions RAD-1 through RAD-31.

4.32 Authenticate Node - Deprecated595This transaction is identical to, and has been superseded by the Authenticate Node as part of the
ITI Audit Trail and Node Authentication Profile (ITI TF-2a: 3.19).

4.33 Maintain Time - DeprecatedThis transaction is identical to, and has been superseded by the Maintain Time as part of the ITIConsistent Time Profile (ITI TF-2a: 3.1).
600

4.34 Record Audit Event - DeprecatedThis transaction has been superseded by the Record Audit Event as part of the ITI Audit Trailand Node Authentication Profile (ITI TF-2b: 3.20) and the Radiology Audit Trail Option
described in RAD TF-3: 5.1. While the Record Audit Event ITI-20 transaction extends thisdeprecated transaction, it is still backward compatible.

605

4.35 Charge Posted
This section corresponds to Transaction RAD-35 of the IHE Technical Framework. TransactionRAD-35 is used by the Department System Scheduler/Order Filler and Charge Processor actors.
4.35.1 Scope

610

615

The Charge Posted Transaction specifies a message from the Department System
Scheduler/Order Filler to the Charge Processor. This HL7 Financial Transaction message
contains procedure data typically needed to generate a claim.
The Department System Scheduler/Order Filler provides the procedure data that is used by theCharge Processor. The Charge Processor may or may not expect the actual transaction fees
associated with the procedures included in the transaction. In some situations, the Department
System Scheduler/Order Filler is best able to match the procedure details to the appropriate fees.
In other situations, the Charge Processor performs this function. In either case, the Charge
Processor can override the fees provided by the Department System Scheduler/Order Filler.
The ways and means of ensuring the required data is complete is the responsibility of the Charge
Processor and is outside the scope of IHE.

620

Note: although IHE specifies real-time charge posted transactions, batch processing can beaccommodated as per the batch specifications defined in HL7 Chapter 2, sec. 2.23.2.

16
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.35.2 Use Case Roles
ChargeProcessor

DSS/Order
FillerChargePostedActor: Department System Scheduler/Order Filler
625

Role: Collects information relevant to the posting of charges and submits it to the Charge
Processor.
Actor: Charge Processor
Role: Receives the information from the Department System Scheduler/Order Filler. Processes
and combines charges in order to issue an insurance claim or patient’s billing statement.

630

4.35.3 Referenced Standards
Health Level Seven, Version 2.3.1: Chapter 6 - Financial Management
DICOM 2011 PS 3.4 Modality Performed Procedure Step SOP Class
4.35.4 Interaction Diagram
DSS/Order
FillerChargeProcessor
Charge Posted
DFT^P03635

4.35.4.1 Financial Transaction Message
The Detailed Financial Transaction (DFT) message is used to describe a financial transaction
transmitted between the Department System Scheduler/Order Filler and the Charge Processor.
Note that sometimes the DFT does not actually result in a financial transaction.
4.35.4.1.1

640

Trigger Events

The Department System Scheduler/Order Filler determines when the charge posted transactions
are to be sent to the Charge Processor. There are two types of financial billing transactions –Technical and Professional. Each can be triggered at a separate time or both can be sent at thesame time - depending on the site configuration.
•

Technical Billing

17
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
645

Charge posting of the Technical Billing for a procedure is typically triggered when theprocedure is completed. The Performed Procedure Step Manager sends the MPPS
Completed message to the Department System Scheduler/Order Filler. The Department
System Scheduler/Order Filler is now aware that the procedure has been completed andsends the technical charge information to the Charge Processor.
Technical Billing for certain post-processing operations, such as Mammography CAD, istriggered when the Department System Scheduler/Order Filler receive confirmation fromthe Post-processing Manager that the step has been completed. The Department System
Scheduler receives this confirmation by grouping with Post-Processing Manager; if PostProcessing Manager is grouped with Image Manager, Charge Posting of the Professional
Billing will be triggered by the Performed Work Status Update message to the
Department System Scheduler/Order Filler that specifies completion of the postprocessing operation.

650

655

•
660

665

Professional Billing
Charge posting of the Professional Billing is triggered when a report iscompleted/verified by the radiologist. When the Department System Scheduler/Order
Filler is aware that the report is completed it sends the professional charge information to
the Charge Processor.
The Department System Scheduler/Order Filler may receive confirmation from theReport Manager that the report has been completed and verified. Department System
Scheduler receives this confirmation by grouping with Report Manager. If ReportManager implements the Reporting Workflow Profile, Charge Posting of the Professional
Billing will be triggered by the Performed Work Status Update transaction that specifies
completion of the report.

4.35.4.1.2
670

675

Message Semantics

The Department System Scheduler/Order Filler uses the DFT message to convey necessary
charge posting information to the Charge Processor. The Charge Processor shall obtain therelated Patient Demographic information from the ADT Patient Registration transaction
generally received earlier.
The Department System Scheduler/Order Filler uses information from the Modality Performed
Procedure Step Completed/Discontinued transaction to verify the procedure has been completed.
This information can also include the DICOM Billing and Material Management Code Module
which provides procedure, materials and devices information.
The Charge Posted Transaction will transmit Detailed Financial Transactions (DFT) messages
using the P03 event.

680

One or more PR1 segments shall be present if additional procedures, materials or devices arepresent. It may be absent otherwise.
Note: Additional qualifications to the level of specification and HL7 profiling are stated in RAD TF-2: 2.3.

Required segments are defined below. Other segments are optional

18
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________DFT Segment

Detailed Financial
Transaction Message

Chapter in
HL7 2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

[PV1]

Patient Visit

3 (see note){FT1}

Financial Transaction

6[{PR1}]

Procedure

6

685
Note:

690

PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national appendices tothe IHE Technical framework (See RAD TF-4)

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the DFT
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
4.35.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2.2 “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of “DFT”; the second component shall have value of P03.

695

4.35.4.1.2.2 EVN Segment
The EVN segment is used to communicate necessary trigger event information to receiving
applications. See RAD TF-2: 4.1.4.1.2.1.2 for required and optional fields of the EVN segment.
4.35.4.1.2.3 PID Segment

700

All of the fields in PID segment are optional, except those listed in Table 4.35-1. See RAD TF-2:
4.1.4.1.2.1.3 for the list of all fields of the PID segment.
Table 4.35-1: IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

3

20

CX

R

00106

Patient Identifier List

5

48

XPN

R

00108

Patient Name

18

20

CX

C

00121

Patient Account Number

Adapted from the HL7 standard, version 2.3.1
4.35.4.1.2.4 PV1 Segment
705

Most of the fields in PV1 segment are optional, except those listed in Table 4.35-2. See RAD
TF-2: 4.1.4.1.2.1.4 for the list of all fields of the PV1 segment.

19
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table 4.35-2: IHE Profile - PV1 Segment
SEQ

LEN

DT

OPT

2

1

IS

R

19

20

CX

C

51

1

IS

C

TBL#

ITEM#

0004

00132

Patient Class

00149

Visit Number

01226

Visit Indicator

0326

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1
710

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Radiology Technical Framework (See RAD TF-4)
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.

715

4.35.4.1.2.5 FT1 Segment
The FT1 segment is used to post charges, credits, payments, and adjustments to patientaccounting records.
Table 4.35-3: IHE Profile - FT1 Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

O

00355

Set ID - FT1

2

12

ST

O

00356

Transaction ID

3

10

ST

O

00357

Transaction Batch ID

4

26

TS

R

00358

Transaction Date

5

26

TS

R

00359

Transaction Posting Date

6

8

IS

R

0017

00360

Transaction Type

7

80

CE

R

0132

00361

Transaction Code

8

40

ST

O

00362

Transaction Description

9

40

ST

O

00363

Transaction Description - Alt

10

6

NM

O

00364

Transaction Quantity

11

12

CP

O

00365

Transaction Amount - Extended

12

12

CP

O

00366

Transaction Amount - Unit

13

60

CE

O

0049

00367

Department Code

14

60

CE

O

0072

00368

Insurance Plan ID

15

12

CP

O

00369

Insurance Amount

16

80

PL

O

00133

Assigned Patient Location

17

1

IS

O

0024

00370

Fee Schedule

18

2

IS

O

0018

00148

Patient Type

19

60

CE

O

0051

00371

Diagnosis Code - FT1

20

120

XCN

R

0084

00372

Performed By Code

21

120

XCN

R

00373

Order By Code

22

12

CP

O

00374

Unit Cost

20
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
SEQ

LEN

23

22

EI

DT

R

OPT

TBL#

00217

Filler Order Number

24

120

XCN

O

00765

Entered By Code

25

80

CE

R

0088

00393

Procedure Code

26

80

CE

O

0340

01316

Procedure Code Modifier

720

ITEM#

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1
4.35.4.1.2.6 PR1 Segment – Procedures

725

The PR1 segment contains information relative to various types of procedures that can be
performed on a patient. The PR1 segment can be used to send procedure information, forexample: Surgical, Nuclear Medicine, X ray with contrast, etc. The PR1 segment is used to send
multiple procedures, for example, for medical records encoding or for Charge Processors.
Table 4.35-4: PR1 Attributes
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

R

00391

Set ID - PR1

2

2

IS

R

0089

00392

Procedure Coding Method

3

80

CE

R

0088

00393

Procedure Code

4

40

ST

O

00394

Procedure Description

5

26

TS

R

6

2

IS

R

7

4

NM

O

8

120

XCN

O

9

2

IS

O

10

4

NM

O

11

120

XCN

O

12

230

XCN

13

60

CE

14

2

NM

O

15

80

CE

O

16

80

CE

O

00395

Procedure Date/Time

00396

Procedure Functional Type

00397

Procedure Minutes

0010

00398

Anesthesiologist

0019

00399

Anesthesia Code00400

Anesthesia Minutes

0010

00401

Surgeon

O

0010

00402

Procedure Practitioner

O

0059

00403

Consent Code

00404

Procedure Priority

0051

00772

Associated Diagnosis Code

0340

01316

Procedure Code Modifier

0230

Adapted from the HL7 standard, version 2.3.1
Note: Each PR1 segment will contain only one procedure code or one modifier code.

730

4.35.4.2 Sources of Information
The Charge Posted Transaction derives its data from three sources which are described below.
Table 4.35-5 describes the mapping of the fields in the FT1 segment and the PR1 segment.
•

Order Management

21
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________The Order Placer General Order Message provides the Department System
Scheduler/Order Filler with the required Charge Posted Transaction fields to be used in
the PID Segment. See RAD TF-2: 4.2 and 4.3 for required and optional fields.

735
•

740

745

The Modality General Order Message provides the Department System Scheduler/Order
Filler with the required Charge Posted Transaction fields to be used in the FT1 segment
and the PR1 segment. There may be additional procedures, or supplies information
contained in the DICOM Billing Materials and Management message. See RAD TF-2;
4.7 (Modality Procedure Step Completed/Discontinued) for required and optional fields.
The message semantics are defined in the DICOM Service Class Section of the DICOM 2011
Modality Performed Procedure Step SOP Class. It is the responsibility of the Acquisition
Modality to ensure that the procedure information is sent to the Department System
Scheduler/Order Filler.
•

750

Modality Performed Procedure Step

Manual Posting / Department System Scheduler/Order Filler
Manual entry of Charge Posted Transaction information is also supported. This enables
the Department System Scheduler/Order Filler to collect information that is not being
provided by the Modality or the Order Placer and is required by the Charge Processor.
This data can be manually entered into or is a function of the Department System
Scheduler/Order Filler.
Table 4.35-5: Mapping of the FT1 Message

FT1 Field

Field Definition

OPT

HL7 –
ADT and
ORM
Segments

Modality
Performed
Procedure
Step

Manual Input /Department
SystemScheduler/Order
FillerTransaction
Date

Date of the transaction. For
example, this field would be
used to identify the date aprocedure, item, or test was
conducted or used. It may bedefaulted to today’s date.

R

Performed
Procedure Step
End Date(0040,0004) +Performed
Procedure Step
End Time(0040,0005)

Generated by
Department System
Scheduler/Order
Filler if there is no
MPPS

Transaction
Posting Date

Date of the transaction thatwas sent to the financial
system for posting.

R

Generated by
Department System
Scheduler/Order
FillerUse today’s date.

Transaction
Type

Code that identifies the type oftransaction. Values:
CG – Charge
CD – Credit
PY – Payment
AJ – Adjustment

R

Generated by
Department System
Scheduler/Order
Filler22
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________FT1 Field

Field Definition

OPT

HL7 –
ADT and
ORM
Segments

Modality
Performed
Procedure
Step

Manual Input /Department
SystemScheduler/Order
FillerTransaction
Code

Code assigned by theinstitution for the purpose of
uniquely identifying thetransaction. For example, thisfield would be used touniquely identify a procedure,
supply item, or test for
charging purposes.

R

Billing Item
Sequence (0040,
0296)
Note: If theBilling Item
Sequence isblank then use
Procedure Code
Sequence (0008,
1032)

Transaction
Quantity

Quantity of items associatedwith this transactionO

Quantity
Sequence(0040,0293)

Transaction
Amount Extended

The amount of a transaction. It
may be left blank if thetransaction is automatically
priced. Total price for multiple
items.

O

Generated by
Department System
Scheduler/Order
FillerTransaction
Amount Unit

Unit price of a transaction.
Price of a single item.

O

Generated by
Department System
Scheduler/Order
Filler.

Department
Code

The department code that
controls the transaction code
described above.

O

Generated by
Department System
Scheduler/Order
Filler.

Insurance
Plan ID

The identifier of the primary
insurance plan with which thistransaction shall be associatedO

Generated by
Department System
Scheduler/Order
Filler.

Insurance
Amount

The amount to be posted to theinsurance plan referenced
above.

O

Generated by
Department System
Scheduler/Order
Filler.

AssignedPatient
Location

This field contains the current
patient location. This can be
the location of the patientwhen the charge item wasordered or when the charged
service was rendered.

O

FeeSchedule

This field contains the codeused to select the appropriate
fee schedule to be used for thistransaction posting.

O

Patient Type

This field contains the typecode assigned to the patient forthis episode of care (visit orstay).

O

Generated by
Department System
Scheduler/Order
Filler if there is no
MPPS.

PV1-3 –
AssignedPatient
Location(ADT)

23
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________FT1 Field

Field Definition

OPT

HL7 –
ADT and
ORM
Segments

Diagnosis
Code – FT1

This field contains the primary
diagnosis code for billing
purposes. ICD9 CM is
assumed for all diagnosis
codes. This is the most current
diagnosis code that has been
assigned to the patient. ICD10
can also be used. The name ofcoding system (third
component) indicates whichcoding system is used.

O

Performed
By CodeThis field contains thecomposite number/name of theperson/group that performed
the test/procedure/transaction,etc. This is the service
provider.

R

Order By
CodeThis field contains thecomposite number/name of theperson/group that ordered thetest/ procedure/transaction, etc.

R

Unit Cost

This field contains the unit
cost of transaction. The cost ofa single item.

O

Filler Order
NumberThis field is used when thebilling system is requestingobservational reporting
justification for a charge. Thisis the number used by a filler
to uniquely identify a result.

R

ORC-3 Filler
Order
Number(ORM)

Entered By
CodeThis field identifies thecomposite number/name of theperson who entered theinsurance information.

O

ORC-10Entered By(ORM)

Procedure
CodeThis field contains a unique
identifier assigned to theprocedure, if any, associatedwith the charge.

R

Modality
Performed
Procedure
Step

Manual Input /Department
SystemScheduler/Order
FillerPerforming
Physician’s
Name(0008,1050)
Note: May berepeated.

Generated by
Department System
Scheduler/Order
Filler if there is no
MPPS.

ORC-12
Ordering
Provider(ORM)
Generated by
Department System
Scheduler/Order
Filler.

Procedure Code
Sequence (0008,
1032)

24
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________FT1 Field

Field Definition

Procedure
Code
ModifierThis field contains theprocedure code modifier to theprocedure code reported infield 25, when applicable.
Procedure code modifiers aredefined by regulatory agencies
such as HCFA and the AMA.

OPT

HL7 –
ADT and
ORM
Segments

Modality
Performed
Procedure
Step

O

Manual Input /Department
SystemScheduler/Order
Filler
Generated by
Department System
Scheduler/Order
Filler.
Use “TC” forTechnical
Component.
Use “26” forProfessional
Component
Other modifiers may
be included as
repetitions of the
field.

755
Table 4.35-6: Mapping of the PR1 Segment
PR1 Field

Field Definition

OPT

HL7 – ADTand ORM
Segments

MPPS –
Modality
Perform
Procedure
Step

Manual Input /Department
SystemScheduler/Order
FillerSet ID - PR1

A number that identifies thistransaction. For the firstoccurrence of the segment thesequence number shall be 1,
for the second occurrence it
shall be 2, etc.

R

Procedure
CodeThis field contains a unique
identifier assigned to theprocedure.

R

Billing
Procedure Step
Sequence(0040,0320)

Generated by
Department System
Scheduler/Order
Filler if there is no
MPPS.

Procedure
Date/Time

This field contains thedate/time that the procedure
was performedR

Performed
Procedure Step
End Date(0040,0004) +Performed
Procedure Step
End Time(0040,0005)
Note: Use thelast MPPS of theProcedure

Generated by
Department System
Scheduler/Order
Filler if there is no
MPPS.

Procedure
FunctionalType

The optional code that further
defines the type of procedure.
Values:A – Anesthesia
P – Procedure for treatment

R

Generated by
Department System
Scheduler/Order
Filler

Generated by
Department System
Scheduler/Order
Filler.

25
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
PR1 Field

Field Definition

OPT

HL7 – ADTand ORM
Segments

MPPS –
Modality
Perform
Procedure
Step

Manual Input /Department
SystemScheduler/Order
Filler

I – Invasive procedure notclassified
D – Diagnostic procedure
Procedure
Code
ModifierThis field contains theprocedure code modifier tothe procedure code reported
in field 3, when applicable.

O

Generated by
Department System
Scheduler/Order
Filler or Charge
Processor.
Use “TC” forTechnical
Component.
Use “26” forProfessional
Component.
Other modifiers may
be included as
repetitions of the
field.
Modifier may beabsent in a case of
global billing.

4.35.4.2.1.1 Expected Actions

760

It is expected that the Department System Scheduler/Order Filler will be sending the Charge
Posted Transaction to the Charge Processor when one of the trigger events has occurred. Thiscan be either the technical billing or the professional billing financial transaction.

4.36 Account Management
This section corresponds to Transaction RAD-36 of the IHE Technical Framework. TransactionRAD-36 is used by the ADT Patient Registration and Charge Processor actors.
4.36.1 Scope
765

770

The Account Management Transaction specifies messages from the ADT Patient Registration to
the Charge Processor. These messages are sent when the account for the patient is set-up,
updated, or closed.
Use of this transaction minimizes the information needed to be sent to the Department System
Scheduler/Order Filler such as insurance or guarantor information. The Charge Processor
receives this information directly from the ADT system.

26
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.36.2 Use Case Roles
ADT Patient
Registration

ChargeProcessor

Account
Management

Actor: ADT Patient Registration
Role: Collects information relevant to the account patient and submits it to the Charge Processor.
775

Actor: Charge Processor
Role: Receives the information from Patient Registration. Processes and combines charges inorder to issue an insurance claim or patient’s billing statement.
4.36.3 Referenced Standards
Health Level Seven, Version 2.3.1: Chapter 6 - Financial Management780

4.36.4 Interaction Diagram
ChargeProcessor

ADT Patient
Registration

Account Management
BAR^P01, P05, P06

4.36.4.1 Account Management - New Account785

The Account Management message is used to describe a patient account information transaction
transmitted between the ADT Patient Registration and the Charge Processor. Data is sent fromthe ADT Patient Registration application to the patient accounting or financial system toestablish an account for a patient’s billing/accounts receivable record. This message enables theCharge Processor to process the patient claim after the procedure charge is received.
4.36.4.1.1

790

Trigger Events

Creation of a new account will typically occur as a result of one of the following ADT Patientregistration events:••

Admission of an in-patient into a facility
Registration of an outpatient for a visit of the facility
27

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•
795

Pre-admission of an in-patient (i.e., registration of patient information ahead of actual
admission).

Creation of an account will result in the following Account Management message:•

P01 – Add Patient Account.

4.36.4.1.2

800

Message Semantics

The Account Management transaction is conducted by the HL7 BAR message. The ADT Actor
shall generate the message whenever a patient is admitted, pre-admitted or registered. The P01
event shall only be used to add a new account that did not exist before, not to update an existingaccount. The new P05 (update account) event shall be used to update an existing account. The
new P06 (end account) event shall be used to close an account.
One or more DG1 segments shall be present if patient’s diagnosis is known at the time of
Account creation. It may be absent otherwise.

805

One or more GT1 segments shall be present if Guarantor (even if it is patient itself) is known at
the time of Account creation. It may be absent otherwise.
One or more IN1 segments shall be present if insurance information about patient is known at thetime of Account creation. It may be absent otherwise.
Note: Additional qualifications to the level of specification and HL7 profiling are stated in RAD TF-2: 2.3.

810

The segments of the Add Patient Account message listed below are required, and the detailed
description of messages is provided in the following subsections.
BAR Segment

Billing Account

Chapter in HL7 2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

[PV1]

Patient Visit

3 (see note)[{DG1}]

Diagnosis

6[{GT1}]

Guarantor

6[{IN1}]

Insurance

6

Note: PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national appendices to the
IHE Radiology Technical Framework (See RAD TF-4)

815

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the BAR
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
4.36.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2.2 “Message Control”.

820

Field MSH-9 Message Type shall have at least two components. The first component shall havea value of “BAR”; the second component shall have the value of P01.
28
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.36.4.1.2.2 EVN Segment
The EVN segment is used to communicate necessary trigger event information to receiving
applications. See RAD TF-2: 4.1.4.1.2.1.2 for required and optional fields of the EVN segment.
825

4.36.4.1.2.3 PID Segment
All of the fields in PID segment are optional, except those listed in Table 4.36-1. See RAD TF-2:
4.1.4.1.2.1.3 for the list of all fields of the PID segment.
Table 4.36-1: IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

3

20

CX

R

00106

Patient Identifier List

5

48

XPN

R

00108

Patient Name

18

20

CX

C

00121

Patient Account Number

830

Adapted from the HL7 standard, version 2.3.1
4.36.4.1.2.4 PV1 Segment
Most of the fields in PV1 segment are optional, except those listed in Table 4.36-2. See RAD
TF-2: 4.1.4.1.2.1.4 for the list of all fields of the PV1 segment.

835

Table 4.36-2: IHE Profile - PV1 Segment
SEQ

LEN

DT

OPT

2

1

IS

R

19

20

CX

C

51

1

IS

C

TBL#

ITEM#

0004

00132

Patient Class

00149

Visit Number

01226

Visit Indicator

0326

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1
At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Radiology Technical Framework (See RAD TF-4)
840

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.
4.36.4.1.2.5 DG1 Segment

845

The DG1 segment contains patient diagnosis information of various types, for example,
admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, formedical records encoding). It is also used when the FT1-19-diagnosis code does not provide
sufficient information for a billing system. This diagnosis coding shall be distinguished from theclinical problem segment used by caregivers to manage the patient. Table 4.36-3 lists therequired and optional attributes of the DG1 segment.

29
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
850

Table 4.36-3: IHE Profile - DG1 Segment
SEQ

LEN

DT

OPT

1

4

SI

R

2

2

ID

O

3

60

CE

O

4

40

ST

5

26

TS

6

2

IS

R

7

60

CE

8

60

CE

9

2

10

TBL#

ITEM#

ELEMENT NAME

00375

Set ID - DG1

0053

00376

Diagnosis Coding Method

0051

00377

Diagnosis Code - DG1

O

00378

Diagnosis Description

O

00379

Diagnosis Date/Time

0052

00380

Diagnosis Type

O

0118

00381

Major Diagnostic Category

O

0055

00382

Diagnostic Related Group

ID

O

0136

00383

DRG Approval Indicator

2

IS

O

0056

00384

DRG Grouper Review Code

11

60

CE

O

0083

00385

Outlier Type

12

3

NM

O

00386

Outlier Days

13

12

CP

O

00387

Outlier Cost

14

4

ST

O

00388

Grouper Version And Type

15

2

ID

O

00389

Diagnosis Priority

16

60

XCN

O

00390

Diagnosing Clinician

17

3

IS

O

0228

00766

Diagnosis Classification

18

1

ID

O

0136

00767

Confidential Indicator

19

26

TS

O

00768

Attestation Date/Time

4.36.4.1.2.6 GT1 Segment
The GT1 segment contains guarantor (e.g., the person or the organization with financial
responsibility for payment of a patient account) data for patient and insurance billing
applications. Table 4.36-4 lists the required and optional attributes of the GT1 segment.
855
Table 4.36-4: IHE Profile - GT1 Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

R

2

59

CX

3

48

XPN

4

48

5

106

6

40

XTN

O

00410

Guarantor Ph Num-Home

7

40

XTN

O

00411

Guarantor Ph Num-Business

8

26

TS

O

00412

Guarantor Date/Time Of Birth

9

1

IS

O

0001

00413

Guarantor Sex

10

2

IS

O

0068

00414

Guarantor Type

11

80

CE

O

0063

00415

Guarantor Relationship

12

11

ST

O

00416

Guarantor SSN

00405

Set ID - GT1

O

00406

Guarantor Number

R

00407

Guarantor Name

XPN

O

00408

Guarantor Spouse Name

XAD

O

00409

Guarantor Address

30
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
SEQ

LEN

DT

OPT

13

8

DT

O

TBL#

00417

ITEM#

Guarantor Date - Begin

ELEMENT NAME

14

8

DT

O

00418

Guarantor Date - End

15

2

NM

O

00419

Guarantor Priority

16

130

XPN

O

00420

Guarantor Employer Name

17

106

XAD

O

00421

Guarantor Employer Address

18

40

XTN

O

00422

Guarantor Employer Phone
Number

19

20

CX

O

00423

Guarantor Employee ID Number

20

2

IS

O

0066

00424

Guarantor Employment Status

21

130

XON

O

00425

Guarantor Organization Name

22

1

ID

O

0136

00773

Guarantor Billing Hold Flag

23

80

CE

O

0341

00774

Guarantor Credit Rating Code

24

26

TS

O

00775

Guarantor Death Date And Time

25

1

ID

O

0136

00776

Guarantor Death Flag

26

80

CE

O

0218

00777

Guarantor Charge Adjustment
Code

27

10

CP

O

00778

Guarantor Household Annual
Income

28

3

NM

O

00779

Guarantor Household Size

29

20

CX

O

30

80

CE

O

31

8

DT

32

8

33
34

00780

Guarantor Employer ID Number

00781

Guarantor Marital Status Code

O

00782

Guarantor Hire Effective Date

DT

O

00783

Employment Stop Date

2

IS

O

0223

00755

Living Dependency

2

IS

O

0009

00145

Ambulatory Status

35

80

CE

O

0171

00129

Citizenship

36

60

CE

O

0296

00118

Primary Language

37

2

IS

O

0220

00742

Living Arrangement

38

80

CE

O

0215

00743

Publicity Code

39

1

ID

O

0136

00744

Protection Indicator

40

2

IS

O

0231

00745

Student Indicator

41

80

CE

O

0006

00120

Religion

42

48

XPN

O

00746

Mother’s Maiden Name

43

80

CE

O

0212

00739

Nationality

44

80

CE

O

0189

00125

Ethnic Group

45

48

XPN

O

00748

Contact Person’s Name

46

40

XTN

O

00749

Contact Person’s Phone Number

47

80

CE

O

0222

00747

Contact Reason

48

2

IS

O

0063

00784

Contact Relationship

49

20

ST

O

00785

Job Title

50

20

JCC

O

00786

Job Code/Class

0002

0327/
0328

31
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
SEQ

LEN

DT

OPT

51

130

XON

O

52

2

IS

O

53

2

IS

54

50

FC

55

80

CE

TBL#

ITEM#

ELEMENT NAME

01299

Guarantor Employer’s
Organization Name

0295

00753

Handicap

O

0311

00752

Job Status

O

0064

01231

Guarantor Financial Class

O

0005

01291

Guarantor Race

4.36.4.1.2.7 IN1 Segment

860

The IN1 segment contains insurance policy coverage information necessary to produce properly
pro-rated and patient and insurance bills. Table 4.36-5 lists the required and optional attributes of
the IN1 segment.
Table 4.36-5: IHE Profile - IN1 Segment
SEQ

LEN

DT

OPT

TBL#

1

4

SI

R

2

60

CE

R

3

59

CX

R

4

130

XON

O

00429

Insurance Company Name

5

106

XAD

O

00430

Insurance Company Address

6

48

XPN

O

00431

Insurance Co Contact Person

7

40

XTN

O

00432

Insurance Co Phone Number

8

12

ST

O

00433

Group Number

9

130

XON

O

00434

Group Name

10

12

CX

O

00435

Insured’s Group Emp ID

11

130

XON

O

00436

Insured’s Group Emp Name

12

8

DT

O

00437

Plan Effective Date

13

8

DT

O

00438

Plan Expiration Date

14

55

CM

O

00439

Authorization Information

15

3

IS

O

00440

Plan Type

16

48

XPN

O

00441

Name Of Insured

17

80

CE

O

00442

Insured’s Relationship To Patient

18

26

TS

O

00443

Insured’s Date Of Birth

19

106

XAD

O

00444

Insured’s Address

20

2

IS

O

0135

00445

Assignment Of Benefits

21

2

IS

O

0173

00446

Coordination Of Benefits

22

2

ST

O

00447

Coord Of Ben. Priority

23

1

ID

O

00448

Notice Of Admission Flag

24

8

DT

O

00449

Notice Of Admission Date

25

1

ID

O

00450

Report Of Eligibility Flag

26

8

DT

O

00451

Report Of Eligibility Date

0072

0086
0063

0136
0136

ITEM
#

ELEMENT NAME

00426

Set ID - IN1

00368

Insurance Plan ID

00428

Insurance Company ID

32
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
SEQ

LEN

DT

OPT

TBL#

ITEM
#

27

2

IS

O

0093

00452

Release Information Code

28

15

ST

O

00453

Pre-Admit Cert (PAC)

29

26

TS

O

00454

Verification Date/Time

30

60

XCN

O

00455

Verification By

31

2

IS

O

0098

00456

Type Of Agreement Code

32

2

IS

O

0022

00457

Billing Status

33

4

NM

O

00458

Lifetime Reserve Days

34

4

NM

O

00459

Delay Before L.R. Day

35

8

IS

O

00460

Company Plan Code

36

15

ST

O

00461

Policy Number

37

12

CP

O

00462

Policy Deductible

38

12

CP

O

00463

Policy Limit - Amount

39

4

NM

O

00464

Policy Limit - Days

40

12

CP

O

00465

Room Rate - Semi-Private

41

12

CP

O

00466

Room Rate - Private

42

60

CE

O

0066

00467

Insured’s Employment Status

43

1

IS

O

0001

00468

Insured’s Sex

44

106

XAD

O

00469

Insured’s Employer’s Address

45

2

ST

O

00470

Verification Status

46

8

IS

O

0072

00471

Prior Insurance Plan ID

47

3

IS

O

0309

01227

Coverage Type

48

2

IS

O

0295

00753

Handicap

49

12

CX

O

01230

Insured’s ID Number

4.36.4.1.3
865

0042

ELEMENT NAME

Expected Actions

It is expected that after receiving Add Patient Account message the receiving system will create
and maintain the account information for the patient for purpose of utilizing it when processing
charges.
4.36.4.2 Account Management – Update Account
4.36.4.2.1

870

Trigger Events

Changes to patient account information (e.g., change in patient name, patient address, guarantor,
insurance, etc.) shall trigger the following Update Account message:
P05 – Update Account Information
4.36.4.2.2

Message Semantics

The Account Management transaction is conducted by the HL7 BAR message. The ADT Actor
shall generate the message whenever patient account information changed. The P05 (update

33
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
875

880

account) event shall only be used to update an existing account. The new P06 (end account)
event shall be used to close an account.
All of the required (R and R2) information for a patient record shall be re-sent in a P05 message.
Any information received as NULL (i.e., transmitted as two double quote marks "“) in the P05
message shall be removed from the receiving system's database for that patient record. If novalue is sent (i.e., omitted) in the P05 message, the old value shall remain unchanged in thereceiving system's database for that patient record.
Note: Additional qualifications to the level of specification and HL7 profiling are stated in RAD TF-2: 2.3.

885

The segments of the Update Account Information message listed below are required, and thedetailed description of the message is provided in Section 4.36.4.1.2.5. One or more DG1segments shall be present if a patient’s diagnosis is changed. One or more GT1 segments shall bepresent if Guarantor information is updated. One or more IN1 segments shall be present if
insurance information is added or modified.
BAR Segment

890

Billing Account

Chapter in HL7 2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

[PV1]

Patient Visit

3 (see note)[{DG1}]

Diagnosis

6[{GT1}]

Guarantor

6[{IN1}]

Insurance

6

Note: PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national appendices to the
IHE Radiology Technical Framework (See RAD TF-4)

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the BAR
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
895

4.36.4.2.2.1 MSH Segment
The MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2.2 “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component shall havea value of “BAR”; the second component shall have the value of P05.
4.36.4.2.2.2 EVN Segment

900

The EVN segment is used to communicate necessary trigger event information to receiving
applications. See 4.1.4.1.2.1.2 for required and optional fields of the EVN segment.
4.36.4.2.2.3 PID Segment
All of the fields in PID segment are optional, except those listed in Table 4.36-6. See RAD TF-2:
4.1.4.1.2.1.3 for the list of all fields of the PID segment.
34
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
905
Table 4.36-6: IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

3

20

CX

R

00106

Patient Identifier List

5

48

XPN

R

00108

Patient Name

18

20

CX

C

00121

Patient Account Number

Adapted from the HL7 standard, version 2.3.1
4.36.4.2.2.4 PV1 Segment
910

Most of the fields in PV1 segment are optional, except those listed in Table 4.36-7. See RAD
TF-2: 4.1.4.1.2.1.4 for the list of all fields of the PV1 segment.
Table 4.36-7: IHE Profile - PV1 Segment
SEQ

LEN

DT

OPT

2

1

IS

R

19

20

CX

C

51

1

IS

C

TBL#

ITEM#

0004

00132

Patient Class

00149

Visit Number

01226

Visit Indicator

0326

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1
915

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Radiology Technical Framework (See RAD TF-4).
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.
4.36.4.2.2.5 DG1 Segment920

See sec.4.36.4.1.2.5 for required and optional fields of the DG1 segment.
4.36.4.2.2.6 GT1 Segment
See sec.4.36.4.1.2.6 for required and optional fields of the GT1 segment.
4.36.4.2.2.7 IN1 Segment
See sec. 4.36.4.1.2.7 for required and optional fields of the IN1 segment.

925

4.36.4.2.3

Expected Actions

It is expected that after receiving Update Account Information message the receiving system will
update its local patient demographic, diagnosis, guarantor, and/or insurance information. Any
information received as null in the new P05 message shall be removed locally.

35
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.36.4.3 Account Management – End Account930

4.36.4.3.1

Trigger Events

Ending or closing of an account will typically occur as a result of patient discharge or visit end
and will result in the following Account Management message:
P06 – End Account.
4.36.4.3.2
935

Message Semantics

The Account Management transaction is conducted by the HL7 BAR message. The ADT Actor
shall generate the message whenever a patient is closed. The new P06 (end account) event shallbe used to close an account.
Note: Additional qualifications to the level of specification and HL7 profiling are stated in RAD TF-2: 2.3.

940

The segments of the End Account message listed below are required, and the detailed
description of messages is provided in the following subsections.
BAR Segment

945

Billing Account

Chapter in HL7 2.3.1

MSH

Message Header

2

EVN

Event Type

3

PID

Patient Identification

3

[PV1]

Patient Visit

3 (see note)

Note: PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national appendices to the
IHE Radiology Technical Framework (See RAD TF-4)

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the ACK message.
4.36.4.3.2.1 MSH Segment
950

The MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2.2 “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component shall havea value of “BAR”; the second component shall have value of P06.
4.36.4.3.2.2 EVN Segment

955

The EVN segment is used to communicate necessary trigger event information to receiving
applications. See RAD TF-2: 4.1.4.1.2.1.2 for required and optional fields of the EVN segment.
4.36.4.3.2.3 PID Segment
All of the fields in PID segment are optional, except those listed in Table 4.36-8. See RAD TF-2:
4.1.4.1.2.1.3 for the list of all fields of the PID segment.

36
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
960

Table 4.36-8: IHE Profile - PID segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

3

20

CX

R

00106

Patient Identifier List

5

48

XPN

R

00108

Patient Name

18

20

CX

C

00121

Patient Account Number

Adapted from the HL7 standard, version 2.3.1
4.36.4.3.2.4 PV1 Segment
Most of the fields in PV1 segment are optional, except those listed in Table 4.36-9. RAD TF-2:
4.1.4.1.2.1.4 for the list of all fields of the PV1 segment.
965
Table 4.36-9: IHE Profile - PV1 Segment
SEQ

LEN

DT

OPT

2

1

IS

R

19

20

CX

C

51

1

IS

C

TBL#

ITEM#

0004

00132

Patient Class

00149

Visit Number

01226

Visit Indicator

0326

ELEMENT NAME

Adapted from the HL7 standard, version 2.3.1

970

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Radiology Technical Framework (See RAD TF-4)
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.
4.36.4.3.3

975

Expected Actions

It is expected that after receiving End Account message (P06) the receiving system will update
its local patient account information to reflect the fact that the account has been closed.

4.37 Query Post-Processing Worklist
This section corresponds to Transaction RAD-37 of the IHE Technical Framework. TransactionRAD-37 is used by Post-Processing Manager and Evidence Creator.
4.37.1 Scope
980

985

This transaction is used during post-processing by the Evidence Creator to find out what tasks
have been scheduled by the Post-Processing Manager. The transaction describes generically theworklist being provided for post-processing related workitem codes for Image Processing,Computer Aided Diagnosis, and Computer Aided Detection.
The Post-Processing Manager is the provider of the worklist. It obtains the necessary information
with either grouping with the Department System Scheduler or the Image Manager. The
Evidence Creator retrieves the worklist and includes received information in the resulting

37
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
instances, which are stored through instance stored transactions such as Evident Document
Stored, Image Stored, etc.
4.37.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Query Post-Processing
Worklist

990
Actor: Evidence Creator
Role: Query the Post-Processing Manager for post-processing Scheduled Procedure Steps.
Actor: Post-Processing Manager
995

Role: Schedule post-processing procedure steps for the workitems of Image Processing,Computer Aided Diagnosis, and Computer Aided Detection; accept requests for Worklist items,
perform the query and return response.
4.37.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Worklist SOP Class
4.37.4 Interaction Diagram
Post-Processing
Manager

Evidence Creator

Query GP Worklist
Receive GP Worklist

1000
4.37.4.1 Query General Purpose Worklist Message
This is the worklist query sent to the Post-Processing Manager.
4.37.4.1.1
1005

Trigger Events

A user or an automated function on the Evidence Creator queries for scheduled post-processing
worklist items.

38
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.37.4.1.2

Message Semantics

C-FIND request of the DICOM General Purpose Worklist SOP Class is used to query for thegeneral purpose worklist. Evidence Creator performs the SCU role, and the Post-Processing
Manager performs the SCP role.
1010

4.37.4.1.2.1 Matching Keys and Return KeysThe Evidence Creator is required to query for specific attributes (return keys) that will beinserted into the instances created as a result of post-processing. See Appendix D for moredetails.

1015

1020

The Evidence Creator shall support individually each one of the required query keys listed inTable 4.37-4 - Return and Matching Keys For Post-Processing Worklist Queries. In addition, atleast one of the following three combinations shall be implemented by the Evidence Creator:
1. Patient Oriented Query: Query for a worklist for a specific patient/procedure. The SCU shallsupport all (31) combinations of the matching key attributes listed in Table 4.37-1 by including 1
or more keys. The sequence attributes denoted in the italics are not matching keys on their own
but have to be included in a query to convey the value of the attributes contained within them.
Thus, the SCU shall support any combination of Patient’s Name, Patient ID, Accession Number,
Requested Procedure ID, and Scheduled Workitem Code.
Table 4.37-1: GPWL Keys for Patient Oriented QueryMatching Key Attributes

Tag

Patient's Name

(0010,0010)

Patient ID(0010,0020)

Referenced Request Sequence(0040,A370)>Accession Number(0008,0050)>Requested Procedure ID(0040,1001)

Scheduled Workitem Code Sequence(0040,4018)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

1025

1030

2. Station-oriented Query: Query for a broad worklist for particular workstation. The SCU
shall support all (15) combinations of the matching key attributes listed in Table 4.37-2 byincluding 1 or more keys. The sequence attributes denoted in the italics are not matching keys on
their own but have to be included in a query to convey the value of the attributes contained
within them. Code Value of the Scheduled Station Name Code Sequence, if valued, shall be set
to the AE Title of the workstation’s General Purpose Worklist SCU.
Table 4.37-2: GPWL Keys for Station-Oriented Queries
Matching Key Attributes
General Purpose Scheduled Procedure Step Status

Tag(0040,4001)

39
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1035

Scheduled Station Name Code Sequence(0040,4025)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

Scheduled Procedure Step Start Date and Time(0040,4005)

Scheduled Workitem Code Sequence(0040,4018)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

3. The Class-oriented Query: Query for a broad worklist for a particular class of workstations.
The SCU shall support all (15) combinations of the matching key attributes listed in Table 4.37-3
by including 1 or more keys. The sequence attributes denoted in the italics are not matching keys
on their own but have to be included in a query to convey the value of the attributes contained
within them.

1040
Table 4.37-3: GPWL Keys for Class-Oriented Worklist Queries
Matching Key Attributes

Tag

General Purpose Scheduled Procedure Step Status(0040,4001)

Scheduled Station Class Code Sequence(0040,4026)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

Scheduled Procedure Step Start Date and Time(0040,4005)

Scheduled Workitem Code Sequence(0040,4018)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

4.37.4.1.2.2 Examples for the Use of Matching Key Attributes
•
1045

•
•
•

1050

Using the Scheduled Procedure Step Start Date and Time key: query for all the postprocessing tasks scheduled for today.
Using the Scheduled Workitem Code key: query for all computer-aided detection (CAD)
tasks.
Using Scheduled Station Name key: query for all the post-processing tasks that arescheduled for this workstation.
Using the Scheduled Procedure Step Start Date and Time, Scheduled Workitem Code and
Scheduled Station Class Code keys: query for all the Image Processing tasks that arescheduled for today on CT 3D reconstruction workstations.

Note: Applications are recommended to append a wildcard "*" at the end of each component of the structured Patient
Name to facilitate matching with both structured and unstructured Patient Names.

4.37.4.1.2.3 Matching Keys and Return Keys
1055

The Evidence Creator is required to query for specific attributes (return keys), many of which
will be required in the objects it creates. The requirements for the attributes in the stored objects
are defined in Appendix C. There are additional attributes that may be queried.
40
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1060

Table 4.37-4 summarizes the matching key requirements and lists the optional and required
attributes that may be requested and shall be returned in order to make these available to the user
at the Evidence Creator. See RAD TF-2: 2.2 for more information on conventions used in thistable.
Table 4.37-4: Matching and Return Keys for Post-Processing Worklist Queries
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

SOP Common
Specific Character Set(0008,0005)

O

O

O

R

SOP Class UID(0008,0016)

O

O

R+*

R

SOP Instance UID(0008,0018)

O

R

R+*

R

General Purpose Scheduled Procedure Step Information
General Purpose Scheduled
Procedure Step Status(0040,4001)

R+

R

R+

R

Input Availability Flag

(0040,4020)

O

R

R+

R

General Purpose Scheduled
Procedure Step Priority(0040,4003)

O

R

R+

R

Scheduled Procedure Step ID(0040,0009)

O

O

O

R

Scheduled Workitem Code
Sequence(0040,4018)>Code Value(0008,0100)

R+

R

R+*

R

>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+

R

Scheduled Processing
Applications Code Sequence(0040,4004)>Code Value(0008,0100)

O

R

R+*

R

>Coding Scheme Designator(0008,0102)

O

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+

R

Scheduled Station Name Code
Sequence(0040,4025)>Code Value(0008,0100)

R+

R

R+*

R

>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+*

R

Scheduled Station Class Code
Sequence(0040,4026)>Code Value(0008,0100)

R+

R

R+*

R

>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+*

R

Scheduled Station Geographic
Location Code Sequence(0040,4027)>Code Value(0008,0100)

O

R

O

R

>Coding Scheme Designator(0008,0102)

O

R

O

R

41
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

>Code Meaning(0008,0104)

-

-

O

R

Scheduled Procedure Step Start
Date and Time(0040,4005)

R+

R

R+

R

Expected Completion Date andTime(0040,4011)

O

R

O

R

Scheduled Human Performers
Sequence(0040,4034)>Human Performer Code
Sequence(0040,4009)>>Code Value(0008,0100)

O

R

O

R

>>Coding Scheme Designator(0008,0102)

O

R

O

R

>>Code Meaning(0008,0104)

-

-

O

R

>Human Performer's Name

(0040,4037)

O

O

O

R+

>Human Performer's Organization(0040,4036)

O

O

O

R+

Referenced Study Component
Sequence(0008,1111)>Referenced SOP Class UID(0008,1150)

O

O

O

R

>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Input Information Sequence(0040,4021)
O

O

R+*

R

>Study Instance UID(0020,000D)>Referenced Series Sequence(0008,1115)>>Series Instance UID(0020,000E)

O

O

R+*

R

>>Retrieve AE Title(0008,0054)

O

O

O

R

>>Storage Media File-Set ID(0088,0130)

O

O

O

O

>>Storage Media File-Set UID(0088,0140)

O

O

O

O

>>Referenced SOP Sequence(0008,1199)>>>Referenced SOP Class UID(0008,1150)

O

O

R+*

R

>>>Referenced SOP Instance UID(0008,1155)

O

O

R+*

R

Relevant Information Sequence(0040,4022)>Study Instance UID(0020,000D)

O

O

O

R

>Referenced Series Sequence(0008,1115)>>Series Instance UID(0020,000E)

O

O

O

R

>>Retrieve AE Title(0008,0054)

O

O

O

O

>>Storage Media File-Set ID(0088,0130)

O

O

O

O

>>Storage Media File-Set UID(0088,0140)

O

O

O

R

>>Referenced SOP Sequence(0008,1199)>>>Referenced SOP Class UID(0008,1150)

O

O

O

R

>>>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Resulting General Purpose
Performed Procedure Step

(0040,4015)

42
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

Sequence>Referenced SOP Class UID(0008,1150)

O

O

O

R

>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Actual Human Performers
Sequence(0040,4035)>Human Performer Code
Sequence(0040,4009)

O

O

O

R

>>Code Value(0008,0100)

O

O

O

R

>>Coding Scheme Designator(0008,0102)

O

O

O

R

>>Code Meaning(0008,0104)

-

-

O

R

>Human Performer's Name

(0040,4037)

O

O

O

R+

>Human Performer's
Organization(0040,4036)

O

O

O

R+

Study Instance UID(0020,000D)

O

O

R+*

R

Multiple Copies Flag

(0040,4006)

O

O

O

R

O

O

O

O

O

O

R+*

R

All other Attributes from theGeneral Purpose Scheduled
Procedure Step Information
ModuleGeneral Purpose Scheduled Procedure Step Relationship
Referenced Request Sequence(0040,A370)>Study Instance UID(0020,000D)>Referenced Study Sequence(0008,1110)>>Referenced SOP Class UID(0008,1150)

O

O

R+*

R

>>Referenced SOP Instance UID(0008,1155)

O

O

R+*

R

>Requested Procedure ID(0040,1001)

R+

R+

R+

R

>Requested Procedure Description(0032,1060)

O

O

O

R

>Requested Procedure Code
Sequence(0032,1064)>>Code Value(0008,0100)

O

O

O

R

>>Coding Scheme Designator(0008,0102)

O

O

O

R

>>Code Meaning(0008,0104)

-

-

O

R

>Accession Number(0008,0050)

R+

R

R+

R

>Requesting Physician(0032,1032)

O

O

O

R

O

O

O

O

O

O

O

O

>All other Attributes relating to
the Requested Procedure and the
Imaging Service Request in the
General Purpose Scheduled
Procedure Step Relationship
ModulePatient Relationship
All Attributes from the Patient
Relationship Module

43
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

Patient Identification
Patient's Name

(0010,0010)

R+

R

R+

R

Patient ID(0010,0020)

R+

R

R+

R

O

O

O

O

All other Attributes from thePatient Identification Module
Patient Demographic
Patient's Birth Date

(0010,0030)

O

O

R+

R

Patient's Sex(0010,0040)

O

O

R+

R

O

O

O

O

O

O

O

O

All other Attributes from thePatient Demographic Module
Patient Medical
All Attributes from the Patient
Medical Module

4.37.4.1.3
1065

Expected Actions

The Post-Processing Manager performs the query and sends the matching General Purpose
Worklist items to the Evidence Creator.
4.37.4.2 Receive General Purpose Worklist Message
This is the message the Post-Processing Manager sends containing post-processing General
Purpose Worklist information as a response to the Evidence Creator query.

1070

4.37.4.2.1

Trigger Events

The Post-Processing Manager receives a query for a Post-Processing Worklist.
4.37.4.2.2

1075

1080

Message Semantics

C-FIND Response from the DICOM General Purpose Worklist SOP Class will be used for thismessage. Some of the attributes queried through the worklist originate from other sources during
previous steps in the workflow, and are made available to the Post-Processing Manager (groupedwith Department System Scheduler or Image Manager) through other transactions such as
MPPS. It is up to the Post-Processing Manager to determine the Input Information, e.g., study,
series, etc. appropriate to be used in a workitem Scheduled Procedure Step, i.e., it is independentof the acquisition process and resulting MPPS.
The Post-Processing Manager shall specify the type of task to be performed in the content of the
Scheduled Workitem Code Sequence (0040,4018) using one of the following values from
DCMR CID 9231:

44Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table 4.37-5: Post-Processing Workitem Definition
Coding Scheme Designator(0008,0102)

1085

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM

110001

Image Processing

DCM

110002

Quality Control

DCM

110003

Computer Aided Diagnosis

DCM

110004Computer Aided Detection

DCM

110008Print

DCM

110009No subsequent Workitems

4.37.4.2.3

Expected Actions

An automated Evidence Creator uses the worklist to start post-processing or the user is provided
with the worklist to start work.

4.38 Workitem Claimed
1090

This section corresponds to Transaction RAD-38 of the IHE Technical Framework. TransactionRAD-38 is used by Post-Processing Manager, Report Manager, Report Creator and Evidence
Creator.
4.38.1 Scope

1095

1100

Upon selecting a post-processing workitem, the Evidence Creator takes ownership of the item bytelling the Post Processing Manager to change the status of the SPS to IN PROGRESS. This
allows the Post-Processing Manager to update its worklist and permits other worklist users todetect that this SPS has been claimed and is possibly already being worked on.
Similarly during the reporting workflow, upon selecting a Reporting workitem, the ReportCreator takes ownership of the item by telling the Reporting Manager to change the status of the
SPS to IN PROGRESS. This allows the Report Manager to update its worklist and permits otherworklist users to detect that this SPS has been claimed and is possibly already being worked on.
In both workflow cases, the SCU can also set the status to SUSPEND.
4.38.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Workitem Claimed

ReportManager

ReportCreator45
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1105

Actor: Evidence Creator
Role: Updates the Post-Processing Manager of the new status of the post-processing SPS when
the Evidence Creator claims the post-processing SPS.
Actor: Post-Processing Manager
Role: Accepts post-processing GP-SPS update information from the Evidence Creator.

1110

Actor: Report Creator
Role: Updates Report Manager with status of the Reporting SPS when the Report Creator claims
the reporting SPS.
Actor: Report Manager
Role: Accepts GP-SPS update information from the Report Creator.

1115

4.38.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Scheduled Procedure Step SOP Class.
4.38.4 Interaction Diagram
Post-Processing
Manager

Evidence
CreatorGP-SPS N-ACTION

Report Manager

Report Creator
GP-SPS N-ACTION

1120

4.38.4.1 General Purpose Scheduled Procedure Step In Progress/Suspend
Message
4.38.4.1.1

Trigger Events

For a post-processing workitem, a user or an automated function on the Evidence Creator begins
to act on a post-processing scheduled procedure step, or stops acting on it without completing it.
1125

For the reporting workitem, the user begins to act on the scheduled procedure step at the ReportCreator, or stops acting on it without completing it.

46
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.38.4.1.2

1130

Message Semantics

The Evidence Creator uses the N-ACTION request of the DICOM General Purpose Scheduled
Procedure Step SOP Class to inform the Post-Processing Manager that a specific SPS has been
started, and its status is IN PROGRESS. The Evidence Creator performs the SCU role, and the
Post-Processing Manager performs the SCP role. An SPS may also be suspended or resumed,
and the associated status of SUSPENDED or SCHEDULED will be set (see the DICOM 2011,
Part 4, Section F.1.6 for additional information).
The Report Creator and Report Manager utilize the same mechanism, where the Report Creator
performs the SCU role, and the Report Manager performs the SCP role.

1135

1140

If a human is performing the Post-Processing scheduled procedure step, then the N-ACTION
request may include the Actual Human Performers Sequence.
In a case of the reporting scheduled procedure step, the Report Creator shall send the Actual
Human Performer Sequence to the Reporting Manager, who shall then check if the person isallowed to perform the workitem. The Report Creator application shall ensure that the correctuser information is filled in the sequence.
4.38.4.1.3

1145

Expected Actions

The Post-Processing Manager updates the status of the SPS to IN PROGRESS, which is anindication that the SPS is already being working on, and other Evidence Creators shall not
perform any action on it. Attempts by any Evidence Creator without the current Transaction UID
to update the SPS will be rejected.
When Post-Processing Manager updates the status of the SPS to SUSPENDED or
SCHEDULED, the SPS has now been released from the control of the Evidence Creator.

1150

In the same way, the Report Manager updates the status of the SPS to IN PROGRESS, which isan indication that the SPS is already being working on, and other Report Creators shall not
perform any action on it. Attempts by any other Report Creator to update the SPS will berejected by the Report Manager.
When the Report Manager updates the status of the SPS to SUSPENDED or SCHEDULED, the
SPS has now been released from the control of the Report Creator.

4.39 Workitem Performed Procedure Step In Progress
1155

This section corresponds to Transaction RAD-39 of the IHE Technical Framework. TransactionRAD-39 is used by Post-Processing Manager and Evidence Creator as well as Report Manager
and Report Creator.
4.39.1 Scope

1160

Upon starting to work on the claimed post-processing scheduled procedure step, Evidence
Creator sends a message to the Post-Processing Manager to create a Performed Procedure Step
(PPS).
Upon starting to work on the claimed reporting scheduled procedure step, Report Creator sends a
message to the Report Manager to create a Performed Procedure Step (PPS).
47
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.39.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Workitem PPS inprogress

1165

ReportManager

ReportCreatorActor: Evidence Creator
Role: Update the Post-Processing Manager with creation of a post-processing PPS when the
Evidence Creator starts the work.
Actor: Report Manager
1170

Role: Accept PPS information from Report Creator.
Actor: Report Creator
Role: Updates the Report Manager with the creation of a Reporting Workitem PPS, when theReport Creator starts the work.
Actor: Post-Processing Manager

1175

Role: Accept post-processing PPS information from the Evidence Creator.
4.39.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Performed Procedure Step SOP Class
4.39.4 Interaction Diagram
Evidence
CreatorPost-Processing
Manager

GP-PPS N-CREATE

Report Creator

Report Manager

GP-PPS N-CREATE

48
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1180

4.39.4.1 General Purpose Performed Procedure Step In Progress Message
4.39.4.1.1

Trigger Events

For a post-processing workitem, a user or an automated function on the Evidence Creator begins
a post-processing performed procedure step.
1185

For a reporting workitem, a user begins to perform the scheduled procedure step at the ReportCreator.
4.39.4.1.2

Message Semantics

The Evidence Creator as SCU uses the N-CREATE request of the DICOM General Purpose
Performed Procedure Step SOP to inform the Post-Processing Manager as SCP that a specific
PPS has been started and its status is IN PROGRESS.
1190

4.39.4.1.3

Expected Actions

The Post-Processing Manager or the Report Manager creates the PPS with status IN
PROGRESS.

1195

If a Referenced General Purpose Scheduled Procedure Step Sequence (0040,4016) item ispresent in the N-CREATE request, the Post-Processing Manager or the Report Manager shallupdate the Attribute Resulting General Purpose Performed Procedure Steps Sequence(0040,4015) in the identified General Purpose Scheduled Procedure Step SOP Instance.
The Post-Processing Manager may use the Performed Work Status Update transaction to notify
the interested recipients about the received GP-PPS.

1200

The Report Manager may use the Performed Work Status Update transaction to notify theinterested recipients about the received GP-PPS using for this purpose.
4.39.4.1.3.1 Relationship between Scheduled and Performed Procedure Steps
The relationship between Scheduled and Performed Procedure Step information is shown in thefollowing cases. Refer to Appendix C for details of forming attributes in each of these cases.
4.39.4.1.3.1.1

SPS

Simple Case1

1results
in

PPS

1205
This case indicates a 1-to-1 relationship between SPS and PPS. Information about the Scheduled
Procedure Step and Requested Procedure shall be copied from the Scheduled Procedure Step
object to the Performed Procedure Step Relationship Module.

49
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.39.4.1.3.1.2

Unscheduled Case

0

SPS

1

results
in

PPS

1210
This case indicates a 0-to-1 relationship between SPS and PPS. Information about the Scheduled
Procedure Step and, possibly, Requested Procedure is not available to the Evidence Creator or
Report Creator due to different reasons, e.g., General Purpose Worklist SCP not available,
unplanned post-processing during reporting.
1215

4.39.4.1.3.1.3

Append Case

1

SPS

1
results in

PPS atEvidence Creator or
Report Creator

1-n

1220

PPS appended atEvidence Creator or
Report CreatorThis case indicates a 1-to-N relationship between SPS and PPS where first the PPS is generated
in response to an SPS. Other Performed Procedure Steps are added sequentially at a later time.
All Performed Procedure Steps shall refer back to the same Requested Procedure and to theoriginal SPS. All Requested Procedure and Scheduled Procedure Step attributes shall be copiedfrom the Scheduled Procedure Step Object to the Performed Procedure Step Relationship
Module and to the Request Attribute Sequence of the resulting composite instance.
No PPS can be appended if the SPS status is COMPLETED or DISCONTINUED.
4.39.4.1.3.1.4

SPS

Abandoned Case1

1results
in

PPS

1225

1230

This case indicates a 1-to-1 relationship between SPS and PPS, even though the PPS may or may
not have associated Evidence Documents Images or other data objects. A procedure step may
have to be abandoned for clinical reasons before it is complete. If SOP instances are sent by the
Evidence Creator to the Image Archive or from the Report Creator to Report Manager, then theyshall be identified in the PPS N-SET. This is a means to explicitly communicate this information
to the Post-Processing Manager. All Requested Procedure and Scheduled Procedure Step
50
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
attributes shall be copied from the Scheduled Procedure Step Object to the Performed Procedure
Step Relationship Module.

4.40 Workitem Performed Procedure Step Completed
1235

This section corresponds to Transaction RAD-40 of the IHE Technical Framework. Transaction
RAD-40 is used by Post-Processing Manager and Evidence Creator as well as Report Manager
and Report Creator.
4.40.1 Scope

1240

1245

After completing or discontinuing a post-processing performed procedure step, the Evidence
Creator sends a message to the Post-Processing Manager to update the PPS status to
COMPLETED or DISCONTINUED and references any results that have been created and sent
to the Image Manager/Archive.
Report Creator behaves similarly to update the Report Manager with the PPS status and thereferences to the result that was created and sent to the Report Manager, e.g., an SR object, or an
external ID of an object outside of IHE scope.
4.40.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Workitem PPS
completed
ReportManager

ReportCreatorActor: Evidence Creator
1250

Role: Update the Post-Processing Manager with status of the post-processing PPS when the
Evidence Creator finishes or discontinues work.
Actor: Post-Processing Manager
Role: Accept post-processing PPS information from the Evidence Creator.
Actor: Report Creator

1255

Role: Updates Report Manager with status of the Reporting Workitem PPS, when it finishes ordiscontinues work.
Actor: Report Manager
Role: Accepts PPS information from Report Creator.
4.40.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Performed Procedure Step SOP Class
51
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1260

4.40.4 Interaction Diagram
Evidence
CreatorPost-Processing
Manager

GP-PPS N-SET

Report Manager

Report Creator

GP-PPS N-SET

4.40.4.1 General Purpose Performed Procedure Step Completed Message
4.40.4.1.1
1265

Trigger Events

For a post-processing workitem, automated Evidence Creator, or a user finishes the postprocessing scheduled procedure step.
For a reporting Workitem, a user finishes the work on the scheduled procedure step.
4.40.4.1.2

1270

Message Semantics

The Evidence Creator as SCU uses the N-SET request of the DICOM General Purpose
Performed Procedure Step SOP Class to inform the Post-Processing Manager as SCP that a
specific performed procedure step has been done and its status is COMPLETED. The Evidence
Creator may use N-SET to send intermediate updates of the PPS information. The final N-SET
has either the status of COMPLETED or DISCONTINUED. The Report Manager acts in thesame way as SCU with the Report Manger as SCP. The Report Manager notifies the DSS about
the PPS status through either the Performed Work Status Update or by grouping with it.

1275

When the status is set to COMPLETED or DISCONTINUED, the Evidence Creator shall send to
the Post-Processing Manager a list of all Composite SOP Instances, if any, created in the Output
Information Sequence (0040,4033). Similarly, the Report Creator shall send the list of all SOP
Instances in the Output Information Sequence (0040,4033) or identify non-DICOM output in the
Non-DICOM Output Code Sequence (0040,4032).

1280

4.40.4.1.3

Reporting Message Semantics

After the workitem has been completed, the Report Creator shall provide the Report Manager
with the details of the reporting task that has been performed. This information shall be included
into the Performed Work Item Code Sequence in the General Purpose Performed Procedure Step
N-SET message. The Report Creator shall also reference any results created during the reporting
52
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1285

1290

task performed. The output information is part of the General Purpose Performed Procedure Step
Results Module. The output data must be stored to an appropriate data repository. Which datarepository is used will depend on the type of the output data that might be a report, an audio file,an Evidence Document or other objects.
The Report Creator may also suggest subsequent work items to the Report Manager. The
requested subsequent work items are included in the General Purpose Performed Procedure Step
Results Module.
4.40.4.1.4

Expected Actions

The Post-Processing Manager or Report Manager updates the status of the PPS to COMPLETED
or DISCONTINUED.
1295

4.41 Workitem CompletedThis section corresponds to Transaction RAD-41 of the IHE Technical Framework. Transaction
RAD-41 is used by Post-Processing Manager and Evidence Creator as well as Report Manager
and Report Creator.
4.41.1 Scope

1300

1305

After completing or discontinuing a post-processing scheduled procedure step, the Evidence
Creator sends a message to the Post-Processing Manager to update the SPS status to
COMPLETED or DISCONTINUED. This allows the Post-Processing Manager to update its
worklist.
After completing or discontinuing a reporting scheduled procedure step, the Report Creator
sends a message to the Report Manager to update the SPS status to COMPLETED or
DISCONTINUED. This allows the Report Manager to update its worklist.
4.41.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Workitem completed

ReportManager

ReportCreatorActor: Evidence Creator
1310

Role: Update the Post-Processing Manager with status of the post-processing SPS when the
Evidence Creator finishes work.
Actor: Post-Processing Manager
Role: Accept post-processing GP-SPS information from Evidence Creator.
53
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Actor: Report Creator
1315

Role: Updates Report Manager with status of the Reporting Workitem SPS, when it finishes thework.
Actor: Report Manager
Role: Accepts reporting GP-SPS information from Report Creator.
4.41.3 Referenced Standards

1320

DICOM 2011 PS 3.4: General Purpose Scheduled Procedure Step SOP Class
4.41.4 Interaction Diagram
Evidence
CreatorPost-Processing
Manager

GP-SPS N-ACTION

Report Creator

Report Manager

GP-SPS N-ACTION

4.41.4.1 General Purpose SPS Completed Message
4.41.4.1.1
1325

Trigger Events

For a post-processing workitem, a user or automated function on the Evidence Creator finishes
the post-processing scheduled procedure step.
For the reporting workitem, a user finishes the work on the scheduled procedure step at theReport Creator.
4.41.4.1.2

1330

1335

Message Semantics

The Evidence Creator as SCU uses the N-ACTION request of the DICOM General Purpose
Scheduled Procedure Step SOP Class to inform the Post-Processing Manager as SCP that a
specific scheduled procedure step has been finished and its status is COMPLETED. Thismessage informs the Post-Processing Manager that the SPS is complete and that further PPS will
not be created for this SPS. The Evidence Creator may also discontinue a SPS with a status of
DISCONTINUED.

54
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1340

In the same way, the Report Creator uses the N-ACTION request of the DICOM General
Purpose Scheduled Procedure Step SOP Class to inform the Report Manager as SCP that a
specific scheduled procedure step has been finished and its status is COMPLETED. Thismessage informs the Report Manager that the workitem SPS is complete and that further PPS
will not be created for this SPS. The Report Creator may also discontinue a SPS with a status of
DISCONTINUED.
4.41.4.1.3

Expected Actions

The Post-Processing Manager or the Report Manager updates the status of the SPS to
COMPLETED or DISCONTINUED.
1345

In addition, the Post-Processing Manager or Report Manager informs the DSS and ImageManager using the Performed Work Status Update transaction.

4.42 Performed Work Status Update
This section corresponds to Transaction RAD-42 of the IHE Technical Framework. Transaction
RAD-42 is used by the Department System Scheduler, Report Manager and Image Manager.
1350

4.42.1 Scope
This transaction is used by the Department System Scheduler, Report Manager or the ImageManager to inform the others of the status of performed work being managed. This transaction
allows the system not managing the performed work to stay in sync with the status.

1355

How or whether the non-managing system uses this information is at the discretion of
implementers and customers. Some examples are given below:
•

1360
•
•
1365

The Department System Scheduler is grouped with the Post-Processing Manager andmanages all post-processing tasks. This transaction enables the Department System
Scheduler to notify the Image Manager about the Post-Processing work that has been
performed, e.g., CAD has been performed on a set of images and an evidence document
has been stored.
The Image Manager is grouped with the Post-Processing Manager and manages somepost-processing tasks. This transaction enables the Image Manager to notify the
Department System Scheduler about the post-processing work that has been performed.
The Report Manager is implemented as a standalone system and manages reporting tasks.
This transaction enables Report Manager to notify Department System Scheduler andImage Manager that report has been completed.

55
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.42.2 Use Case Roles
Department System
Scheduler/PostProcessing Manager

ReportManagerImage
Manager/PostProcessing Manager

Performed Work
Status Update

Actor: Department System Scheduler
1370

Role: When managing tasks (i.e., is grouped with a Post-processing Manager), it must send task
status notifications to the Image Manager and Report Manager. When monitoring the status oftasks managed by the Image Manager or Report Manager it must be ready to receive task status
notifications.
Actor: Image Manager

1375

Role: When managing tasks (i.e., is grouped with a Post-processing Manager), it must send task
status notifications to the Department System Scheduler and Report Manager. When monitoring
the status of tasks managed by the Department System Scheduler or Report Manager it must be
ready to receive task status notifications.
Actor: Report Manager

1380

Role: When managing tasks (i.e., implementing Reporting Worklist, Workitem Claimed,
Workitem Completed, Workitem Performed Procedure Step In Progress, Workitem Performed
Procedure Step Completed), it must send task status notifications to the Department System
Scheduler and Image Manager. When monitoring the status of tasks managed by the Department
System Scheduler or Image Manager it must be ready to receive task status notifications.

1385

4.42.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Performed Procedure Step SOP Class

56
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.42.4 Interaction Diagram
Department System Scheduler /Post-Processing Manager

Image
Manager

Report Manager

General Purpose PPS
N-CREATE

Scenario A

General Purpose PPS
N-SETGeneral Purpose PPS
N-CREATE
General Purpose PPS
N-SET

Department
System Scheduler

Image Manager /Post-Processing Manager
Scenario B

Report Manager

General Purpose PPS
N-CREATE
General Purpose PPS
N-SETGeneral Purpose PPS
N-CREATE
General Purpose PPS
N-SET

Department
System Scheduler

Report Manager
Scenario C

Image Manager

General Purpose PPS
N-CREATE
General Purpose PPS
N-SETGeneral Purpose PPS
N-CREATE
General Purpose PPS
N-SET

4.42.4.1 Post-Processing Performed Procedure Step Created/Updated Message
1390

4.42.4.1.1

Trigger Events

In scenario A, the Department System Scheduler is grouped with a Post-Processing Manager andreceives status creation or update on tasks it manages. In scenario B, the Image Manager, due to57
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1395

being grouped with a Post-Processing Manager, receives status creation or updates on tasks it
manages, e.g., from an Evidence Creator. In Scenario C, Report Manager receives status creation
or updates on tasks it manages from Report Creator. In either scenario, for example, a GP-PPS
Completed message received by the Post-Processing Manager or Report Manager shall trigger
the Work Status Update message to be sent.
4.42.4.1.2

1400

1405

1410

1415

1420

1425

1430

Message Semantics

In scenario A, the Department System Scheduler uses the N-CREATE and N-SET requests of
the DICOM General Purpose Performed Procedure Step SOP to inform the Image Manager andReport Manager when work has been started and when it is complete. The Department System
Scheduler performs the SCU role, and the Image Manager and Report Manager perform the SCP
role.
In scenario B, the Image Manager uses the N-CREATE and N-SET requests of the DICOM
General Purpose Performed Procedure Step SOP to inform the Department System Scheduler
and Report Manager when work has been started and when it is complete. The Image Manager
performs the SCU role, and the Department System Scheduler and Report Manager perform the
SCP role.
In scenario C, the Report Manager uses the N-CREATE and N-SET requests of the DICOM
General Purpose Performed Procedure Step SOP to inform the Department System Scheduler
and Image Manager when work has been started and when it is complete. The Report Manager
performs the SCU role, and the Department System Scheduler and Image Manager performs the
SCP role.
“Performed work” may consist of one or more related sub-workitems managed by the SCU, whois acting as the workflow manager for these workitems. As the SCU receives status information
about each sub-workitem, it will in turn update the SCP. The SCU sends N-CREATE with GPPPS status of “IN PROGRESS” after the sub-workitem has been claimed, but no later than thefirst workitem performed procedure step in progress transaction for that sub-workitem has been
performed. In the N-CREATE, the SCU uses the Performed Workitem Code Sequence(0040,4019) to communicate the sub-workitem. The SCU may use N-SET to send intermediate
updates. The final N-SET with GP-PPS status of “COMPLETED” is sent after the sub-workitem
GP-SPS is completed. If there are further sub-workitems managed by the SCU, N-SET willcontain the Requested Subsequent WorkItem Code Sequence, indicating the next workitem itwill be updating. When the SCU finishes updating all sub-workitems it manages, this attribute
will be sent with the workitem of “No Subsequent Workitems,” signifying the end of this set of
performed work. This means that another workflow manager may take over managing
subsequent set of work.
Post-Processing Manager and Report Manager shall generate unscheduled GP-PPS to use in the
Performed Work Status transaction; they cannot simply re-transmit the GP-PPS received fromthe Evidence Creator or Report Creator. To populate Performed WorkItem Code Sequence, theyshall use appropriate codes from DCMR Context Group 9231 (see Table 4.42-1).

58
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table 4.42-1: Context ID 9231 – General Purpose Workitem Definition
Coding Scheme Designator(0008,0102)

1435

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM

110001

Image Processing

DCM

110002

Quality Control

DCM

110003

Computer Aided Diagnosis

DCM

110004Computer Aided Detection

DCM

110005Interpretation

DCM

110006

Transcription

DCM

110007

Report Verification

DCM

110008Print

DCM

110009No subsequent Workitems

4.42.4.1.3

Expected Actions

The Department System Scheduler or Image Manager records and uses the information as
appropriate to its responsibilities.

4.43 Evidence Document Stored
1440

This section corresponds to Transaction RAD-43 of the IHE Technical Framework. Transaction
RAD-43 is used by the Acquisition Modality and Evidence Creator actors.
4.43.1 Scope
In the Evidence Documents Stored transaction, the Acquisition Modality or the Evidence Creatortransmits an Evidence Document, which is stored in the Image Archive.

1445

1450

Evidence Documents are DICOM composite objects that are produced as a result of performing
procedure steps such as image acquisition, image processing or computer-aided detection.
These objects are intended to serve as evidence for diagnostic interpretation; however, they are
not images but rather DICOM Structured Reporting documents. Evidence Documents represent
the uninterpreted information which is primarily managed and used inside imaging department,
although distribution outside Radiology is not precluded. Such objects are not expected to be
managed by the Report Manager. Objects encoded as SOP Instances of such SOP classes as
Mammography CAD are examples of Evidence documents.

59
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.43.2 Use Case Roles
Acquisition
Modality

Evidence
Creator

Image
Archive

Evidence Document
StoredActor: Acquisition Modality
1455

Role: Records non-imaging evidence information in the Evidence Documents and stores them tothe Image Archive.
Actor: Evidence Creator
Role: Records non-imaging evidence information in the Evidence Documents and stores them tothe Image Archive.

1460

Actor: Image Archive
Role: Accepts and Stores Evidence Document Instances received from the Acquisition Modality
or Evidence Creator.
4.43.3 Referenced Standards

1465

DICOM 2011 PS 3.4: Storage Service Class; Basic Text SR SOP Class; Enhanced SR SOPClass; Comprehensive SR SOP Class; Chest CAD SR SOP Class; Mammography CAD SR SOPClass; OB-GYN Ultrasound Procedure Reports; Catheterization Lab SR; Vascular UltrasoundSR.
This list is intended to provide a base list of examples. It is expected that DICOM will continue
to publish additional SR SOP Classes and Templates appropriate for Evidence Documents.

1470

4.43.4 Interaction Diagram
Acquisition
Modality

Image
Archive

Evidence Document Stored

Evidence
CreatorEvidence Document Stored(C-STORE)(C-STORE)

60
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.43.4.1 Evidence Document Stored
This transaction relates to the “DICOM C-STORE” event between the Acquisition modality or
the Evidence Creator and the Image Archive in the above interaction diagram.
1475

4.43.4.1.1

Trigger Events

The Acquisition Modality or the Evidence Creator generates Evidence Documents that need to
be archived.
4.43.4.1.2
1480

1485

Message Semantics

The Acquisition Modality or the Evidence Creator uses the DICOM C-STORE message totransfer the Evidence Documents (as SR objects) to the Image Archive for storage. The
Acquisition Modality or the Evidence Creator is the DICOM Storage SCU and the Image
Archive is the DICOM Storage SCP.
It is a requirement that certain information be recorded in the Evidence Document header. The
details of mapping such information to DICOM SOP instances are specified in RAD TF-2:
Appendix A.2, Table A.2-1.
4.43.4.1.3

Expected Actions

The DICOM Standard (2011) defines a number of non-image storage SOP classes that may be
used for creation of Evidence Documents. It is expected that the Image Archive will support
multiple storage SOP classes as defined in Table 4.43-1 below.
1490
Table 4.43-1: Suggested Evidence Document SOP Classes
SOP Class UID

SOP Class Name

1.2.840.10008.5.1.4.1.1.88.50

Mammography CAD SR

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR

1.2.840.10008.5.1.4.1.1.88.65

Chest CAD SR

It is also expected that the Image Archive will support one or more Templates that are defined to
be used with the Evidence Documents, as specified in the Table 4.43-2.
1495

Table 4.43-2: Suggested Evidence Document Templates
Template ID

Template Name

TID 4000

Mammography CAD Document Root Template

TID 5000

OB-GYN Ultrasound Procedure Report

TID 3500

Hemodynamics Report

TID 4100

Chest CAD SR Document Root Template

TID 5100

Vascular Ultrasound Procedure Report Template

The Image Archive must support storage level 2: i.e., all type 3 attributes must be supported.
61
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.43.4.1.3.1 Mammography Image Profile
Evidence Creator and Image Manager/Image Archive actors supporting the Mammography
Image Profile shall support the Mammography CAD SR SOP Class.
1500

1505

In particular, CAD systems (acting as Evidence Creators) performing analysis on Mammography
images shall be able to return their results in Mammography CAD SR SOP Class instances. This
does not preclude them from additionally creating Presentation States and/or Secondary Capture
or Mammography images.
Also, Image Manager/Image Archive actors shall not only be able to receive Mammography
CAD SR SOP Class objects from the Evidence Creator, but also be able to return them in
response to queries (i.e., they must actually be stored intact for later retrieval, not merely
processed or burned in to images dynamically). See Retrieve Evidence Transaction Section
4.45.4.2.3.1.

4.44 Query Evidence Documents
1510

This section corresponds to Transaction RAD-44 of the IHE Technical Framework. Transaction
RAD-44 is used by the Image Archive and Image Display actors.
4.44.1 Scope
This section describes the sequence of Transactions required for the Image Display to query the
Image Archive for instances of Evidence Documents.

1515

4.44.2 Use Case Roles
Image
Archive

Image
Display

Query
Evidence

Actor: Image Display
Role: Query for Evidence Documents objects (generally in order to retrieve them).
Actor: Image Archive
1520

Role: Respond to queries from the Image Display for Evidence Documents objects.
4.44.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service Class

62
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.44.4 Interaction Diagram
Image Archive

Image Display

Query Evidence Documents (C-FIND)
Query Responses (C-FIND)

1525

4.44.4.1 Query Evidence Documents
The Query (Study Root – FIND and optionally Patient Root – FIND) SOP Classes shall besupported. Refer to DICOM 2011 PS 3.4: Query/Retrieve Service Class for detailed descriptive
semantics.
4.44.4.1.1

1530

Trigger Events

Image Display needs to obtain information about Evidence Documents.
4.44.4.1.2

Message Semantics

The message semantics are defined by the DICOM Query/Retrieve SOP Classes.

1535

A C-FIND Request from the DICOM Study Root Query/Retrieve Information Model – FIND
SOP Class or the DICOM Patient Root Query/Retrieve Information Model – FIND SOP Class
shall be sent from the Image Display to the Image Archive.
The Image Display uses one or more matching keys as filter criteria to obtain the list of matching
entries in the Image Archive at the selected level (Patient & Study/Series/Instance).

1540

In addition to the required and unique keys defined by the DICOM Standard, the IHE Technical
Framework has defined matching and return keys to be supported by query SCUs and SCPs. The
keys are defined in RAD TF-2: 4.14.4.1.2 and Table 4.14-1. The conventions for key usage aredefined in RAD TF-2: 2.2. For the Image Display (SCU) and the Image Archive (SCP) the
additional Evidence Document Instances specific keys are defined in Table 4.44-1.
Table 4.44-1: Evidence Document Instance Specific Query Matching and Return Keys
Attribute Name

Tag

Query Keys Matching

Query Keys Return

SCU

SCU

SCP

SCP

Evidence Document Instance Specific Level
Content Date

(0008,0023)

O

O

O

R+

Content Time

(0008,0033)

O

O

O

R+

Referenced Request Sequence(0040,A370)>Study Instance UID(0020,000D)

O

O

R+*

R+

63
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

1545

Tag

Query Keys Matching

Query Keys Return

SCU

SCU

SCP

SCP

>Accession Number(0008,0050)

O

O

R+

R+

>Requested Procedure ID(0040,1001)

O

O

R+

R+

>Requested Procedure Code
Sequence(0032,1064)>>Code Value(0008,0100)

O

O

O

R+

>>Coding Scheme Designator(0008,0102)

O

O

O

R+

>>Coding Scheme Version(0008,0103)

O

O

O

R+

>>Code Meaning(0008,0104)

O

O

O

R+

Content Template Sequence(0040,A504)>Template Identifier(0040,DB00)

O

O

R+

R+

Concept Name Code Sequence(0040,A043)>Code Value(0008,0100)

O

O

R+*

R+

>Coding Scheme Designator(0008,0102)

O

O

R+*

R+

>Coding Scheme Version(0008,0103)

O

O

O

R+

>Code Meaning(0008,0104)

O

O

R+

R+

4.44.4.1.3

Expected Actions

The Image Archive receives the C-FIND request, performs the matching on the provided keys
and sends the list of matching records back to the Image Display via C-FIND responses.
The Image Display is expected to use the Template ID to select Evidence Documents for
retrieval that it supports.
1550

4.44.4.1.3.1 Mammography Image Profile
Image Display and Image Manager/Image Archive actors supporting the Mammography Image
Profile shall support the Mammography CAD SR SOP Class.

4.45 Retrieve Evidence Documents
1555

This section corresponds to Transaction RAD-45 of the IHE Technical Framework. Transaction
RAD-45 is used by the Image Archive, Image Display, Imaging Document Source and Imaging
Document Consumer.
4.45.1 Scope1560

In the Retrieve Evidence Documents Transaction, the requested DICOM Evidence Documents
are transferred from the Image Archive to the Image Display or from the Imaging Document
Source to the Imaging Document Consumer.

64
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.45.2 Use Case Roles
Image Archive

Imaging Document
SourceImage Display

Imaging Document
Consumer

Retrieve Evidence
Documents

Actor: Image Archive:
Role: Sends requested Evidence Documents to the Image Display Actor.
1565

Actor: Imaging Document Source
Role: Sends requested Evidence Documents to the Imaging Document Consumer.
Actor: Image Display
Role: Receives requested Evidence Documents from the Image Archive Actor.
Actor: Imaging Document Consumer

1570

Role: Receives requested Evidence Documents from the Imaging Document Source
4.45.3 Referenced Standards
DICOM 2011 PS 3.4: Query/Retrieve Service Class, Storage SOP Class
4.45.4 Interaction Diagram
Image Archive

Image Display

Retrieve Evidence documents (C-MOVE)Store Evidence Documents (C-STORE)

RenderEvidence
Documents

1575

4.45.4.1 Retrieve Evidence Documents
The Retrieve (Study Root – MOVE and optionally Patient Root - MOVE) SOP Classes shall besupported. The Image Archive as an SCU shall support DICOM Storage SOP Classes that may
be used as Evidence Documents. The Imaging Document Source as an SCU shall support65
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1580

DICOM Storage SOP Classes that may be used as Evidence Documents it published for sharing.
Refer to DICOM 2011 PS 3.4, Annex C, for detailed descriptive semantics (see Table 4.38-1).

1585

In the case of retrieving Evidence Documents in a Cross-Enterprise, imaging document sharing(XDS-I.b) network environment, a configuration of mapping the AE Titles to DICOM AE
Network Addresses (IP Address and Port number) is needed to be exchanged between the
Imaging Document Source and the Imaging Document Consumer. Appendix G describes indetails the AE Title mapping to the DICOM AE Network Addresses.
4.45.4.1.1

Trigger EventsThe Image Display or the Imaging Document Consumer selects specific Evidence Document
objects to retrieve from the Image Archive or the Imaging Document Source.
4.45.4.1.2

Message Semantics

1590

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the
DICOM 2011 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the ImageManager or Imaging Document Source to assure that the patient and procedure information iscurrent in the Evidence Document objects when they are retrieved from the Image Archive or
Imaging Document Source.

1595

4.45.4.1.3

Expected Actions

The Image Archive or the Imaging Document Source receives the C-MOVE request, establishes
a DICOM association with the Image Display or the Imaging Document Consumer, and uses the
DICOM C-STORE command to transfer the requested Evidence Document objects.
1600

Since the Image Display or the Imaging Document Consumer can select compatible documents
based on the Template IDs returned in the query, the Image Display or the Imaging Document
Consumer is required not to return an error to the Image Archive or the Imaging Document
Source due to the retrieved document content. The retrieved results may simply be discarded
instead.
4.45.4.2 Render Evidence Documents

1605

This transaction relates to the “Render Evidence Documents” event of the above interaction
diagram.
4.45.4.2.1

Trigger EventsThe Image Display or the Imaging Document Consumer receives Evidence Document instancesfrom the Image Archive or the Imaging Document Source.
1610

4.45.4.2.2

Invocation Semantics

1615

This is a local invocation of functions resident within the Image Display or the Imaging
Document Consumer. Evidence Documents shall be displayed to the user of the Image Display
or the Imaging Document Consumer. The method used by the Image Display or the Imaging
Document Consumer to present Evidence Documents for viewing by the user is outside thescope of the IHE Technical Framework. For example, in the case when an Image Display or an
66
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Imaging Document Source is grouped with an Evidence Creator, the Evidence Document may berendered as input for further processing by the Evidence Creator.
4.45.4.2.3
1620

1625

Expected Actions

The Image Display or the Imaging Document Consumer renders the Evidence Documents
retrieved. If the Image Display or the Imaging Document Consumer is unable to handle parts ofthe document, it may inform the user and offer the choice of doing a “low-grade” rendering or
ignoring the data.
Evidence Documents may contain references to other types of evidence objects. The Image
Display or the Imaging Document Consumer shall always be able to render (or “low-grade”
render) referenced Evidence Documents or to invoke other rendering display functionality.
If the Image Display also supports the Consistent Presentation of Images Profile, it is also
required to apply any presentation states referenced in the Evidence Document for application to
the relevant images.

1630

If the Image Display also supports the Key Image Notes Profile, it is also required to render any
Key Image Notes referenced in the Evidence Document.

1635

Note: It is recommended to use the just retrieved instance of the Evidence Document to ensure that the most recent patient
data be displayed to reflect possible patient merge and patient update in the Image Manager/Image Archive. Thispatient data may be inconsistent with patient data contained in a previously retrieved copy of the same Evidence
Document instance.

4.45.4.2.3.1 Mammography Image Profile
Image Display and Image Manager/Image Archive actors supporting the Mammography Image
Profile shall support the Mammography CAD SR SOP Class.
1640

Image Display actors shall be able to apply Mammography CAD SR information to displayed
images; see RAD TF-2:4.16.4.2.2.1.1.8 Display of CAD Marks. It is not permitted to ignore datathat has a rendering intent of presentation required; there is no such thing as a “low-grade”
rendering for Mammography CAD SR.

4.46 Query Reporting Worklist
1645This section corresponds to Transaction RAD-46 of the IHE Technical Framework. Transaction
RAD-46 is used by Report Manager and Report Creator.
4.46.1 Scope

1650

This transaction is used during Reporting work done by the Report Creator to find out what tasks
have been scheduled or assigned to it by the Report Manager. This transaction allows the ReportManager to provide the Report Creator with a worklist that shall contain Reporting-related
workitem codes for conducting Interpretation of Images, Dictation, Transcription andVerification of the report.
The Report Manager is the provider of the worklist. It obtains the necessary information about
the patient and type of a procedure through the Procedure Scheduled transaction from the67
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1655

1660

Department System Scheduler. It is being notified about the existence of images and otherevidence objects through the Modality Procedure Step completed transaction from Performed
Procedure Step Manager, and may confirm their availability through the Images Available
Query.
The Report Creator retrieves the worklist and includes received information such as patient
demographics, Study Instance UID, etc., in the resulting instances (see Appendix D), which are
stored through instance stored transactions such as Evidence Document Stored, Image Stored,
etc.
4.46.2 Use Case Roles
Report Creator

Report Manager

Query Reporting
Worklist

Actor: Report Creator
1665

Role: Queries the Report Manager for Reporting Scheduled Procedure Steps.
Actor: Report Manager
Role: Schedules Reporting procedure steps for the workitems of Interpretation, Dictation,
Transcription and Verification as applicable; accepts query requests for Worklist items andreturns responses.

1670

4.46.3 Referenced Standards
DICOM 2011 PS 3.4: General Purpose Worklist SOP Class
4.46.4 Interaction Diagram
Report Creator

Report Manager

Query GP Worklist
Receive GP Worklist

4.46.4.1 Query General Purpose Worklist Message
1675

This is the worklist query sent to the Report Manager.

68
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.46.4.1.1

Trigger Events

A user or an automated function on the Report Creator queries for scheduled Reporting worklist
items.
4.46.4.1.2
1680

Message Semantics

C-FIND request of the DICOM General Purpose Worklist SOP Class is used to query for thegeneral purpose worklist. Report Creator performs the SCU role, and the Report Manager
performs the SCP role.
4.46.4.1.2.1 Matching Keys and Return Keys

1685

The Report Creator is required to query for specific attributes (return keys) that will be inserted
into the instances created as a result of creation of a diagnostic report. See Appendix D for moredetails.
The Report Creator shall support individually each one of the required query keys listed in Table
4.46-3 - Return and Matching Keys For Reporting Worklist. In addition, at least one of thefollowing two combinations shall be implemented by the Report Creator:

1690

1695

1. Patient Oriented Query: Query for a worklist for a specific patient/procedure. The SCU shallsupport all combinations (31) of the matching key attributes listed in Table 4.46-1 by including 1
or more keys. The sequence attributes denoted in the italics are not matching keys on their own
but have to be included in a query to convey the value of the attributes contained within them.
Thus, the SCU shall support any combination of Patient’s Name, Patient ID, Accession Number,
Requested Procedure ID, and Scheduled Workitem Code.
Table 4.46-1: GPWL Keys for Patient Oriented QueryMatching Key Attributes

1700

Tag

Patient's Name

(0010,0010)

Patient ID(0010,0020)

Referenced Request Sequence(0040,A370)>Accession Number(0008,0050)>Requested Procedure ID(0040,1001)

Scheduled Workitem Code Sequence(0040,4018)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

2. User-oriented Query: Query for a broad worklist for particular user being logged in on aparticular station. The SCU shall support all (63) combinations of the matching key attributes
listed in Table 4.46-2 by including 1 or more keys. The sequence attributes denoted in the italics
are not matching keys on their own but have to be included in a query to convey the value of theattributes contained within them. Code Value of the Scheduled Station Name Code Sequence, if
69
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1705

valued, shall be set to the AE Title of the workstation’s General Purpose Worklist SCU.
Table 4.46-2: GPWL Keys for User-Oriented Queries
Matching Key Attributes

Tag

General Purpose Scheduled Procedure Step Status(0040,4001)

Scheduled Station Name Code Sequence(0040,4025)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

Scheduled Procedure Step Start Date and Time(0040,4005)

Scheduled Workitem Code Sequence(0040,4018)>Code Value(0008,0100)>Coding Scheme Designator(0008,0102)

Scheduled Human Performers Sequence(0040,4034)>Human Performer Code Sequence(0040,4009)>>Code Value(0008,0100)>>Coding Scheme Designator(0008,0102)>Human Performer's Name

(0040,4037)

4.46.4.1.2.2 Examples for the Use of Matching Key Attributes
•
1710
•
•
•
1715

Using the Scheduled Procedure Step Start Date and Time key: query for all the Reportingtasks scheduled for today.
Using the Scheduled Workitem Code key: query for all Transcription tasks.
Using Scheduled Human Performer Name key: query for all the Reporting tasks that arescheduled for this radiologist.
Using the Scheduled Procedure Step Start Date and Time, Scheduled Workitem Code and
Scheduled Human Performer Name keys: query for all the report verification tasks thatare scheduled for today on for this radiologist.

Note: Applications are recommended to append a wildcard "*" at the end of each component of the structured Patient
Name to facilitate matching with both structured and unstructured Patient Names.

1720

4.46.4.1.2.3 Matching Keys and Return Keys
The Report Creator is required to query for specific attributes (return keys), many of which will
be required in the objects it creates. The requirements for the attributes in the stored objects aredefined in Appendix D. There are additional attributes that may be queried but might not be used
elsewhere.

1725

Table 4.46-3 summarizes the matching key requirements and lists the optional and required
attributes that may be requested and shall be returned in order to make these available to the user
at the Report Creator. See RAD TF-2: 2.2 for more information on the requirements expressed inthis table.

70
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1730

Table 4.46-3: Matching and Return Keys for ReportWorklist Queries
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

SOP Common
Specific Character Set(0008,0005)

O

O

O

R

SOP Class UID(0008,0016)

O

O

R+*

R

SOP Instance UID(0008,0018)

O

R

R+*

R

General Purpose Scheduled Procedure Step Information
General Purpose Scheduled
Procedure Step Status(0040,4001)

R+

R

R+

R

Input Availability Flag

(0040,4020)

O

R

R+

R

General Purpose Scheduled
Procedure Step Priority(0040,4003)

O

R

R+

R

Scheduled Procedure Step ID(0040,0009)

O

O

O

R

Scheduled Workitem Code
Sequence(0040,4018)>Code Value(0008,0100)

R+

R

R+*

R

>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+

R

Scheduled Processing
Applications Code Sequence(0040,4004)>Code Value(0008,0100)

O

R

O

R

>Coding Scheme Designator(0008,0102)

O

R

O

R

>Code Meaning(0008,0104)

-

-

O

R

Scheduled Station Name Code
Sequence(0040,4025)>Code Value(0008,0100)

R+

R

R+*

R

>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>Code Meaning(0008,0104)

-

-

R+

R

Scheduled Station Class Code
Sequence(0040,4026)>Code Value(0008,0100)

O

R

O

R

>Coding Scheme Designator(0008,0102)

O

R

O

R

>Code Meaning(0008,0104)

-

-

O

R

Scheduled Station Geographic
Location Code Sequence(0040,4027)>Code Value(0008,0100)

O

R

O

R

>Coding Scheme Designator(0008,0102)

O

R

O

R

>Code Meaning(0008,0104)

-

-

O

R

Scheduled Procedure Step Start
Date and Time(0040,4005)

R+

R

R+

R

Expected Completion Date andTime(0040,4011)

O

R

O

R

Scheduled Human Performers(0040,4034)

71
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

Sequence>Human Performer Code
Sequence(0040,4009)>>Code Value(0008,0100)

R+

R

R+*

R

>>Coding Scheme Designator(0008,0102)

R+

R

R+*

R

>>Code Meaning(0008,0104)

-

-

R+

R

>Human Performer's Name

(0040,4037)

R+

R+

R+

R+

>Human Performer's Organization(0040,4036)

O

O

O

R+

Referenced Study Component
Sequence(0008,1111)>Referenced SOP Class UID(0008,1150)

O

O

O

R

>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Input Information Sequence(0040,4021)>Study Instance UID(0020,000D)

O

O

R+*

R

>Referenced Series Sequence(0008,1115)>>Series Instance UID(0020,000E)

O

O

R+*

R

>>Retrieve AE Title(0008,0054)

O

O

O

R

>>Storage Media File-Set ID(0088,0130)

O

O

O

O

>>Storage Media File-Set UID(0088,0140)

O

O

O

O

>>Referenced SOP Sequence(0008,1199)>>>Referenced SOP Class UID(0008,1150)

O

O

R+*

R

>>>Referenced SOP Instance UID(0008,1155)

O

O

R+*

R

Relevant Information Sequence(0040,4022)>Study Instance UID(0020,000D)

O

O

O

R

>Referenced Series Sequence(0008,1115)>>Series Instance UID(0020,000E)

O

O

O

R

>>Retrieve AE Title(0008,0054)

O

O

O

O

>>Storage Media File-Set ID(0088,0130)

O

O

O

O

>>Storage Media File-Set UID(0088,0140)

O

O

O

R

>>Referenced SOP Sequence(0008,1199)>>>Referenced SOP Class UID(0008,1150)

O

O

O

R

>>>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Resulting General Purpose
Performed Procedure Step
Sequence(0040,4015)>Referenced SOP Class UID(0008,1150)

O

O

O

R

>Referenced SOP Instance UID(0008,1155)

O

O

O

R

Actual Human Performers
Sequence(0040,4035)>Human Performer Code(0040,4009)

72
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

Sequence>>Code Value(0008,0100)

O

O

O

R

>>Coding Scheme Designator(0008,0102)

O

O

O

R

>>Code Meaning(0008,0104)

-

-

O

R

>Human Performer's Name

(0040,4037)

O

O

O

R+

>Human Performer's
Organization(0040,4036)

O

O

O

R+

Study Instance UID(0020,000D)

O

O

R+*

R

Multiple Copies Flag

(0040,4006)

O

O

O

R

O

O

O

O

O

O

R+*

R

O

O

R+*

R

All other Attributes from theGeneral Purpose Scheduled
Procedure Step Information
ModuleGeneral Purpose Scheduled Procedure Step Relationship
Referenced Request Sequence(0040,A370)>Study Instance UID(0020,000D)>Referenced Study Sequence(0008,1110)>>Referenced SOP Class UID(0008,1150)>>Referenced SOP Instance UID(0008,1155)

O

O

R+*

R

>Requested Procedure ID(0040,1001)

R+

R+

R+

R

>Requested Procedure Description(0032,1060)

O

O

O

R

>Requested Procedure Code
Sequence(0032,1064)>>Code Value(0008,0100)

O

O

O

R

>>Coding Scheme Designator(0008,0102)

O

O

O

R

>>Code Meaning(0008,0104)

-

-

O

R

>Accession Number(0008,0050)

R+

R

R+

R

>Requesting Physician(0032,1032)

O

O

O

R

O

O

O

O

O

O

O

O

>All other Attributes relating to
the Requested Procedure and the
Imaging Service Request in the
General Purpose Scheduled
Procedure Step Relationship
ModulePatient Relationship
All Attributes from the Patient
Relationship Module
Patient Identification
Patient's Name

(0010,0010)

R+

R

R+

R

Patient ID(0010,0020)

R+

R

R+

R

O

O

O

O

All other Attributes from thePatient Identification Module
Patient Demographic

73
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

Tag

Query Keys
Matching
SCU

Query Keys Return

SCP

SCU

SCP

Patient's Birth Date

(0010,0030)

O

O

R+

R

Patient's Sex(0010,0040)

O

O

R+

R

O

O

O

O

O

O

O

O

All other Attributes from thePatient Demographic Module
Patient Medical
All Attributes from the Patient
Medical Module

4.46.4.1.3

Expected Actions

The Report Manager performs the query and sends the matching General Purpose Worklist items
to the Report Creator.
4.46.4.2 Receive General Purpose Worklist Message
1735

This is the message the Report Manager sends containing General Purpose Worklist information
as a response to the Report Creator query.
4.46.4.2.1

Trigger Events

The Report Manager receives a query for a Worklist.
4.46.4.2.2
1740

1745

Message Semantics

C-FIND Response from the DICOM General Purpose Worklist SOP Class will be used for thismessage. Some of the attributes queried through the worklist originate from other sources during
previous steps in the workflow, and are made available to the Report Manager through othertransactions such as MPPS. It is up to the Report Manager to determine the Input Information,e.g., study, series, etc. appropriate to be used in a workitem Scheduled Procedure Step, i.e., it isindependent of the acquisition process and resulting MPPS.
The Post-Processing Manager shall specify the type of task to be performed in the content of the
Scheduled Workitem Code Sequence (0040,4018) using one of the following values from
DCMR CID 9231:

1750

Table 4.46-4: Reporting Workitem Definition
Coding Scheme Designator(0008,0102)

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM

110005Interpretation

DCM

110006

Transcription

DCM

110007

Report Verification

DCM

110009No subsequent Workitems

74
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.46.4.2.3

1755

Expected Actions

A Report Creator displays the worklist to the user who might then select the item to work on.
When the user selects the workitem and performs the report creation work, the Report Creator
will notify the Report Creator of the work progress as defined in the Workitem Claimed andWorkitem Completed transactions.

4.47 Distribute Imaging Information on MediaThis section corresponds to Transaction RAD-47 of the IHE Technical Framework. Transaction
RAD-47 is used by the Portable Media Creator and by media reading actors (Portable Media
Importer, Image Display, Report Reader, Display and Print Composer).
1760

4.47.1 Scope
In the Distribute Imaging Information on Media transaction the Portable Media Creator sends
information to media reading actors by means of Interchange Media where it stores theinformation.
4.47.2 Use Case Roles

1765

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

Role: Read the DICOM content of distributed media in order to access information stored in the
DICOMDIR file and its referenced instances (DICOM FSR) and perform import of media data.
Actor: Image Display
Role: Read the DICOM content of distributed media in order to access information stored in the
DICOMDIR file (DICOM FSR) and display its referenced evidence objects.

1775

Actor: Report Reader
Role: Read the DICOM content of distributed media in order to access information stored in the
DICOMDIR file (DICOM FSR) and read its referenced diagnostic reports.
Actor: Print Composer
75
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1780

Role: Read the DICOM content of distributed media in order to access information stored in the
DICOMDIR file (DICOM FSR) and send print data (images) to the Print Server.
Actor: Display (from ITI TF)
Role: Read the web-viewable content of distributed media in order to access information stored
in the INDEX.HTM file and display its referenced data (XHTML files and JPEG images).
4.47.3 Referenced Standard

1785

DICOM 2011 PS 3.10: Media Storage and File Format for Data Interchange
DICOM 2011 PS 3.11: Media Storage Application Profiles
DICOM 2011 PS 3.12: Media Formats and Physical Media for Data Interchange
DICOM Supplement 80 (final text): DVD Media Application Profiles

1790

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

1795

4.47.4.1 Distribute Imaging Information on MediaThis transaction consists of the interchange of information on media by way of the physicaltransport of the created media from the Portable Media Creator to a media-reading actor.

76
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1800

4.47.4.1.1 Trigger Events
The user at the Portable Media Creator wishes to transport information by the creation andtransport of interchange media. The Portable Media Creator assembles the Interchange Media
content and stores it on the media.
4.47.4.1.2 Message Semantics

1805

The message semantics of this transaction are described in terms of content specifications forthe media.
The Portable Media Creator shall be able to include all DICOM objects supported by the IHE
actors with which it is grouped. If not grouped with any IHE actors, it shall be able to include
all DICOM Storage objects listed in its DICOM Conformance Statement.

1810

4.47.4.1.2.1 Media Filesystem and File Naming Restrictions
Since the DICOM content on the media is required to conform to the DICOM standard, someof the requirements specified in PS 3.10, 3.11 and 3.12 are reiterated here for emphasis:

1815

1820

•
•
•

Strict ISO 9660 Level 1 compliance
No packet writing
File and folder names referenced by the DICOMDIR file restricted to 8 characters,
uppercase letters, digits and underscore only, with no extension

Specifically, it is not permitted to name DICOM files based on their SOP Instance UID, sincethat would exceed the 8 character limit and use the illegal period character, and it is not
permitted to add a “.dcm” extension or similar. Filenames should not be in lower case, norhave lower case equivalent file names encoded as Joliet or Rockridge extensions to the ISO
9660 filesystem.
Refer to Appendix E of this supplement for a reference to common implementation
misinterpretations and/or errors that are detrimental to interoperability.

1825

Non-DICOM data is restricted to ISO 9660 Level 1 compliance, but without the restrictions on
file extensions and characters imposed by DICOM; i.e., a 3 character extension is permitted.
4.47.4.1.2.2 Content Organization Overview
The following diagram illustrates the content organization principles (see Appendix F for
examples):

1830

77
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________DICOMDIR

Identification
Marking<directory of
DICOM files>

Available entry
points to accessmedia content

INDEX.HTM
README.TXT

WEB CONTENT

IHE_PDI<other directories>
Other Content<other files>

Figure 4.47.4.1.2.2-1: Media Content Organization

Description of the content to be contained in the media file system:

1835

1840

4.47.4.1.2.2.1 DICOM Content
The DICOMDIR file shall be located in the root directory and shall reference all DICOM
instances contained in the media.
The DICOM instance files shall not be in the root directory or in the IHE_PDI sub-directory,
instead they shall reside in a sub-directory whose name is not otherwise constrained. No other
DICOM instance files shall be placed on the media.
It is recommended, though not required, to include the README.TXT file described below,
even if the Web Content Option is not supported.
4.47.4.1.2.2.2 Web Content Option
Portable Media Creators implementing the Web Content Option shall meet the following
requirements:

1845

•

INDEX.HTM file located in the root directory, which shall portray the exact content of
the interchange media. The file shall present:•

An informative header containing:
•
•

1850
•
•

Identification of the institution that created the interchange media
Optionally, a disclaimer statement about privacy/security from the institution thatcreated the interchange media

a link to an entry point for accessing the web content of the IHE_PDI directorya link to the README.TXT file78

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
•
•
1855
•
•

a link to additional non-constrained data (if it exists) - See Section 4.47.4.1.2.2.3
a manifest which lists the data that can be imported by a Portable Media Importer
Actor. (i.e., all DICOM content on the media)
a manifest which lists any patient-related data contained on the CD that cannot be
imported (i.e., additional non-constrained content that doesn’t have an importable
DICOM equivalent on the media).
a link to a launch point for a DICOM viewer, if present on the interchange media

1860
Note: The file INDEX.HTM is required to present the content defined above to the user. This does not imply that the
information must necessarily be contained in INDEX.HTM. Instead, INDEX.HTM might also open a frame set
consisting of additional XHTML files that in total contains the information specified above.

1865

•

README.TXT file located in the root directory, that shall contain:••

Contact information regarding the Institution that created the media.
Information regarding the Application that created the media.
•
•

•

1870

•

General information about the overall organization of the interchange media. This is
not intended to be specific to the content stored on this instance of interchange media,
which if necessary should be placed in the INDEX.HTM file.
Information regarding the Media Viewer application (if a Media Viewer is contained)
•
•
•
•
•
•

1875

Name of the product application and software version
Contact information of the vendor of the application that created the media

Operating system(s) supported
Name of the product application and software version
Contact information of vendor that provided the Media Viewer application
Disclaimer statement about the intended usage of the application
List of minimum requirements
Additional information regarding the usage of the application

1880
Note that generally the README.TXT file is independent of the clinical content of the media, i.e., the same
README.TXT may be included on all media created by that application at that institution.
It is recommended that information is included in the README.TXT file about web browsers (including version number)that are known to be capable of displaying the web content as intended.

1885•

IHE_PDI directory located in the root directory of the interchange media which shallcontain:
•

1890

•
•

Web-viewable objects in XHTML, JPEG, PNG and/or GIF derived from the DICOM
encoded objects or used for web page navigation.
The web content shall faithfully represent the patient's clinical condition.
It is not allowed to place any other data in the IHE_PDI directory.
79

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•
1895

It is allowed to have sub-directories within the IHE_PDI directory

Note that these are IHE requirements (not DICOM requirements) that are intended to facilitate the overall organization of
the media and make easier the access to the INDEX.HTM file, especially for non-expert users like patients andreferring physicians.
Note: There is a recognized need for cine/video data, however a standardized method (format) has not yet been identified
for endorsement by IHE and inclusion in this transaction.

4.47.4.1.2.2.3 Optional Content
1900

It is permitted to place other data on the media outside the IHE_PDI directory. Any additional
content shall take into account all constraints listed above especially:••

No DICOM instance files are allowed.
This data shall be described or referenced as defined in Section 4.47.4.1.2.2.2.

Furthermore any additional directory in the root directory cannot begin with “IHE”.
1905

Additional files (files other than mandatory files) in the root directory are not expressly
prohibited however their inclusion is discouraged.
Note that it cannot be assumed that any automatically launching application will run on thereceiving device.
4.47.4.1.2.2.3.1 DICOM Media Viewer

1910

If a DICOM media viewer is present on the media, it is recommended that:
•
•
•

1915

the media viewer be capable of correctly rendering all DICOM objects stored on themediuma user manual in PDF format be included on the medium, in the root directorya short manual in hardcopy be provided within the CD jewel case

4.47.4.1.2.2.4 Media Identification
The Portable Media Creator Actor shall support a user in adding human-readable identification
information on the outside of the physical medium. The method of media marking is outside thescope of this integration profile.

1920

It is recommended that the Patient Name, patient ID, birthdate, media creation date, the study
dates for the studies on the medium and the name of the originating institution be marked on themedium. It is also recommended that the type of content (“DICOM ONLY” or “DICOM PLUSWEB”) be marked on the medium.
4.47.4.1.2.3 Content Organization Detail4.47.4.1.2.3.1 DICOM Content

1925

The DICOM portion of the media content is defined by the current DICOM standard. It is
required that created file-sets be correctly formatted in order to grant maximum interoperability.
All DICOM data shall be referenced by the DICOMDIR file.
80
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

1930

In order to assure interoperable use of the created media, a “widely-used” general purpose
DICOM Media Application Profile is required. The Portable Media Creator, Portable Media
Importer, Image Display, Report Reader and Print Composer shall use the STD-GEN-CD Media
Storage Application Profile to interchange DICOM information on interchange media.
The Portable Media Creator is not required to be able to create media containing data frommultiple patients. However, all media reading actors shall be able to import media containing
multiple patients’ data.

1935

While the Portable Media Creator is not required to correct DICOM SOP instances from a sourcethat incorrectly encodes the DICOM data, it is expected that the DICOM Media Creator willstore the DICOM files in Explicit VR Little Endian. The DICOMDIR, whose content is entirely
the responsibility of the Portable Media Creator, shall be correctly encoded regardless of thecorrectness of any referenced SOP Instances.

1940

The Portable Media Creator may be requested to include DICOM SOP Instances that do notcontain sufficient information to encode mandatory DICOMDIR information. For example,
Patient ID and Study ID are Type 2 and may be zero length in image SOP Instances, but are
Type 1 in the Patient and Study Directory Records. The complete list of attributes which fall into
this category are listed in Table 4.47.4-1

1945
Table 4.47.4-1: Optional DICOM SOP Instance Attributes required in DICOMDIR
Directory
Record Type
Patient ID(0010,0020)

STUDY

Study ID

(0020,0010)

IMAGE

1955

Tag

PATIENTSERIES

1950

Attribute Name

Study Date

(0008,0020)

Study Time

(0008,0030)

Modality(0008,0060)

Series Number(0020,0011)

Instance Number(0020,0013)

The Portable Media Creator is required to synthesize appropriate values for all such mandatory
attributes. No specific guidance is given as to from whence appropriate values should beobtained or what default values are appropriate, except that different patients, studies, and series
must remain distinct (e.g., two different Studies with differing Study Instance UIDs shall not be
assigned the same synthesized Study ID). There is no firm requirement that a synthesized Patient
ID must be globally unique as it is not a UID. However, it is the only Type 1 attribute for Patient
Directory Records and is a key index value for searching. Any synthesized Patient ID values
shall be unique, at least in the context of the DICOMDIR on the media being created, so thateach corresponding Patient Directory Record will be guaranteed to be unique. Implementersmust also be careful to ensure that multiple Patient Directory Records do not link to Study
Directory Records with the same Study Instance UID. The requirements for synthesizing new
Study ID values are less rigid as Study Directory Records are still guaranteed to have unique
81
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
1960

Study UID values. The Portable Media Creator is not required to add these synthesized values tothe instances to be stored on media.
4.47.4.1.2.3.1.1 DICOM Instances Content
There are no additional requirements specified here on the Attributes contained within DICOM
Instances on the media.

1965

1970

1975

1980

If the Portable Media Creator Actor is grouped with an Acquisition Modality (or other) Actor
within the Scheduled Workflow Integration Profile, then the attributes may effectively beconstrained beyond the normative requirements of the DICOM standard. For example certain
attribute values in the Modality Worklist query shall be included.
However, since such grouping is not required under this profile, actors receiving created media
such as the Portable Media Importer, Image Display, Report Reader and Print Composer may notassume that the DICOM Instance Attributes are constrained beyond the definitions of the IODs
in the DICOM Standard.
The instances on the Interchange Media generated by a Portable Media Creator shall all be
DICOM Composite IODs. Therefore the Interchange Media shall not contain instances from thefollowing SOP Classes:
•
•
•
•
•
•
•
•

Detached Patient Management SOP Class
Detached Study Management SOP Class
Detached Visit Management SOP Class
Study Component Management SOP Class
Modality Performed Procedure Step SOP Class
Detached Result Management SOP Class
Detached Interpretation Management SOP ClassStored Print Storage SOP Class

4.47.4.1.2.3.1.2 DICOMDIR Directory Content
1985

There are no additional DICOMDIR keys required beyond those required by the DICOM STDGEN-CD specification.
No private elements shall be included in the standard directory records and no private directory
records shall be present.

1990

1995

The following types of Directory shall not be used in the Basic Directory object (DICOMDIRFile):
•
•
•
•
•
•
•

VISIT
RESULTS
INTERPRETATIONSTUDY COMPONENTSTORED PRINTTOPICPRIVATE
82

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________The PATIENT, STUDY, SERIES Directory Records shall follow the following rules:
2000

•
•
•
•

2005
•
•
2010

Only one Directory Record per Patient ID shall be present in the DICOMDIR.
Only one STUDY Directory Record per Study Instance UID shall be present in the
DICOMDIR; this implies that a study belongs to a single patient.
Only one SERIES Directory Record per Series Instance UID shall be present in the
DICOMDIR; this implies that a series belongs to a single study.
Only one composite instance level Directory Record shall be present per SOP Instance
UID; this implies that an instance belongs to only a single series.
Only one HL7 STRUC DOC Directory Record shall be present per SOP Instance UID;
this implies that an instance belongs to only a single Patient.
Only one HANGING PROTOCOL Directory Record shall be present per SOP Instance
UID

Users should review the supported Media Storage SOP Classes in the Conformance Statementsof media creators and readers to ensure interoperability in the interchange of media objects.
4.47.4.1.2.3.1.3 DICOM Report Content
It is highly recommended to place diagnostic reports on the media.

2015

2020

The Portable Media Creator Actor, if grouped with a Report Creator Actor, shall support theability to create a diagnostic imaging report. A Basic Text DICOM SR, according to a proper
subset of the Simple Image Report Pattern as defined by the SINR Integration Profile, can becreated and this kind of diagnostic report can be imported by a Portable Media Importer.
Additional optional diagnostic reports in non-DICOM formats (such as HL7 CDA) are notdefined by this transaction and may be placed on the media without the need to create DICOM
SRs, but they will be non-importable data.
Note: This requirement may be met with other DICOM SR SOP Classes that are used for diagnostic or therapeutic reports.
For the most basic radiology report, a simple pattern with one or more sections including a paragraph of text meets
this requirement. Image references do not have to be included, but may be if so desired.

2025

4.47.4.1.2.3.2 Web Content Option
Portable Media Creators claiming the Web Content Option shall meet the following
requirements:

2030

End-users should be able to access information at a minimum using a web browser to viewcontent on media. In order to grant maximum interoperability using the stored XHTML files,
they shall be formatted according to the XHTML Basic and W3C HTML Compatibility
Guidelines provided in Appendix C of the W3C XHTML 1.0 Recommendation.
The web-viewable data that is generated by Portable Media Creators claiming the Web Content
Option shall:•2035

contain the web representation of a subset of the media’s DICOM information, using only
XHTML files, JPEG referenced images, and PNG and/or GIF files used for navigation,

83
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
•
•
2040

•

contain hyperlinks within XHTML files which contain only lowercase letters to promoteinteroperability across O/S Platforms,
reside in the IHE_PDI, while the corresponding DICOM data from which it is derived islocated in a different sub-directory (see Section 4.47.4.1.2.2.1), andbe completely referenced in the INDEX.HTM file

The web-viewable data included shall be a set or subset that was considered at the time ofcreation to faithfully represent the patient's clinical condition.

2045

If the Portable Media Creator supports Presentation States, it shall have the capability to apply
them to the relevant images when including web-viewable content. The user of the application
may choose not to make use of this capability.
The constraints placed by DICOM on the ISO 9660 file system are not required for webviewable content, i.e., a 3-character extension is permitted.

2050

2055

2060

2065

To ensure interoperability, JPEG means a file with a JFIF header and encoded using thesequential Huffman DCT 8bit per component process (baseline), and the progressive variant
thereof.
To ensure interoperability the use of XHTML shall be limited to static and restricted forms ofdynamic web content. At this time Dynamic Web Content such as DHTML and most Scripting
Languages are explicitly prohibited as no single established Standard exists to ensureinteroperability between web browsers. The use of JavaScript is explicitly permitted, recognizingthat there may be issues with different browsers. Portable Media Creators should make every
effort to use portable constructs or use JavaScript that works with or adapts to all known portablebrowsers; further, the failure of JavaScripts should not make the resulting web pages unusable.
Because XHTML rather than legacy HTML is required, it is necessary to provide information
about appearance using either embedded styles or an external stylesheet, since legacy attributes
controlling appearance are not permitted in XHTML Strict. The use of Cascading Stylesheets(CSS) is explicitly permitted, recognizing that there may be issues with different browsers.
Portable Media Creators should make every effort to use portable constructs or use CSS thatworks with or adapts to all known portable browsers; further, the failure of CSS should not makethe resulting web pages unusable.
Additional optional web-viewable content not derived from DICOM objects may be stored on
the media, but not in the IHE_PDI directory.
4.47.4.1.3 Expected Actions

2070

2075

The receiving/reading actors read the patient’s data from the media and act upon it as specified
below. The receiving actor shall document which DICOM objects it supports in its Conformance
Statement. If a SOP Class on the media is not supported, the actor shall present the user with asummary of the data that could not be acted upon, containing the Patient Name(s) and ID(s),Study ID(s), Study Date(s), Study and Series Description(s) and Modality as obtained (if present)from the DICOMDIR file.
The automatic launching of applications is not expressly prohibited on media interchanged
within this profile; its use is discouraged, however.
84
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
To facilitate avoidance of malicious software, receiving actors (Portable Media Importer,
Image Display, Report Reader, Print composer and Display) are not required to launch
automatically running applications present on media.
4.47.4.1.3.2 Image Display
2080

The Image Display reads the DICOM image data from the media and provides the user withthe ability to view all studies (that it supports) contained on the media. GSPS objects and Key
Image Notes are read from the media and applied if the Consistent Presentation of Images andthe Key Image Notes IHE Integration Profiles are supported. The Image Display Actor may
optionally be grouped with other actors which view other evidence objects.

2085

4.47.4.1.3.3 Report Reader
The Report Reader reads the DICOM SR Reports from the media and may process them(based on the SR object classes it supports). At a minimum, it provides the user with the ability
to view all reports per the DICOM SR SCP requirements.
4.47.4.1.3.4 Portable Media Importer

2090

2095

2100

The Portable Media Importer reads DICOM data from the media. Together with the actor withwhich it is grouped (see vol. 1), it shall be able to perform key attribute reconciliation.
Reconciliation may not be required in all cases (e.g., within the same importing
institution/enterprise). Refer to Table 4.47.4-2 for key attributes to be reconciled. Import
Reconciliation Workflow provides a workflow to reconcile key attributes (See IRWF.b Trial
Implementation Supplement). Note that the Referenced Study Sequence and Requested
Attributes Sequence are removed for consistency with behavior of the unscheduled cases in SWF
and PIR.
The grouped actors provide the capability of storing the supported DICOM objects to an ImageManager/ Image Archive (for image objects like Images, Presentation States, Key Image Notes,
Evidence Documents), or to a Report Repository (for Diagnostic Reports).
Table 4.47.4-2: Media instances - Key attributes to be reconciled
Attribute from Media

Updating action

Patient Name

Replace with value from ADT (See note 1)

Patient ID

Replace with value from ADT (See note 1)

Patient’s Birth Date

Replace with value from ADT (See note 1)

Patient‘s Sex

Replace with value from ADT (See note 1)

Study Instance UID

Remains unchanged

Series Instance UID

Remains unchanged

SOP Instance UID

Remains unchanged

85
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute from Media

Updating action

Workflow-related Identifying Attributes(e.g., Order, Requested Procedure,
Scheduled and Performed IDs andUIDs).

Values from such identifying attributes of media information•
remain unchanged,•
are replaced with a value from the local
environment, or•
are removed (zero length value).
The exact method of reconciliation depends on the importing
institution’s procedures, and goes beyond the IHE scope.

Descriptive performed procedure
information(this is information that pertains to themanner in which the information was
created (e.g., acquisition context) or it
may be payload of the instance (e.g.,
image structure, document content))

Remains unchanged (see Note 2)

Note 1: The manner in which the Portable Media Importer receives the ADT value is beyond the scope of this transaction.

2105

Note 2: Handling of Coded information is beyond the scope of this transaction.

4.47.4.1.3.5 Print Composer
The Print Composer reads the DICOM image data from the media and provides a means to printit.
4.47.4.1.3.6 Display
2110

The Display Actor (defined in the IT Infrastructure TF) reads the web-viewable informationfrom the media and displays it. Note that the web-viewable content will only be present if the
Portable Media Creator involved supports the Web Content Option.

4.48 Appointment Notification
2115

This section corresponds to Transaction RAD-48 of the IHE Technical Framework. Transaction
RAD-48 is used by the Order Placer and Department System Scheduler/Order Filler actors.
4.48.1 Scope

2120

In the Appointment Notification Transaction, a Department System Scheduler/Order Filler sends
to an Order Placer Actor new appointment bookings and appointment rescheduling whichcontains the date(s) and time(s) of the Scheduled Procedures Steps. It may also notify an Order
Placer of the cancellation of appointment bookings.
4.48.2 Use CaseRoles

86
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
DSS/
Order Filler

Order Placer

Appointment
Notification

2125

Actor: Department System Scheduler/Order Filler
Role: Generates Appointment Notification messages and sends them to the corresponding Order
Placer Actor.
Actor: Order Placer
Role: Receives Appointment Notification messages and internally processes them.

2130

4.48.3 Referenced Standard
HL7 V2.4, chapter 10.
4.48.4 Interaction Diagram

2135

4.48.4.1 Appointment Notification -New Bookings
4.48.4.1.1 Trigger Events
SIU^S12 - Notification of New Appointment Booking
87Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2140

The DSS/Order Filler receives an order from an Order Placer Actor. The DSS/Order Filler
determines what procedure steps need to be scheduled. After scheduling the corresponding
appointment(s), the DSS/Order Filler may send the Order Placer an Appointment Notification New Appointment Booking message. Each appointment may satisfy zero or more Scheduled
Procedure Steps. Information in the AIS segment describes the date(s) and time(s) of theappointment(s) that has been booked.
4.48.4.1.2 Message Semantics

2145

The message semantics follow the SIU^S12 message as specified in HL7 V2.4 Chapter 10. Refer
to HL7 Standard for general message semantics. The cardinality of each segment is given withinsquare brackets (minimum and maximum number of repetitions authorized).
SIU^S12

Schedule Information
Unsolicited

Chapter in HL7 V2.4

MSH

Message Header

2

SCH

Schedule Activity Information

10

{ RGS

Resource Group Segment

10

{ AIS

Appointment Information - Service

10

Notes and Comments

2[{ NTE }]
}

2150

2155

There is one group (RGS, AIS) per appointment booking. It is repeated when several
appointment bookings have been made for the same Order. There must be at least one AIS
segment (and therefore one RGS segment) since it contains timing information of theappointment.
Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the SIU
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the HL7 ACK message.
4.48.4.1.2.1 MSH Segment
The MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2 “Message Control”.

2160

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of SIU; the second component shall have a value of S12. The third component is optional;
however, if present, it shall have a value of SIU_S12.
4.48.4.1.2.2 SCH Segment
The following table identifies required and optional fields of the SCH segment.
SEQ

LEN

DT

OPT

RP/
#

TBL
#

ITEM#

ELEMENT NAME

1

75

EI

O

00860

Placer Appointment ID

2

75

EI

R

00861

Filler Appointment ID

88
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
SEQ

LEN

DT

OPT

RP/
#

TBL
#

ITEM#

ELEMENT NAME

4

22

EI

C

00218

Placer Group Number

6

250

CE

R

00883

Event Reason

11

200

TQ

R

Y

00884

Appointment Timing Quantity

16

250

XCN

R

Y

00885

Filler Contact Person

20

250

XCN

O

Y

00878

Entered by Person

26

22

EI

R

Y

00216

Placer Order Number

27

22

EI

R

Y

00217

Filler Order Number
Adapted from the HL7 Standard, version 2.4

2165

Field SCH-1 Placer Appointment ID contains the placer application’s permanent identifier forthe appointment request. This field is not used.
Field SCH-2 Filler Appointment ID contains the filler application’s permanent identifier for theappointment request. This field is required to be sent.

2170

Field SCH-4 Placer Group Number shall be valued only if the Order Placer and the Order Filler
utilize concept of Order Groups. Shall not be present otherwise.
Field SCH-6 Event Reason is mandatory in HL7 V2.4 but not used by the Order Placer in this
IHE transaction. In order to keep the compatibility with HL7 V2.4, it shall be sent by the Order
Filler with the value ^APT.

2175

2180

Field SCH-11 Appointment Quantity Timing is mandatory in HL7 V2.4 but not used by the Order
Placer in this IHE transaction. Dates and Times are set in the AIS segment. In order to keep thecompatibility with HL7 V2.4, it shall be sent with a value set to 1.
Field SCH-16 Filler Contact Person identifies the person responsible for the scheduling of therequested appointment. Most often, this person will be the same person responsible formaintaining the schedule or for reviewing appointment requests. This is the person to call if theappointment needs to be rescheduled or cancelled.
Field SCH-20 Entered by Person identifies the person responsible for entering the request for thescheduling of an appointment. It is included to trace the persons responsible for the request.

2185

Field SCH-26 Placer Order Number is the order number assigned by the placer application forthe order associated with this scheduling filler response. In the context of IHE Radiology
Scheduled Workflow, this field is required to be sent.
Field SCH-27 Filler Order Number is the order number assigned by the filler application for theorder associated with this scheduling filler response. In the context of IHE Radiology Scheduled
Workflow, this field is required to be sent.
4.48.4.1.2.3 RGS Segment

2190

The RGS segment is used to identify relationships between resources (date and time, location,
medical staff) identified for a scheduled event. Related resources are defined in a group of
resources. Each group starts with a RGS segment, followed by an AIS segment (for the date andtime). The use of other segments (AIG, AIL, AIP) is beyond the scope of this integration profile.
89
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2195

There must be one group per set of Scheduled Procedure Steps that are scheduled to take place
during the same appointment.
RGS segment shall be constructed as defined in Section 10.6.3 “RGS – Resource Group
Segment” of HL7 V2.4 chapter 10 “Scheduling”. The following table identifies required andoptional fields of the RGS segment.
SEQ

LEN

DT

OPT

1

4

SI

R

2

3

ID

C

3

250

CE

O

RP/
#

TBL
#
0206

ITEM#

ELEMENT NAME

01203

Set ID – RGS

00763

Segment Action Code

01204

Resource Group ID

2200

Adapted from the HL7 Standard, version 2.4

4.48.4.1.2.4 AIS Segment
The AIS segment contains the date and time of a Scheduled Procedure. There is only one AIS
segment per group of resources.
2205

AIS segment shall be constructed as defined in Section 10.6.4 “AIS – Appointment Information– Service Segment” of HL7 V2.4 chapter 10 “Scheduling”. The following table identifies
required and optional fields of the AIS segment.
SEQ

LEN

DT

OPT

RP/
#

TBL
#

ITEM#

1

4

SI

R

2

3

ID

R

00763

Segment Action Code

3

250

CE

R

00238

Universal Service Identifier

4

26

TS

R

01202

Start Date/Time

5

20

NM

O

00891

Start Date/Time Offset

6

250

CE

O

00892

Start Date/Time Offset Units

7

20

NM

O

00893

Duration

8

250

CE

O

00894

Duration Units

9

10

IS

C

0279

00895

Allow Substitution Code

10

250

CE

C

0278

00889

Filler Status Code

11

250

CE

O

Y

0411

01474

Placer Supplemental Service
Information

12

250

CE

O

Y

0411

01475

Filler Supplemental Service
Information

00890
0206

ELEMENT NAME
Set ID – AIS

Adapted from the HL7 Standard, version 2.4

2210

Field AIS-2 Segment Action Code contains the action to be taken when adding, updating or
modifying information in this segment. All AIS segments in the same RGS group shall containthe same action code. This field is required and is valued with: A (Add/Insert).

90
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2215

2220

Field AIS-3 Universal Service Identifier contains an identifier for the Scheduled Procedure Steps
to be scheduled and the associated Requested Procedure Components. The 3 first components(“identifier”, “text”, “name of coding system”) contain the Requested Procedure Code (CodeValue, Meaning and Coding Scheme). The fifth component (“alternate text”) shall contain aconcatenated text description of the Scheduled Procedure Step(s) which can be understood at theOrder Placer level. The fourth (“identifier”) and sixth (“name of coding system”) components are
not used.
Field AIS-4 Start Date/Time contains the date and time of the appointment. Both date and time
are required. A time zone offset (from UTC) may be included. If the offset is not included thetime zone is understood to be the local time zone of the sender. For example, 09:00 AM US
Central Time on October 22, 2004 could be represented as: 200410220900-0600 or
200410220900 for a sender within the US Central time zone.
4.48.4.1.2.5 NTE Segment2225

Any information relative to the examination can be sent in NTE segments like Patient
instructions (empty stomach, full or empty bladder), pre-medication (preliminary injection,
biological examination), etc.
SEQ

LEN

DT

OPT

RP/
#

TBL
#

ITEM#

ELEMENT NAME

1

4

SI

R

00096

Set ID – NTE

2

8

ID

R

00097

Source of Comment

3

65536

FT

R

00098

Comment

4

250

CE

R

01318

Comment Type
Adapted from the HL7 Standard, version 2.4

2230

Field NTE-2 Source of Comment identifies the source of the comment. This field is required but
may be empty. Valid values are:Value

Description

L

Order Filler is the source of the commentO

Other system is the source of comment

Field NTE-3 Comment contains the text of the comment. To delete a previously sent comment,
the field shall contain empty quotation mark “”.
Field NTE-4 Comment Type contains a value to identify the type of comment. Valid values are:
2235
Value

Description

PI

Patient InstructionAI

Ancillary Instruction

GI

General Instruction

RE

Remark91
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.48.4.1.3 Expected Actions
The Order Placer shall accept the appointment bookings as scheduled and shall return an HL7
ACK message.
4.48.4.2 Appointment Notification - Reschedule Bookings
2240

4.48.4.2.1 Trigger Events
SIU^S13 - Appointment Notification - Reschedule Bookings

2245

In some cases, appointments may be rescheduled in the Radiology Department. This message issent by the DSS/Order Filler to notify the Order Placer that an existing appointment has been
rescheduled. The information in the AIS segment describes the new date(s) and time(s) to which
the previously booked appointment has been moved. Additionally, it describes the unchanged
information in the previously booked appointments.
4.48.4.2.2 Message Semantics
The message semantics follow the SIU^S13 message as specified in HL7 V2.4 Chapter 10. Refer
to HL7 Standard for general message semantics.

2250
SIU^S13

Schedule Information Unsolicited

Chapter in HL7 V2.4

MSH

Message Header

2

SCH

Schedule Activity Information

10

{ RGS

Resource Group Segment

10

{ AIS

Appointment Information - Service

10[{ NTE }]Notes and Comments

2}

There is one group (RGS, AIS) per appointment booking. It is repeated when several
appointment bookings have been made for the same Order. There must be at least one AIS
segment (and therefore one RGS segment) since it contains timing information of theappointment.
2255

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the SIU
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the HL7 ACK message.
4.48.4.2.2.1 MSH Segment
MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2 “Message Control”.

2260

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of SIU; the second component shall have a value of S13. The third component is optional;
however, if present, it shall have a value of SIU_S13.

92
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.48.4.2.2.2 SCH, RGS, NTE Segments
2265

SCH, RGS and NTE segments shall be constructed as defined in Section 4.48.4.1.2 “Message
Semantics” of the current proposition.
4.48.4.2.2.2 AIS Segment
The segment shall be constructed as defined in Section 4.48.4.1.2.4 except for Field AIS-2
Segment Action Code which is valued with: U (Update).
4.48.4.2.3 Expected Actions

2270

The Order Placer shall accept the appointment information for rescheduling and shall return an
HL7 ACK message.
4.48.4.3 Appointment Notification - Cancel Bookings
4.48.4.3.1 Trigger Events
SIU^S15 - Appointment Notification - Cancel Booking

2275

This event is triggered when existing appointment bookings have been cancelled by an Order
Filler Actor.
4.48.4.3.2 Message Semantics
The message semantics follow the SIU^S15 message as specified in HL7 V2.4 Chapter 10. Refer
to HL7 Standard for general message semantics.

2280
SIU^S15

Schedule Information
Unsolicited

Chapter in HL7 V2.4

MSH

Message Header

2

SCH

Schedule Activity Information

10

{ RGS

Resource Group Segment

10

{ AIS

Appointment Information –Service10[{ NTE }]Notes and Comments

2}

There is one group (RGS, AIS) per appointment booking. It is repeated when several
appointment bookings have been made for the same Order. There must be at least one AIS
segment (and therefore one RGS segment).
2285

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of the SIU
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” for definition anddiscussion of the HL7 ACK message.
4.48.4.3.2.1 MSH Segment
MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2 “Message Control”.
93
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2290

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of SIU; the second component shall have a value of S15. The third component is optional;
however, if present, it shall have a value of SIU_S15.
4.48.4.3.2.2 SCH, RGS, NTE Segments
SCH, RGS and NTE segments shall be constructed as defined in Section 4.48.4.1.2 “Message
Semantics”.

2295

4.48.4.3.2.3 AIS Segment
The segment shall be constructed as defined in Section 4.48.4.1.2.4 except for:•Field AIS-2 Segment Action Code is valued with: D (Delete).

4.48.4.3.3 Expected Actions
2300

The Order Placer shall accept the appointment information for cancellation and shall return an
HL7 ACK message. This message shall not be sent when the Order Filler or the Order Placer
cancel an order. It is assumed that appointments are automatically cancelled by the Order Filler
and that the Order Placer will take the same action.

4.49 Instance Availability Notification
2305

This section corresponds to Transaction RAD-49 of the IHE Radiology Technical Framework.
Transaction RAD-49 is used by the Image Manager/Image Archive, DSS/Order Filler, PostProcessing Manager and Report Manager Actors.
4.49.1 Scope2310

In the Instance Availability Notification Transaction, an Image Manager/Image Archive sends a
message to relevant actors to inform them of the availability status of newly stored DICOM
objects. Actors being notified are known to need these objects for fulfilling scheduled workflow
processes and can retrieve and use the objects referenced in this message. This allows forsupporting a variety of workflow conditions in imaging departments.
4.49.2 Use Case Roles
Image Manager/
Image Archive

DSS/
Order Filler

Instance
Availability
Notification

2315

Post-Processing
Manager

ReportManager

Actor: Image Manager/Image Archive
Role: Generate an Instance Availability Notification message and send it to the DSS/Order Filler
and optionally to other workflow managing actors (Post-Processing Manager, Report Manager).
94
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Actor: DSS/Order Filler
Role: Receive an Instance Availability Notification message and internally process it.
2320

Actor: Post-Processing Manager
Role: Receive an Instance Availability Notification message and internally process it.
Actor: Report Manager
Role: Receive an Instance Availability Notification message and internally process it.
4.49.3 Referenced Standard

2325

DICOM 2011 PS 3.4: Instance Availability Notification Service Class
4.49.4 Interaction Diagram
Image
Manager

PostProcessing
Manager

DSS/
Order Filler

ReportManager

Instance Availability
Notification (N-CREATE)
Instance Availability
Notification (N-CREATE)
Instance Availability
Notification (N-CREATE)

4.49.4.1 Instance Availability Notification
2330

This message uses the DICOM Instance Availability Notification Service from an ImageManager/Image Archive to inform other workflow managing actors about the availability of
DICOM instances they may be waiting for in order to be able to schedule or start procedure
steps.
4.49.4.1.1 Trigger Events

2335

2340

During image acquisition, an MPPS-capable Acquisition Modality creates a set of instances andstores them to an Image Manager/Image Archive. Alternatively as a part of importing Evidence
Objects, an MPPS capable Importer imports instances and stores them to an ImageManager/Image Archive. The Image Manager/Image Archive, after having received the last
instance of the instance set referenced in the MPPS, shall send an Instance Availability
Notification to the DSS/Order Filler that has also received the related MPPS. It may also decide
to send the Instance Availability Notification to other instance managing actors in the workflow
to inform them that all instances referenced in the related MPPS are available.
95
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2345

2350

One Instance Availability Notification shall be sent for each MPPS that contains references toinstances. MPPS without references to instances shall not trigger the sending of an Instance
Availability Notification. This applies to all the MPPS cases described in transaction RAD-6(RAD TF-2, 4.6: Simple Case, Unscheduled Case, Group Case, Append Case (Normal andGroup Case), Abandoned Case) and in transaction RAD-7 (RAD TF-2: 4.7: MPPSDISCONTINUED, except the case of incorrect worklist entry selected, RAD TF-2: 4.7.4.1.3.1).
It also applies to the Import PPS cases described in transaction RAD TF-3: 4.59.4.1.2.
(Unscheduled Import and Unscheduled Import Cases) and the Import PPS Discontinued (RADTF-3:4.60.4.1.2.2).
4.49.4.1.2 Message Semantics

2355

2360

2365

2370

2375

2380

The end of the image acquisition is indicated to the Department System Scheduler/Order Filler
and Image Manager/ Image Archive by an MPPS message from the Acquisition Modality
referencing the DICOM instances that were created and are to be stored in the ImageManager/Image Archive. The end of the DICOM object import is indicated to the Department
System Scheduler/Order Filler and Image Manager/ Image Archive by an Import MPPS message
from the Importer referencing the DICOM instances that were created and are to be stored in the
Image Manager/Image Archive.
Note that the MPPS and Instance Availability Notification inform about different events. Thus,
depending on the total volume of the images stored and characteristics of the local system
environment, the MPPS may arrive considerably earlier at the DSS/OF than the Instance
Availability Notification. The dependency of the IAN transaction on the MPPS Completed
transaction may result in delayed notification to the DSS/OF of available instances, if the MPPS
is not sent from the Acquisition Modality or Importer to the Image Manager/Image Archive in atimely fashion.
The Image Manager/Image Archive shall act as an Instance Notification SOP Class SCU andcreate an Instance Availability Notification SOP Class. It shall populate the Reference SOPInstance UID in the Referenced Performed Procedure Step Sequence. It shall include references
to all instances that are referenced in the corresponding MPPS. The other attributes of the SOPClass are used as specified in DICOM Suppl. 93.
The Image Manager/Image Archive shall be able to send the Instance Availability Notification tomultiple actors. The Image Manager/Image Archive shall send the Instance Availability
Notification to the DSS/Order Filler and may be configured to also send it to other actors
described in this transaction.
The DSS/Order Filler, Post-Processing Manager or the Report Manager shall understand that thereceipt of this notification message implies that a complete set of instances is available at theImage Manager/Image Archive that is identified by the Retrieve AE Title attribute.
Due to transient error conditions (e.g., corrupted storage media, Query/Retrieve SCP not
running) that may occur within the Image Manager/Image Archive, an actor may not be able toretrieve instances for which it has received availability notifications. If an actor is uncertain
about the availability status of instances referenced by the Instance Availability Notification, it
can use the Image Availability Query [RAD-11] to confirm the status as a supplementary

96
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
method. Additionally, the Image Manager/Image Archive is assumed to be able to handle
exceptions in instance storage or provision internally, based on local policy.
2385

4.49.4.1.3 Expected Actions

2390

The Department System Scheduler/Order Filler, Post-Processing Manager and Report Manager
shall act as an Instance Notification SOP Class SCP. As a result of receiving the notification, theDepartment System Scheduler/Order Filler (or other actors) shall take appropriate action
knowing that the referenced instances are available for further use in the workflow. Examples ofsuch actions can be:
•
•
•

2395

The Department System Scheduler/Order Filler updates the procedure status internally,
indicating that images for the procedure have been stored.
The Post-Processing Manager adds items to a corresponding worklist.
The Report Manager adds items to a corresponding worklist.

The Report Manager adds items to a list of relevant priors for use within Reporting.

4.50 Store InstancesThis section corresponds to Transaction RAD-50 of the IHE Technical Framework. The Export
Selector and Export Manager actors use transaction RAD-50.
4.50.1 Scope2400

In the Store Instances transaction, the Export Selector sends the selected composite instances tothe Export Manager.
4.50.2 Use Case Roles

ExportSelector

ExportManagerStore
Instances

Actor: Export Selector
2405

Role: Transmit instances to Export Manager.
Actor: Export Manager
Role: Accept instances from Export Selector and queue them for de-identification,
pseudonymization and export

97
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.50.3 Referenced Standard
2410

DICOM 2011 PS 3.4: Storage Service Class.
4.50.4 Interaction Diagram

ExportSelector

ExportManager

C-STORE (Store Instances)

4.50.4.1 Store Instances
4.50.4.1.1 Trigger Events
2415

The Export Selector can transfer instances to the Export Manager sequentially within one ormore DICOM associations.
4.50.4.1.2 Message Semantics
The Export Selector uses the DICOM C-STORE message to transfer the instances. The Export
Selector is the DICOM Storage SCU and the Export Manager is the DICOM Storage SCP.

2420

4.50.4.1.3 Expected Actions
The Export Manager will queue the received DICOM objects, until ready to process them.

2425

The DICOM Standard (2011) defines a number of composite storage SOP classes. The Export
Manager Actor shall support at least one composite storage SOP class, such as Images (see RAD
TF-2: Table 4.8-1 for suggestions), Evidence Documents, Structured Reports, Presentation States
and Radiotherapy objects.

2430

98
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4.51 Store Export Selection
This section corresponds to Transaction RAD-51 of the IHE Technical Framework. The Export
Selector and Export Manager actors use transaction RAD-51.
2435

4.51.1 Scope
In the Store Export Selection transaction, the Export Selector sends a Key Object Selection
document acting as a manifest of a collection of selected composite instances to the Export
Manager.
4.51.2 Use Case Roles
ExportSelector

ExportManagerStore
Export Selection

2440
Actor: Export Selector
Role: Transmit manifest to Export Manager.
Actor: Export Manager
2445

Role: Accept manifest from Export Selector and queue the manifest and the referenced
composite instances for processing (de-identification, pseudonymization and export)
4.51.3 Referenced Standard
DICOM 2011 PS 3.4: Storage Service Class.
DICOM 2011 PS 3.15: Basic Application Level Confidentiality Profile.
DICOM 2011 PS 3.3: Information Object Definitions

2450

DICOM 2011 PS 3.16: Content Mapping Resource

99
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.51.4 Interaction Diagram

ExportSelector

ExportManager

C-STORE (Store Export Selection)

4.51.4.1 Store Export Selection
4.51.4.1.1 Trigger Events
2455

The Export Selector can transfer a manifest to the Export Manager with a DICOM association.
The timing of the transfer is not coupled to the timing of any Store Instances transaction, in thatthey may occur over the same or different associations, and the manifest may be received before,
during or after the instances referred to by the manifest.
4.51.4.1.2 Message Semantics

2460

The Export Selector uses the DICOM C-STORE message to transfer the manifest. The Export
Selector is the DICOM Storage SCU and the Export Manager is the DICOM Storage SCP.
The manifest (Export Selection) is an instance of the Key Object Selection SOP Class
constructed according to the template defined in Table 4.51.4-1, which is a specialization of TID
2010 defined in DICOM 2011 PS 3.16, and is itself non-extensible.

2465
Table 4.51.4-1: Export Selection (“Manifest”) Template – Specializes DICOM TID 2010
NL
1

Rel with
parentValue Type

Concept Name

VM

Req
Type

CONTAINER

EV (TCE001,
IHERADTF, “For
Teaching File
Export”) or (TCE002,
IHERADTF, “ForClinical Trial Export”)
or (TCE007,IHERADTF, “For
Research Collection
Export”) or (TCE008,
IHERADTF, “ForPublication Export”)

1

M

Cond

Value Set
Constraint
Root node100
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2470

NL

Rel with
parentValue Type

Concept Name

VM

Req
Type

2

>

3

Cond

HAS
CONCEPT
MOD

CODE

EV (113011, DCM,
“Document Title
Modifier”)

1

U

>

HAS
CONCEPTMOD

INCLUDEDTID(1204)
Language of Content
Item and Descendants

1

U

4

>

HAS OBS
CONTEXTINCLUDEDTID (1002)
Observer Context

1-n

U

5

>

CONTAINS

TEXT

EV(113012, DCM,
”Key Object
Description”)

1

U

6

>

CONTAINS

IMAGE

Purpose of Reference
shall not be present

1-n

MC

At least one ofRows 6 or 7 shallbe present.

7>

CONTAINSCOMPOSITE

Purpose of Reference
shall not be present

1-n

MC

At least one ofRows 6 or7 shallbe present.

Value Set
Constraint
DCID Table
4.51.4-2 Delay
Reasons

Disposition

The Document Title shall be either (TCE001, IHERADTF, “For Teaching File Export”) or(TCE002, IHERADTF, “For Clinical Trial Export”) or (TCE007, IHERADTF, “For ResearchCollection Export”) or (TCE008, IHERADTF, “For Publication Export”).
The Key Object Description TEXT content item, if present, shall describe the disposition of theselection. The use of this value requires coordination between the Export Selector and the Export
Manager that is beyond the scope of this transaction to define.
•

2475
•
•
2480

In the case of teaching files, this value could contain the identifier of a user to whom thecase is to be routed for authoring, or it could be more generic and reference a role, adepartment, or a category of teaching file.
In the case of clinical trials, this value could contain the identifier of clinical trial
protocol, and may affect behavior of the Remap Identifiers Option.
In the case of research collections, this value could contain the identifier of a researchcollection.

A single Document Title Modifier content item may be present and specify a value that may be
one of those listed in Table 4.51.4-2.
Table 4.51.4-2: Delay Reason Values
CodingSchemeDesignator

Code
Value

Code Meaning

IHERADTF

TCE011

Delay export until final report is available

IHERADTF

TCE012

Delay export until clinical information is available

IHERADTF

TCE013

Delay export until confirmation of diagnosis is available

IHERADTF

TCE014

Delay export until histopathology is available

101
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
CodingSchemeDesignator

Code
Value

Code Meaning

IHERADTF

TCE015

Delay export until other laboratory results is available

IHERADTF

TCE016

Delay export until patient is discharged

IHERADTF

TCE017

Delay export until patient dies

IHERADTF

TCE018Delay export until expert review is available

2485
No additional information describing the collection of referenced instances is contained in the
manifest. Any such additional content, such as pre-formatted information to be conveyed to theteaching file authoring system, may be conveyed in separate SR documents referenced by the
manifest; see Section 4.52 Store Additional Teaching File Information.
2490

2495

The manifest shall not contain references to Additional Teaching File Information alone; hence
any SR documents containing Additional Teaching File Information shall be referenced by theoriginal export selection, and may not be added or sent in a separate manifest.
Note that if the manifest does not include the DICOM TID 1003 Person Observer Identifying
Attributes within the DICOM TID 1002 Observer Context, then it will not be possible to identify
which individual assembled the collection. Accordingly it may not be possible for the Export
Manager and subsequent Actors to route the collection to that individual, other than as specified
by the disposition encoded in the Key Object Description TEXT content item.
Only instances of a single patient may be referenced by the manifest, but there may be instancesof multiple studies.

2500

2505

A common use-case involving multiple studies occurs when the selection references current andprior images. When the selection references more than one study, DICOM requires that multiple
instances of the Key Object Selection Document be created, one for each Study Instance UID
and cross-referenced by the Identical Documents Sequence (see DICOM 2011 PS 3.3
C.17.6.2.1). IHE therefore requires that there be multiple copies of the same manifest sent in thistransaction, one for each study.
4.51.4.1.3 Expected Actions
The Export Manager will queue the manifest until it has received all DICOM instancesreferenced therein, and is ready to process them.

2510

2515

The instances shall not be processed until the manifest has been received, since it dictates theform of processing required. The Delay for Reason Option may require the processing to befurther delayed; see Section 4.51.4.1.5.
Note that in the case of multiple manifests to handle the multiple study case, since the lists ofreferenced instances therein are identical, the Export Manager need not wait until all copies ofthe manifest have been received before commencing processing. In the multiple study case,receipt of only a single manifest shall not be considered as an error condition and normal
processing shall occur. The Export Manager shall examine the Identical Documents Sequence in

102
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
each manifest to detect the multiple study case and to prevent the same export from being
repeated.
2520

No export shall be performed if instances are received but no referencing manifest is received
within a configurable time.
If all the instances in the manifest are not received within a configurable time, the Export
Manager shall proceed with an incomplete set and create an updated manifest. If the missing
instances are received later, either they shall not be exported or a separate export and manifest
shall be exported containing only those instances.

2525

2530

Instances referenced by the manifest may be of a SOP Class not supported by the Export
Manager as a Storage SCP and hence will never be received. The SOP Class UIDs are encodedin the manifest. The Export Manager shall proceed with an incomplete set and create an updated
manifest.
If the Export Manager is grouped with an Image Manager/Archive and already has all referenced
DICOM instances, it may begin processing upon receipt of the manifest.
The Export Manager shall de-identify and pseudonymize all the DICOM instances referenced by
the manifest, as defined in Section 4.51.4.1.4, before forwarding them all by initiating RAD-53
Export Instances transactions.
4.51.4.1.4 De-identification and Pseudonymization

2535

4.51.4.1.4.1 Baseline De-identification and Pseudonymization Requirements
There is considerable variation in what attributes need to be removed to achieve sufficient deidentification and pseudonymization for any particular purpose. See the discussion in Appendix
I.1.

2540

Accordingly, this transaction does not require the removal of all text attribute values, nor theremoval of all private attribute values.

2545

Rather, it requires that the implementation provide a mechanism to allow the user to configure
those attributes that will be removed or replaced. The transaction requires that at minimum, theimplementation support the ability to configure removal and replacement of all those attributes
listed in the Basic Application Level Confidentiality Profile in DICOM PS 3.15. Further, it shallbe configurable to perform no de-identification at all.
When de-identification has been performed, the Export Manager shall add to the DICOM datasetof each instance the Patient Identity Removed (0012,0062) attribute with a value of YES, andadd a value for De-identification Method (0012,0063) or De-identification Method Code
Sequence (0012,0064).

2550

2555

In some scenarios, it will be desirable to configure the Export Manager to perform no deidentification at all, such as when all de-identification will be performed in the Teaching File
Receiver, or not at all. In such cases, if the Patient Identity Removed (0012,0062) attribute ispresent in the dataset it shall not be changed; if it is absent it shall not be added.
In some de-identification scenarios, the UIDs need to be replaced. This transaction does not
require that UIDs be replaced, but does require that if UIDs are replaced, internal consistency
103
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
within the exported set of instances be maintained; the implementation shall be configurable tosupport both. This entails adherence to the following rules:
•
2560

•
•

The same replacement UID is used for all composite instances of the same entity within
the set, e.g., the same Study Instance UID for all instances within the same original study.
References by UID to other instances or entities within the set are updated, e.g.,references to the SOP Instance UIDs of predecessor documents, reference images andsource images.
References by UID to other instances or entities not included within the set are removed
or replaced with consistent, well-formed, dummy references.

2565

If the same instances are exported multiple times on different occasions, the identifying attributesand UIDs therein may or may not be replaced with the same values on each occasion. That is,
this transaction does not require deterministic behavior for replacement of identifying attributesand UIDs, except as specified for the Remap Identifiers Option. See also the discussion in
Appendix I.2.

2570

The actions of the de-identification and pseudonymization must not create invalid IODs.
Specifically:
•
•
•

2575

Mandatory and conditional attributes may not be removed, but rather must be replaced.
Type 1 attributes must be given a value.
Type 2 attributes may be encoded zero length, but it is often advisable to encode a value,
especially for attributes likely to be used in browsers such as Patient Name, Patient ID,
Study ID and Accession Number.

4.51.4.1.4.2 Manifest Coercion

2580

The manifests received from the Export Selector will be Key Object Selection Documents thatreferences instances of a single patient, but possibly from multiple studies. If multiple studies arereferenced there will be multiple copies of the Key Object Selection Document.
The manifest(s) will contain the original identifying information, and hence need to undergo deidentification and pseudonymization prior to export, in accordance with the same requirements
as the instances to which it refers.

2585

The Export Manager shall update the UIDs in the references in the manifest(s) to the studies,
series and instances, if the UIDs in the referenced instances have been changed.
If the Export Manager has not received all the instances in the set referenced by the manifest(s),and will not transmit them to the Receiver, then they shall be removed from the forwarded
manifest(s).
Any Document Title Modifier specifying a Delay for Reason shall be removed.

2590

A manifest shall always be included in the export from the Export Manager to the Receiver.
In the multiple study case, the correct number of manifests shall be exported to the Receiver,regardless of what was received from the Export Selector.

104
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.51.4.1.4.3 Remap Identifiers Option
2595

The purpose of this option and its requirements are described in RAD TF-1:17.2.2. The DICOM
Clinical Trials attributes are further discussed in Appendix I.3.
Table 4.51.4-3 below lists the attributes that shall be used as keys to select which values to use
for remapping of identifiers, and which attributes shall be replaced.

2600

If the same instances are exported multiple times, the attributes in Table 4.51.4-3 shall be
remapped to the same values. Other attributes, including UIDs, may or may not be replaced withthe same values on each occasion. That is, this option only requires deterministic behavior forthe attributes in Table 4.51.4-3.
Table 4.51.4-3 uses the following conventions:
•

2605

•
•
•

M – Match means that the attribute is used as the key value to match at the specified
level, and hence to select new values for mapping other attributes at that level
C – Change means that any value shall be replaced by a non-zero value, or the attributeshall be inserted with a value if not present
D – Deletion means either removal of the attribute if it is Type 3, or replacement withzero length if it is Type 2, or replacement with a dummy value if it is Type 1
L – Leave means do not change the existing value of the attribute

2610
Table 4.51.4-3: Remap Identifiers Option Attributes
Attributes Name

Tag

Match

Delete, Change or
Leave

Notes

Clinical Trial Protocol Level
Clinical Trial Protocol ID(0012,0020)

C

Note 1

C

Note 2Clinical Trial Site Level
Institution Name

(0012,0020)

Clinical Trial Site ID(0012,0030)

M

C

Clinical Trial Subject Level
Patient ID(0010,0020)

M

C

Note 2

Patient Name

(0010,0010)

C

Note 2Other Patient IDs(0010,1000)

D

Patient’s Birth Date

(0010,0030)

L or C or D

Note 4

Patient’s Age(0010,1010)

L or C or D

Note 4

Patient’s Sex(0010,0040)

L or C or D

Note 4

Clinical Trial Subject ID(0012,0040)

C

Clinical Trial Study Level
Study Date

(0008,0020)

M

L or C

Notes 3, 4

Study Time

(0008,0030)

L or C

Notes 3, 4

Study Description(0008,1030)

L or C

Note 4

Clinical Trial Timepoint ID(0012,0050)

C

105
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attributes Name

Accession Number

Tag

Match

Delete, Change or
Leave(0008,0050)

Notes

D

Clinical Trial Series Level
Series Description(0008,103E)

Series Number(0020,0011)

M

L or C

Note 4

L or C

Note 4Note 1: No matching of the Clinical Trial Protocol level based on attributes in the instances is specified, since the clinical
trial protocol that is the target of the export will be conveyed in the disposition specified in the manifest.

2615

2620

Note 2: The delete option is not provided for these attributes; replacement is required. This is because these attributes areimportant for the correct operation of conventional databases and browsers, hence null or dummy values are notacceptable. Typically, for example, the same value inserted in Clinical Trial Subject ID will also be duplicated in
Patient ID and Patient Name. Likewise, the same value inserted in Clinical Trial Site ID will also be duplicated in
Institution Name.
Note 3: Whether or not the Study Date and Time need to be left or replaced depends on the requirements of the clinical
trial; the implementation shall support both.
Note 4: The presence of more than one option means that the application shall be configurable to allow for any of theoptions.

4.51.4.1.4.4 De-identify Pixel Data Option
2625

2630

2635

2640

The removal of identifying information that is burned into the pixel data of single or multi-frame
images is a non-trivial task. With image sources from multiple modalities and multiple vendors it
is difficult to predict a priori within which pixels such identification is contained. Hence this task
is difficult to automate and in the majority of instances requires intervention by a human operator
acting through a user interface with what is essentially a pixel data editor.
An Export Manager claiming this option shall provide a method of de-identification of the pixel
data. The manner in which this is performed is not specified. De-identification is generally
considered successful if patient-identifying information can no longer be read or recovered fromthe pixel data.
Whether or not de-identification of the pixel data of a particular image is required may bedifficult to determine, and may require human intervention. This option requires that the Export
Manager provide a mechanism for categorizing those images that are at risk, and requiringconfirmation by a human operator that the identification has been removed.
If an instance already contains the Burned In Annotation (0028,0301) attribute with a value ofNO, then pixel data de-identification is not required. When de-identification of pixel data has
been performed, the Export Manager shall add to the DICOM dataset of each instance the
Burned In Annotation (0028,0301) attribute with a value of NO.
This option neither requires nor prohibits changing the SOP Instance UIDs; the implementation
shall be configurable to support both.
4.51.4.1.4.5 De-identification of Non-Image Instances

2645

There are no specific requirements or named options for the removal of identification
information that may be contained within the payload of non-image instances. For example, an
106Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2650

SR object that contains a plain text report or an evidence document, or an encapsulated PDF
document, could contain identifying information within the payload that is difficult to detect andremove in an automated manner, and operator intervention may be required. It is beyond thescope of this profile to define the mechanisms for the removal of such information. It suffices tosay that the subset of DICOM composite storage SOP instances supported by the Export
Manager as an SCP should take this factor into consideration.
4.51.4.1.5 Delay for Reason

2655

When the Exporter supports the Delay for Reason Option, and the Document Title Modifier of amanifest specifies a coded reason for delay, and the Exporter supports that coded reason, thenprocessing shall not begin until the reason for the delay has been satisfied, or the delay condition
is not satisfied within a configurable time.

4.52 Store Additional Teaching File Information
This section corresponds to Transaction RAD-52 of the IHE Technical Framework. The Export
Selector and Export Manager actors use transaction RAD-52.
2660

4.52.1 Scope
In the Store Additional Teaching File Information transaction, the Export Selector sends an SR
document containing additional teaching file information to the Export Manager.
4.52.2 Use Case Roles

ExportSelector

ExportManagerStore
Additional
Teaching File
Information

2665

Actor: Export Selector
Role: Transmit information to Export Manager.
Actor: Export Manager
Role: Accept information from Export Selector and queue it for de-identification,
pseudonymization and export

2670

4.52.3 Referenced Standard
DICOM 2011 PS 3.4: Storage Service Class.
107
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.52.4 Interaction Diagram

ExportSelector

ExportManager

C-STORE (Store Additional Teaching File Information)

4.52.4.1 Store Additional Teaching File Information
2675

4.52.4.1.1 Trigger EventsThe Export Selector can transfer information to the Export Manager sequentially within one ormore DICOM associations.

2680

The timing of the transfer is not coupled to the timing of any Store Instances or Store Export
Selection transactions, in that they may occur over the same or different associations, and the
manifest may be received before, during or after the instances referred to by the manifest.
4.52.4.1.2 Message Semantics
The Export Selector uses the DICOM C-STORE message to transfer the additional information
encoded as one or more Enhanced SR SOP Class instances. The Export Selector is the DICOM
Storage SCU and the Export Manager is the DICOM Storage SCP.

2685

This information is separate from the manifest summarizing the collection of referenced
instances is contained.
More than one instance may be present.
To be included in the material to be exported, the instances of this transaction must be referenced
by the manifest(s) in the Store Export Selection transaction.

2690

The Document Title shall be (TCE006, IHERADTF, “Additional Teaching File Information”).
An example template for an SR describing a typical Radiology Teaching File collection is
described in Appendix H.
4.52.4.1.3 Expected Actions
The Export Manager will queue the received DICOM objects, until ready to process them.

108
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
2695

4.53 Export InstancesThis section corresponds to Transaction RAD-53 of the IHE Technical Framework. The Export
Manager and Receiver actors use transaction RAD-53.
4.53.1 Scope2700

In the Export Instances transaction, the Export Manager sends the de-identified andpseudonymized composite instances and a Key Object Selection document acting as a manifestof the collection to a Receiver. The purpose of the manifest is to retain the information that thereferenced instances constitute the collection that it is being exported.
4.53.2 Use Case Roles

ExportManager

Receiver

ExportInstances

2705

Actor: Export
Role: Transmit de-identified and pseudonymized instances and manifest to Receiver.
Actor: Receiver
Role: Accept instances from the Export Manager
4.53.3 Referenced Standard

2710

DICOM 2011 PS 3.4: Storage Service Class.

109
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.53.4 Interaction Diagram

ExportManager

ReceiverC-STORE (Export Instances)

4.53.4.1 Export Instances
4.53.4.1.1 Trigger Events
2715

The Export Manager initiates this transaction when it has de-identified and pseudonymized all
the instances referenced within an Export Selection, as well as any instances of Additional
Teaching File Information and the manifest.
4.53.4.1.2 Message Semantics

2720

The Export Manager uses the DICOM C-STORE message to transfer the instances and the
manifest. The Export Manager is the DICOM Storage SCU and the Receiver is the DICOM
Storage SCP.
The Export Manager can transfer the instances and the manifest to the Receiver within one ormore DICOM associations.

2725

The timing of the transfer of the manifest and the instances to which it refers is not defined, inthat they may occur over the same or different associations, and the manifest may be received
before, during or after the instances referred to by the manifest.
The manifest is an instance of the Key Object Selection SOP Class.
4.53.4.1.3 Expected Actions
A receiver shall support the Key Object Selection SOP Class as an SCP.

2730

The Receiver may support any composite storage SOP class, including Images, Evidence
Documents, Structured Reports, Presentation States, and Radiotherapy objects.
If the Receiver does not support all the SOP Classes of the instances to be exported, then thetransfer will partially or completely fail.

110
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2735

A Receiver claiming the Additional Teaching File Information Option shall be able to receive
Enhanced SR SOP Class instances. No specific semantics are defined for receipt of theAdditional Teaching File Information.
Unless grouped with other Actors, the further behavior of the Receiver on receiving the instancesand manifests is beyond the scope of the transaction to define. Typically:
•

2740
•

2745

In the case of teaching files, such a device might store the received instances whilst
awaiting a manifest prior to queuing the instances for authoring by the user.
In the case of clinical trials, such a device might store the received instances whilst
awaiting a manifest prior to queuing for entry into the clinical trial workflow

A Receiver grouped with an Image Manager/Archive shall make the received instances available
for use in the normal manner as defined by other Profiles. If the Image Manager/Archive claims
the Key Image Note Profile, then the manifests shall be made available as Key Image Notes.
A Receiver grouped with a Portable Media Creator shall store the received instances whilst
awaiting a manifest prior to burning the referenced instances and manifests to media, as definedby the requirements in the Portable Data for Imaging Profile.

4.54 Provide and Register Imaging Document Set - DEPRECATED
2750

This transaction has been deprecated and is superseded by the Provide and Register Imaging
Document Set – MTOM/XOP (RAD TF-3: 4.68) as part of the Cross-Enterprise Document
Sharing for Imaging (XDS-I.b) Profile.

4.55 WADO Retrieve
2755This section corresponds to Transaction RAD-55 of the IHE Technical Framework. TransactionRAD-55 is used by the Imaging Document Consumer and the Image Manager/ Image Archive
actors.
4.55.1 Scope
The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM
SOP Instances with a web-based service through HTTP/HTTPS protocol.

2760

4.55.2 Use Case Roles

ImagingDocument
Consumer

Imaging Document
SourceWADO Retrieve

111
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Actor: Imaging Document Consumer
Role: Issues an HTTP Get Request to access a DICOM instance.
2765

Actor: Imaging Document Source
Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP
response with the appropriate content.
4.55.3 Referenced Standard
DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)

2770

4.55.4 Interaction Diagram
Imaging Document
Consumer

ImagingDocument Source

Object(s) request(GET HTTP Request)
Object(s) send
(HTTP Response to the GET Request)

4.55.4.1 WADO Retrieve

2775

The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instancefrom the Imaging Document Source. The Imaging Document Source receives the request,
generates the response with the appropriate content and sends an HTTP Response to the Imaging
Document Consumer.
4.55.4.1.1 Trigger EventsThe Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within
a DICOM Manifest.

2780

4.55.4.1.2 Message Semantics
The message semantics are defined by the DICOM Web Access to DICOM Persistent Objects(WADO), PS 3.18.

2785

The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a
HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document
Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM
instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance
112
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2790

UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the hostinformation (e.g., web server location, and script language) of the web server to perform thistransaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOPInstance to the web server host information based on its local configuration (see Appendix G).
In addition, the Imaging Document Consumer shall support the following fields in the HTTP
request:Table 4.55-1: WADO HTTP Request Fields

2795

HTTP Field

REQ

AcceptR

This field is used to specify MIME types
which are acceptable for the response

Description

At least one of the following values:
application/dicom
image/jpeg
application/text
application/html*/*
Other values may be included as well

Values

AcceptLanguage

O

This field specifies the language of theobject to be retrieved.

Any valid value according to RFC2616

The Imaging Document Source shall list all media types it supports in the Accept field of the
HTTP request, and shall use WADO HTTP parameter contentType to request the desired media
type of the object to be retrieved in the HTTP response (see Table 4.55-2).
The Imaging Document Source and the Imaging Document Consumer are required to support a
number of parameters in the WADO HTTP Request-URI, as described in the following table.

2800
Table 4.55-2: WADO HTTP Request Parameters
Parameter Name

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
Consumer

NoterequestType

Type of the HTTP request performed. It
must be “WADO”

R

R

studyUID

Unique identifier of the study

RR

seriesUID

Unique identifier of the seriesRR

objectUID

Unique identifier of the object

R

R

contentType

MIME type of the responseR+R+

charsetCharset of the responseOO

anonymize

Anonymize object

OO

annotation

Annotation of the object

O

O

IHE-3

rows

Number of pixel rows

O

O

IHE-3

columns

Number of pixel columns

O

O

IHE-3

regionRegion of image

O

O

IHE-3

IHE-1
IHE-2

113
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Parameter Name

2805

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
ConsumerNotewindowCenter

Window center of the image

O

O

IHE-3

windowWidth

Window width of the image

O

O

IHE-3

frameNumber

Frame number of the single frame in a
multi-frame image

O

O

IHE-3

imageQuality

Image quality factor

O

O

IHE-3

presentationUID

Unique identifier of the presentation
object

O

O

IHE-3

presentationSeriesUID

Unique identifier of the series containing
the presentation object

O

O

IHE-3

transferSyntax

Transfer syntax UID used with DICOM
image object returned in the response

O

O

IHE-3

IHE-1: The Imaging Document Consumer must use the value “application/dicom” toretrieve a DICOM SOP Instance in the DICOM Part 10 File Format. This allows the
Imaging Document Consumer to receive a SOP Instance in the native DICOM
format for full data manipulation.
The Imaging Document Consumer can also use the value “application/jpeg” toretrieve an image encoded in JPEG baseline format if it is a single frame DICOM
image object or a single frame image encoded in a multi-frame DICOM image
object.

2810

The Imaging Document Consumer can also use the values “application/text” or“application/html” to retrieve a DICOM SR object represented in the text or html
format.

2815

The Imaging Document Consumer can also use other values for this parameter as
specified in DICOM 2011 PS 3.18, if they are supported by the Imaging Document
Source.

2820

This parameter is optional in DICOM PS 3.18. Because the default format of the
DICOM persistent object returned in the HTTP Get response in the absence of avalue in this parameter varies depending on the SOP Class of the retrieved object,
this transaction requires that the parameter be supported, to improve
interoperability.
IHE-2: This parameter must be compatible to the value(s) that the Imaging Document
Consumer placed in the Accept field of the HTTP Request-URI.
IHE-3: The parameter applies only to a DICOM SOP Instance if it is an image object.
4.55.4.1.2.1 Example of WADO Request-URI

2825

The following is an example of HTTP Request-URI for retrieving a persistent DICOM object
using WADO:

114
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2830

http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.
40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&
objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&contentType=application%2Fdicom
This example uses response MIME type application/dicom to request the DICOM SOP Instance
returned in the native DICOM Part 10 file format.
4.55.4.1.3 Expected Actions

2835

2840

Upon reception of the WADO HTTP Request, the Imaging Document Source shall parse therequest and if there are no errors, shall construct an HTTP Get Response with the requested
DICOM instance content and return the response as specified by the DICOM WADO standard,with HTTP response code 200 (OK).
The Imaging Document Source shall return HTTP response code 406 (Not Acceptable), if itcannot serve the requested response MIME type(s) in parameter contentType and/or Accept
Field.
The Imaging Document Source shall return HTTP response code 404 (Not Found) if it cannot
locate the requested DICOM SOP Instance or cannot recognize the UID values specified in thereceived HTTP Request-URI.

2845

2850

The Imaging Document Source shall return HTTP response code 400 (Bad Request) if any
required HTTP field or required WADO HTTP parameters are missing in the received HTTP
Request-URI, or any other syntactic error is detected in the HTTP Request-URI (e.g., media type
in contentType parameter conflicts with media types in Accept field).
The Imaging Document Source in the Imaging Object Change Management Integration Profile
shall not return the rejected DICOM SOP Instance(s) referenced by the specific KOS instanceswith the Document Title valued (113001, DCM, “Rejected for Quality Reasons”), (113037,
DCM, “Rejected for Patient Safety Reasons”), (113038, DCM, “Incorrect Modality Worklist
Entry) or (113039, DCM, “Data Retention Policy Expired”). The Imaging Document Source
shall return HTTP response code 404 (Not Found) if the Imaging Document Consumer requested
retrieval of such rejected DICOM SOP Instance(s) referenced in that KOS.

2855
4.55.4.1.4 Audit Trail Trigger Events
IHE specifies a number of events that shall be reportable by means of the IHE Audit Trail (ITI
TF-2a: 3.20). IHE Radiology Audit Trial Option further defines a subset of these events, which
are particularly applicable to the radiology transactions.
2860

Table 4.55-3 lists all the radiology audit trial trigger events applied to transaction RAD-55. The
last column specifies whether the sender or receiver side of the transaction is required to audit
the event.
Table 4.55-3: Audit Record Trigger Events
IHE Radiology Transaction

ATNA Trigger Event(s)Audit Recording Requirements

115
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________IHE Radiology Transaction
WADO Retrieve [55]

ATNA Trigger Event(s)Audit Recording Requirements

Instance-Stored

Imaging Document Source shall audit

Study Used

Imaging Document Consumer shall audit

2865

4.59 Import Procedure Step In ProgressThis section corresponds to Transaction RAD-59 of the IHE Technical Framework. TransactionRAD-59 is used by the Department System Scheduler/Order Filler, Image Manager, Performed
Procedure Step Manager, Report Manager, and Importer actors.
2870

4.59.1 Scope
This transaction includes a message from the Importer to the Performed Procedure Step
Manager, which in turn issues the message to the Department System Scheduler/Order Filler, theImage Manager and the Report Manager that the Performed Procedure Step is in progress.

2875

The receiving Performed Procedure Step Manager is grouped with the Image Manager or the
Department System Scheduler/Order Filler, and shall support forwarding messages to two otherdestinations besides the Actor it is grouped with. It shall start issuing messages to the configured
destinations immediately after it accepts the corresponding messages from the Importer.
To allow for proper integration, the following considerations must be taken into account:

2880

The Performed Procedure Step Manager must maintain PPS objects and then store them until
corresponding N-CREATE and N-SET messages are transmitted to the Actor it is grouped with,and the two other Actors. If transmission to a destination fails, the Performed Procedure Step
Manager shall try to repeat transmission periodically until it succeeds. The Performed Procedure
Step Manager must not use failure of one or more of these transmissions as a reason for rejecting
the initial transmission from the Importer;

2885

Because both the Image Manager and the Department System Scheduler/Order Filler incorporate
the Performed Procedure Step Manager function, an infinite redistribution of PPS messages ispossible. The Image Manager and the Department System Scheduler/Order Filler systems thatprovide the Performed Procedure Step Manager function shall be configurable to disable thisfunction;

2890

Transfer of the information to the system that the receiving Performed Procedure Step Manager
is integrated with is outside the scope of the IHE Technical Framework (i.e., internal to an
implementation).
4.59.2 Use Case Roles

116
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Performed
Procedure Step
Manager

Image Manager
Report Manager

ImporterModality Procedure
Step In Progress

Department System
Scheduler/Order Filler

2895
Actor: Department System Scheduler/Order Filler.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Image Manager.
2900

Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Report Manager.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Importer.

2905

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure
Step has started.
Actor: Performed Procedure Step Manager.
Role: Accepts Performed Procedure Step information from an Importer and transmits it to the
Department System Scheduler/Order Filler, Image Manager and Report Manager.
4.59.3 Referenced Standards

2910

DICOM 2011 PS 3.4: Modality Performed Procedure Step SOP Class.
4.59.4 Interaction Diagram
Importer

Performed Procedure Step
Manager/
Image Manager

MPPS N-CREATE

Department System
Scheduler/Order
FillerReport Manager

MPPS N-CREATEMPPS N-CREATE

117
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Importer

Performed Procedure Step Manager/
Department System Scheduler/Order
FillerMPPS N-CREATE

Image Manager

Report Manager

MPPS N-CREATEMPPS N-CREATE

2915
4.59.4.1 Procedure Step In Progress Message
4.59.4.1.1

Trigger Event

The User begins the import procedure step from the Importer.
4.59.4.1.2
2920

2925

Message Semantics

The Importer importing Evidence Objects into the Enterprise uses a Modality Performed
Procedure Step SOP Class (N-CREATE Service) to inform the Performed Procedure Step
Manager that a specific Procedure Step has been started and is in progress. In turn, the Performed
Procedure Step Manager uses the N-CREATE service to forward the information to the
Department System Scheduler/Order Filler, Image Manager and Report Manager. The Performed
Procedure Step Manager shall use the same Performed Procedure Step SOP Instance UIDs
during this interchange. The following aspects shall be taken into account during implementationof this step:
4.59.4.1.2.1 Patient/Procedure/Scheduled Procedure Step Information

2930

The Importer shall ensure that the critical Patient information is valid and correct (See RAD TF2: Appendix A.5). Additionally, if a Procedure Step has been scheduled for the importation it isalso necessary to validate the Procedure information. Due to the fact that the Evidence Objects or
Hardcopy to be imported are not native to the Enterprise, the validation process (by the User) of
ensuring that the correct Patient is associated with the imported data is critical.
4.59.4.1.2.2 Required Attributes

2935

RAD TF–2: Appendix A.5 lists a number of attributes that shall be coerced by the Importer toensure consistency between the information included in the imported SOP instances, thePerformed Procedure Step attributes, the Patient Demographic Information and the Scheduled
Procedure Step information, if applicable.

118
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2940

4.59.4.1.2.3 Relationship between Scheduled and Performed Procedure Stepsand the Imported DICOM Composite Object
When importing a DICOM Composite Object (e.g., from CD), the DICOM header informationmust either be preserved to ensure the integrity of the Study or coerced to fit within the local
Enterprise. RAD TF-2: Appendix A.5 defines specific coercion requirement. For example, theStudy Instance UID is one of the elements which must be maintained.

2945

The original scheduling and performing of the studies to be imported is outside of the venue of
the Enterprise. For this reason, the association of Evidence Objects from a study to be imported
may have relationships which are not easily described.

2950

When digitizing Hardcopy and creating a new DICOM Composite Object, some of the original
patient and study details may be derived from manual entry, OCR, configuration, etc. or may not
be available. RAD TF-2: Appendix A.5 defines specific requirements.

2955

The relationship between Scheduled and Performed Procedure Step information for an
importation is shown in the following 2 cases. Refer to RAD TF-2: Appendix A.5 for details offilling other attributes (Procedure ID, Accession Number, etc.) in each of these cases. In eachcase a MPPS N-Create Message is sent to notify the system that the performed procedure importis in progress
4.59.4.1.2.3.1

Scheduled Import

1

SPS

2960

2965

resultsin

1

PPS

In the SCHEDULED IMPORT Option, the Scheduled Procedure Step information is provided bya Modality Worklist. There exists a 1-to-1 relationship between SPS and PPS. Information about
the Scheduled Procedure Step and Requested Procedure shall be copied from the Scheduled
Procedure Step object to the Performed Procedure Step Relationship Module (see RAD TF-2:
Appendix A.5).
Examples: A Procedure Step was performed exactly as scheduled. It could also be that a
Procedure Step was not exactly performed as scheduled, but without being rescheduled, e.g.,multiple Portable Media exist for a single Patient Study.
4.59.4.1.2.3.2

Unscheduled Import

SPS

0results
in

1

PPS

119
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

2970

In the UNSCHEDULED IMPORT Option the Importer does not receive Scheduled information.
There is a 0-to-1 relationship between SPS and PPS. The Patient information is received througha Patient Demographics Query and no Scheduled Procedure Step or Requested Procedure
information is available.
4.59.4.1.2.3.3

2975

Performed Protocol Sequence for Import

The Performed Protocol Code Sequence (0040,0260) shall be present in the Import Modality
Performed Procedure Step. It is used to provide information on how the import should be
handled (e.g., Interpret the Evidence Objects, Destroy the associated Media).
The Performed Protocol Code Sequence shall always contain one item with the value of(IRWF001, IHETFRAD, “Import”).

2980

In addition, if the Scheduled Protocol Code Sequence (0040,0008) exists, it shall be copied to the
Performed Protocol Code Sequence (0040,0260), unless modified by the operator. For both the
Scheduled and Unscheduled Import, the Importer may have the ability to add/modify the Import
Instructions (see RAD TF-2:4.5-4).
4.59.4.1.3

2985

Expected Actions

The Department System Scheduler/Order Filler, Report Manager and the Image Manager/Image
Archive receive information from the Performed Procedure Step Manager and in the scheduledcase, link it with the Requested Procedure and Scheduled Procedure Step.
How the Performed Procedure Step Manager, Department System Scheduler/Order Filler, ReportManager and the Image Manager/Image Archive uses the information contained within the
Performed Protocol Sequence is currently undefined.

4.60 Import Procedure Step Completed/Discontinued
2990

This section corresponds to Transaction RAD-60 of the IHE Technical Framework. Transaction
RAD-60 is used by the Department System Scheduler/Order Filler, Image Manager, ReportManager, Performed Procedure Step Manager and Importer actors.
4.60.1 Scope

2995

This transaction includes a message from the Importer to the Performed Procedure Step
Manager, which forwards the messages to the DSS/Order Filler, the Report Manager and theImage Manager that the Performed Procedure Step and importation has been completed. The
Image Manager may need the information to co-locate Evidence Objects of the same study. The
Modality Procedure Step Completed message does not necessarily mean that the set of Evidence
Objects is complete or available for retrieval.

120
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3000

4.60.2 Use Case Roles
Performed
Procedure Step
Manager

Image Manager
Report Manager

ImporterModality Procedure
Step Completed

Department System
Scheduler/Order Filler

Actor: Department System Scheduler/Order Filler.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Image Manager.
3005

Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Report Manager.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Importer.

3010

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure
Step and Importation is completed.
Actor: Performed Procedure Step Manager.
Role: Accepts Performed Procedure Step information from a Portable Media Importer orEvidence Creator and transmits it to the Department System Scheduler/Order Filler, ImageManager and Report Manager.

3015

4.60.3 Referenced Standards
DICOM 2011 PS 3.4: Modality Performed Procedure Step SOP Class.
DICOM 2011 PS 3.16: DCMR Context Groups (Normative)
4.60.4 Interaction Diagram

121
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Importer

Department System
Scheduler/Order
FillerPerformed Procedure Step
Manager/
Image Manager

MPPS N-SET

Report Manager

MPPS N-SETMPPS N-SET

3020
Importer

Performed Procedure Step Manager/
Department System Scheduler/Order
FillerMPPS N-SET

Image Manager

Report Manager

MPPS N-SETMPPS N-SET

3025

Note: The diagram above shows the sequencing of messages for the Modality Performed Procedure Step SOP Class.
Importers will also implement the Storage and Storage Commitment classes. The timing relationship between
PPS messages and Storage and Storage Commitment messages is not specified. That is, PPS messages may occur
before or after storage requests.

4.60.4.1 Procedure Step Completed/Discontinued
4.60.4.1.1

Trigger Event

User completes procedure step on the Importer.
3030

4.60.4.1.2

Message Semantics

The Importer shall send Modality Performed Procedure Step SOP Class (N-SET service) to
inform the Performed Procedure Step Manager that a specific Performed Procedure Step has
been completed or discontinued.
3035

The final N-SET has either the MPPS status of "COMPLETED" or "DISCONTINUED". The
Performed Procedure Step Manager forwards N-SETs to the Department System
Scheduler/Order Filler, Image Manager and Report Manager.

122
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
When an N-SET is issued with a “DISCONTINUED” status, one or more Series of Instances
may be referenced, if Evidence Objects were created and sent.
3040

Note: DICOM specifies that when attributes are allowed to be set by an N-SET, the value provided by the last N-SET
overrides any value set by an earlier N-CREATE or N-SET.

4.60.4.1.2.1 Retrieve AE Title

3045

According to the DICOM Standard, the Importer has the ability to include the Retrieve AE Title
attribute (0008,0054) in the Performed Series Sequence (0040,0340). This is an AE Title where
the referenced SOP instances for the series may be retrieved. This Retrieve AE Title will often
be zero length or be of short-term validity, due to the following situations:
•
•

3050
•

3055

If an Importer supports a Retrieve SOP Class in an SCP Role, the Importer’s Retrieve AE
Title may be included; however, the Importer does not guarantee long-term availability.
A Retrieve AE Title of the Image Manager can be configured on the Importer. Otherwise,
this field shall be sent zero length. Importer implementers shall not assume that thedestination AE Title used for the Storage SCP or Storage Commitment SCP is the sameas that for Image Retrieval.
An Importer may receive the Retrieve AE Title in a Storage Commitment Message (NEVENT REPORT). However, this information may be received well after the MPPS NSET (Complete) was performed.

4.60.4.1.2.2 Import PPS Exception Management
When the Modality Procedure Step is sent with the Status DISCONTINUED, the Procedure Step
Discontinuation Reason Code Sequence (0040,0281) shall be sent with values defined in
DICOM 2011 PS 3.16 Annex B Context ID 9300 or Table 4.60-1 (additional codes that are in
the process of being added by DICOM).

3060
Table 4.60-1: Context ID 9300 – Procedure Discontinuation Reasons Excerpt Most
Restrictive Use: Defined
Coding Scheme
Designator(0008,0102)

Code Value(0008,0100)

Code Meaning (0008,0104)

...
DCM

110521

Objects incorrectly formatted

DCM

110522

Object Types not supported

DCM

110523

Object Set incomplete

DCM

110524

Media Failure

The Reason Code when communicated to the DSS/Order Filler and Image Manager/Image
Archive may imply canceling an order. It may also facilitate more accurate charge posting.
3065

The Reason Code: “Incorrect Worklist Entry Selected” is used by the Importer to convey that thewrong Patient Demographics and/or Scheduled Procedure Step has been selected (incorrect
patient or incorrect Requested procedure/order for the same patient). In this case some or all of

123
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3070

the incorrectly imported Evidence Objects (for example the ones assigned to the wrong patient)may already have been stored to the Image Manager (see Section 4.60.4.1.3.1).
Importer implementers are left free to decide how to correct the resultant evidence objects. The
Importer shall include within the MPPS the list of imported objects that are or will be included in
the Import Stored Transaction(s).

3075Note: When a PPS DISCONTINUED is sent with the reason code "incorrect worklist entry selected", evidence objects
referenced in this PPS DISCONTINUED are Evidence Objects that may have been sent to the ImageManager/Archive. The IHE Technical Framework does not specify whether or not the Importer Actor needs toperform a Storage Commitment for these instances.

3080

The Reason Codes “Equipment Failure”, Objects incorrectly formatted”, “Object Types not
Supported”, “Object Set incomplete” and “Media Failure” will be used to indicate that the
expected Evidence Objects have been imported.
4.60.4.1.2.3 Billing and Material Management Option

3085

The message semantics are defined in the DICOM Service Class Section of the DICOM
Modality Performed Procedure Step SOP Class. It is the responsibility of the Importer to ensurethat the patient and procedure information is sent to the Department System Scheduler/Order
Filler.
The Attributes defined in Table 4.60-2 provide a means to transmit material management codesfrom the importer to the DSS/Order Filler that uses them for calculation of charges to be posted
to the Charge Processor.

3090

3095

An Importer that supports the BILLING AND MATERIAL MANAGEMENT Option shall beable to provide content within the Billing Procedure Step Sequence and the Billing Supplies andDevices Sequence. If the Billing Procedure Step is used, the Import Billing Code Table shall be
configured on the Importer. This table shall be synchronized with the Department System
Scheduler/Order Filler. The codes provided by the Importer might not be the same as the code
the Department System Scheduler/Order Filler is required to use when posting Charges to theCharge Processor.
The Billing Item Sequence provides the mechanism to track the number of media imported. See
Table 4.60.3 for the list of Coded Values that may be specified in the Billing Item sequencewhen there are charges associated with importing items such as a CD or digitizing a RadiologicalFilm. Multiple codes may be present.

3100
Table 4.60-2: Billing and Material Management Code Module Attributes Excerpt
Attribute name

Tag

Attribute Description

Billing Procedure Step Sequence(0040,0320)

Contains billing codes for the Procedure Type performed
within the Procedure Step. The sequence may have zero or
more Items. It may be zero-length if the Billing Supplies
and Devices Sequence is populated.

> Code Value(0008,0100)> Coding Scheme Designator(0008,0102)

124
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute nameTag

> Code Meaning

Attribute Description(0008,0104)…
Billing Supplies and Devices Sequence(0040,0324)

Contains billing codes for chemicals, supplies and devices
for billing used in the Performed Procedure Step. The
sequence may have one or more Items.

>Billing Item Sequence(0040,0296)

Codes values of chemicals, supplies or devices required forbilling. The sequence may have zero or one Items.

>> Code Value(0008,0100)>> Coding Scheme Designator(0008,0102)>> Code Meaning(0008,0104)>Quantity Sequence(0040,0293)

Sequence containing the quantity of used chemicals or
devices. The sequence may have zero or one Items.

>>Quantity(0040,0294)

Numerical quantity value. Specifies the number of media
imported or digitized.

…

Table 4.60-3: Context ID 7008 – Import Device Media

3105

Coding Scheme
Designator(0008,0102)

Code Value(0008,0100)

Code Meaning (0008,0104)

DCM

110020

Sheet Film Scanned

DCM

110021Cine Film Scanned

DCM

110022

Video Tape Scanned

DCM

110023

Page Digitized

DCM

110024

CD Imported

DCM

110025DVD Imported

DCM

110026

MOD Imported

DCM

110027

Studies Imported

DCM

110028Instances Imported

4.60.4.1.3

Expected Actions

The Image Manager, Report Manager and Department System Scheduler/Order Filler receive
information about the Performed Procedure Step being complete or discontinued. The ImageManager, Report Manager and Department System Scheduler are not required to act onintermediate N-SET messages with the MPPS Status "IN PROGRESS".
3110

In the case of the Scheduled Import, the Requested Procedure may be considered complete if all
Performed Procedure Steps related to all Scheduled Procedure Steps have been completed orproperly discontinued.

125
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.60.4.1.3.1 Import PPS Exception Management
3115

3120

3125

When an import exception occurs, the DSS/Order Filler or Image Manager/Archive shall use thereason codes in the final N-SET sent with the status of DISCONTINUED.
When the Modality Procedure Step is received with the Status DISCONTINUED, the receiver
shall interpret the Performed Procedure Step Discontinuation Reason Code Sequence(0040,0281) values as defined in DICOM (see Section 4.60.4.1.2.2). When received by the
Department System Scheduler/Order Filler and the Image Manager/Archive, the Reason Codemay indicate the necessity for modification or canceling of an order. With the Reason Code:“Incorrect Worklist Entry Selected”, the Importer Actor conveys that the wrong SPS or Patient
has been selected (e.g., incorrect patient or incorrect Requested procedure/order for the same
patient). In this case the Image Manager and Department System Scheduler shall take theappropriate action to ensure that already received incorrect instances (i.e., SOP Instancesreferenced by this Discontinued PPS) are not mistakenly used. If the images, presentation states,or key image notes are not actually deleted, the Image Manager shall:
•
•

3130

3135

not return SOP Instance UIDs for the images in query responses,
not return such images in Patient, Study, Series, or Instance level retrievals,

On the DSS and Image Manager, the Order/Requested Procedure status shall be corrected toindicate that the discontinued PPS (with wrong worklist entry selected) is not valid. Therefore
the Order Filler/Department System Scheduler shall not query for those instances with an Image
Availability Notification transaction [RAD-49].
When the Modality Procedure Step is received with the Status DISCONTINUED, it shall include
a Reason Code from the enumerated list (see Table 4.60-1). The Reason Code indicates that allof the Evidence Objects could not be imported. Typically this will be because some of the
DICOM Composite Objects are not supported by the local Enterprise. How the local Enterprisedeals with this situation is up to local policies and is out of scope of the Technical Framework.
4.60.4.1.3.2 Billing and Material Management Information Option

3140

3145

When Billing and Material Management information is provided in the MPPS N-SET, the
DSS/Order Filler shall use the billing codes and/or material usage information provided in the
final N-SET for calculation of charges that it will eventually post to the Charge Processor. It is
recommended that DSS/Order Filler verifies the consistency of provided billing codes with
Requested Procedure Code and Performed Procedure Step Protocol codes supplied in the same
N-SET.

4.61 Imported Objects Stored
This section corresponds to Transaction RAD-61 of the IHE Technical Framework. Transaction
RAD-61 is used by the Image Archive and the Importer actors.
4.61.1Scope3150

In the Imported Objects Stored transaction, the Importer sends the Evidence Objects to the Image
Archive. The reconciled information provided from the Modality Worklist transaction (see RAD

126
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
TF-2: 4.5) or the Patient Demographics Query (see ITI TF-2a:4.21) shall be included in theheaders of the generated images.
4.61.2 Use Case Roles

ImporterImage
Archive

Modality
Images Stored

3155
Actor: Image Archive
Role: Accept and store DICOM Composite Objects from the Portable Media Importer.
Actor: Importer
Role: Transmit imported DICOM object data to Image Archive
3160

4.61.3 Referenced Standards
DICOM 2011 PS 3.4: Storage Service Class, Section B.4.1 Conformance as an SCPDICOM 2011 PS 3.3 SOP Information Objects, Common Module Attribute
4.61.4 Interaction Diagram

Image
Archive

Importer

C-STORE (Evidence Objects Stored)

127
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3165

4.61.4.1 Evidence Objects Stored
4.61.4.1.1

Trigger EventsThe Importer can transfer Evidence objects to the Image Archive sequentially within one or more
DICOM associations, as the Evidence objects become available or collectively.
4.61.4.1.1.1 UIDs
3170

3175

Valid DICOM UIDs are universally unique, so there should be no risk of collision with local
UIDs. When a valid set of DICOM UIDs is present, the importer shall use this set and not change
them. If the importer detects incorrect UIDs or an inconsistent set of UIDs, then it may correct orre-generate UIDs. The UIDs are used as references between objects, and if they are altered, theImporter shall maintain referential integrity. Additional details about when it is appropriate for
an Importer to trigger the creation of a new Study/Series/Image Instance are described in RAD
TF-2: 4.8.4.1.1.1 “Study UIDs and Series UIDs”.
4.61.4.1.2

Message Semantics

The Importer uses the DICOM C-STORE message to transfer the DICOM Composite Objects.
The Importer is the DICOM Storage SCU and the Image Archive is the DICOM Storage SCP.
3180

If the import was scheduled, the User validates the available information for the patient and the
Scheduled Procedure Step/Requested Procedure and coerces the Patient/Order Information as
required (See Section RAD TF-2: Appendix A.5).
If the import was not scheduled, the User validates the available information for the patient andcoerces the Patient Information as required (See Section RAD TF-2: Appendix A.5).

3185

It is a requirement that certain information be recorded in the image header. The details of the
mapping to DICOM instances are specified in RAD TF-2: Appendix A.5.
Per the DICOM Standard, the Importer shall create a new series for its created images (e.g.,
Digitization of Films) and not extend series containing source images.
4.61.4.1.2.1 Original Attributes Sequence

3190

3195

When coercing (i.e., replacing or deleting attributes) from the original Evidence Objects, theImporter shall create or add to the “Original Attributes Sequence” (See Table 4.61.4.1.2-1) at the
top level and store the original values of those altered DICOM elements underneath it as definedin RAD TF-2: Appendix A.5.
The Importer shall use the “Original Attribute Sequence” to preserve information about theoriginal non-digitized data (e.g., Originating Institution, Time of the import, specific attributes
from the originating Institution). The mechanism and values which are preserved is out of scope
for the Technical Framework.

3200
128
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table 4.61.4.1.2-1: Original Attributes Sequence
Attribute Name

Tag

Type

Attribute Description

Original Attributes Sequence (Note 1,2)(0400,0561)

R+

Sequence of Items containing all attributes that are
specified by the User from the Original dataset.
One or more Items may be permitted in thissequence.

>Source of Previous Values(0400,0564)

R+

Identification of the Enterprise which originated theFilms or Documents.

>Attribute Modification Datetime(0400,0562)

R

Date and Time of the hardcopy scan

>Modifying System(0400,0563)

R

Identification of the local Enterprise>Reason for the Attribute Modification(0400,0565)

R

Reason for the attribute modification. Defined terms
are:
COERCE = Replace values of attributes such as
Patient Name, ID, Accession Number,for example, during import of media
from an external institution, or
reconciliation against a master patient
index.
CORRECT = Replace incorrect values, such as
Patient Name or ID, for example, whenincorrect worklist item was chosen or
operator input error.

>Modified Attribute Sequence(0400,0550)

R

Sequence containing a single item that contains all
the Attributes that supplied by the User from theOriginal Films or Documents.

…

>>Any Attribute from the main data set that was modified

Note 1: A new original attribute sequence is added every time the DICOM Objects are imported.

3205

Note 2: For digitized hardcopy the “old values” would be information the operator manually enters. It is expected that there
would be only one sequence in this case.

4.61.4.1.2.2 Contributing Equipment Sequence3210

In order to preserve the fact that these Evidence Objects have been imported into the Enterprise,
the Contributing Equipment Sequence shall be used (See Table 4.61.4.1.2-2). This will allow the
local Institution to make decisions based upon the fact that a set of Evidence Objects has been
imported (e.g., Schedule an over-read based upon an import, delete the imported Evidence
Objects after a prescribed amount of time). The behavior of how Imported Evidence Objects areused and maintained is out of scope of the Technical Framework.

129
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3215

Table 4.61.4.1.2-2: Contributing Equipment Sequence
Tag

Type

Contributing Equipment Sequence

Attribute Name

(0018,A001)

R+

See Notes 1,2Attribute Description>Purpose of Reference Code Sequence(0040,A170)

R

See Table 4.61.4.1.2-3>>Include ‘Code Sequence Macro’ Table 8.8-1

Defined Context ID 7005.

>Manufacturer(0008,0070)

R>Institution Name

(0008,0080)

R+>Station Name

(0008,1010)

R+>Contribution DateTime(0018,A002)

R+

Note 1: For imported objects, a new item shall be added to the Contributing Equipment Sequence every time a DICOM
Object is imported. Each item in the Contributing Equipment Sequence describes a particular piece of importing
equipment. The Equipment Module attributes describe the original creator of the instances.

3220

3225

Note 2: For digitized hardcopy, the Contributing Equipment Sequence shall contain a single item describing the originalacquisition equipment. Since the digitizer is the equipment creating the original DICOM instance, the Equipment
Module attributes describe the hardcopy digitizer.

The following table should be used to provide describe the equipment that has done the import.
This information may be used by an Institution at a later time to take actions specific to data
imported into the Enterprise.
Table 4.61.4.1.2-3: Context ID 7005 – Contributing Equipment Most Restrictive Use:
Defined3230

Coding Scheme
Designator(0008,0102)

Code Value(0008,0100)

DCM

MEDIM

Portable Media Importer Equipment

DCM

FILMD

Film Digitizer Equipment

DCM

DOCD

Document Digitizer Equipment

DCM

VIDD

Video Tape Digitizer Equipment

4.61.4.1.3

Code Meaning (0008,0104)

Expected Actions

The Image Archive will store the received DICOM objects.

3235

The DICOM Images, Evidence Documents and Diagnostic Reports shall be stored such thatthey can be later retrieved (See RAD TF- 2:4.16, RAD TF-2:4.17, RAD TF-2:4.27 and RAD
TF-2:4.3 ) in a fashion meeting the requirements defined for a DICOM Level 2 Storage SCP(Refer to DICOM PS 3.4 B.4.1).

130
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.61.4.1.3.1 DICOM Storage SOP Classes
The DICOM Standard defines a number of image specific storage SOP classes, as well as other
DICOM SOP Classes for DICOM SR, encapsulated pdfs, etc. All standard attributes and private
elements shall be stored.
3240

It is expected that the product’s DICOM Conformance Statement will state which DICOM
Storage SOP Classes it claims to support. Non-supported SOP Classes shall be rejected by the
Image Manager/ Image Archive in the C-Store association. How the Institution deals withsituations where DICOM Objects from the Importer cannot be stored is out of scope of theTechnical Framework.

3245

4.62 Store Dose Information
This section corresponds to Transaction RAD-62 of the IHE Technical Framework. Transaction
RAD-62 is used by the Acquisition Modality, Image Manager/Archive, Dose Information
Reporter and Dose Information Consumer actors.
4.62.1 Scope

3250

This section describes DICOM Storage requests of Structured Report objects containing Doseobjects which detail irradiation events. An Acquisition Modality sends Dose objects to an ImageManager/Archive for storage so they can be later used for monitoring or analysis of patientradiation exposure.
4.62.2 Use Case Roles
Image Manager/
Archive

Acquisition
Modality

Store Dose
Information

Dose Information
Consumer

Dose Information
Reporter

3255
Actor: Acquisition Modality
Role: Generate Dose objects describing irradiation events performed by the Acquisition
Modality and store them to one or more receiving actors.
Actor: Image Manager/Archive
3260

Role: Accept and Store Dose objects received from the Acquisition Modality.
Actor: Dose Information Consumer
Role: Accept and process Dose objects received from the Acquisition Modality.
Actor: Dose Information Reporter
Role: Accept and process Dose objects received from the Acquisition Modality.
131
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3265

4.62.3 Referenced Standard
DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD
DICOM 2011 PS 3.4: Storage Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes
DICOM 2011 PS 3.16: X-Ray Radiation Dose SR IOD Templates

3270

DICOM 2011 PS 3.16: CT Radiation Dose SR IOD Templates
DICOM 2011 PS 3.17: Annex AA: Radiation Dose Reporting Use Cases
4.62.4 Interaction Diagram
Acquisition
Modality

Image Manager/
Archive

C-STORE (Radiation Dose SR)

Note:

3275

In the above diagram, the Dose Information Consumer and the Dose Information Reporter may also receive the
C-STORE message.

4.62.4.1 Store Dose Information

3280

The Acquisition Modality Actor shall implement the X-ray Radiation Dose SR Storage SOPClass in the role of SCU. The Image Manager/Archive Actor, Dose Information Reporter Actorand Dose Information Consumer Actor shall implement the Dose Storage SOP Class in the roleof SCP.
Table 4.62-1: Dose Storage SOP Classes
SOP Class UID
1.2.840.10008.5.1.4.1.1.88.67

SOP Class Name
X-Ray Radiation Dose SR

4.62.4.1.1 Trigger Events
3285

An irradiation event is a single continuous exposure of radiation. For a more precise definition
including details relating to pulsed acquisition, dose modulation, dual source systems, etc. refer
to DICOM 2011 PS 3.16.
132
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________An Acquisition Modality shall record the relevant details for each irradiation event. These details
will be included in Dose objects as described below.
3290

Upon completion or discontinuation of a procedure step where irradiation events occurred, theAcquisition Modality shall compose an appropriate Dose Object containing all the irradiation
events for the procedure step and send the Dose object to the configured destinations.
Note:

3295

3300

3305

3310

The Dose Object is a DICOM Instance created in the context of the procedure step, and thus is expected to appear
in the list of instances in the corresponding MPPS.

In addition to composing Dose objects upon completion or discontinuation of a procedure step,
the Acquisition Modality may also compose and send a Dose object upon completion of an
irradiation event. If such behavior is supported, the actor shall provide a configuration method todisable it. Such objects could enable applications like dose mapping by a workstation during aprocedure. The irradiation events will duplicate events reported in the Dose object for theprocedure step, but this can be detected by receiving systems since the same irradiation event
UID will appear in both Dose objects.
In addition to composing Dose objects upon completion or discontinuation of a procedure step,
the Acquisition Modality may also compose and send a Dose Object summarizing an entire study
or series. Such objects might be preferred by systems wanting a summary of several procedure
steps. If such behavior is supported, the actor shall provide a configuration method to disable it.
The irradiation events will duplicate events reported in the Dose object for the procedure step,
but this can be detected by receiving systems since the same irradiation event UID will appear inboth Dose objects. If the Acquisition Modality does compose such additional Dose objects, it isappropriate to record the prior reports in the Predecessor Documents Sequence (0040,A360).
The Acquisition Modality shall clearly document in its DICOM Conformance Statement its
capabilities for grouping irradiation events into Dose objects.
4.62.4.1.1.1 Digitization

3315

3320

In the case of a system digitizing a film produced locally for which a Dose object has not been
generated, it would be appropriate to create and store a Dose object along with the digital
images. The digitizing system might create the report based on manual entry. An adjacent system
might create the report based on information in the generated images and/or the MPPS from thefilm-based modality.
Digitizing films for external priors shall be handled differently. The location where the prior was
originally created is responsible for recording the original dose. The digitizing system shall be
configurable/controllable to digitize external films and not produce a Dose object.
4.62.4.1.2 Message Semantics
The Acquisition Modality Actor shall use the DICOM C-STORE message to send Dose objects
encoded as DICOM SR objects. These objects serve as a record of irradiation performed by thedevice.

3325

The Acquisition Modality shall be capable of sending the Dose object to multiple destinations.
The primary storage destination is generally an Image Manager/Archive, however Dose
Information Reporters or Dose Information Consumers may also appear as configured
133
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
destinations when they need to receive timely Dose objects without having to repeatedly poll the
Image Manager/Archive.
3330

3335

The Acquisition Modality is responsible for delivery of Dose objects to the destination in spite ofintermittent connections (e.g., due to mobile modalities, network trouble, or the destination being
down).
The contents of the X-Ray Radiation Dose SR objects are generally based on Baseline Template
TID 10001 "Projection X-ray Radiation Dose" or Baseline Template TID 10011 "CT Radiation
Dose", but it should be noted that those templates are extensible, and the use of additional
templates is not prohibited.
Note:

3340

DICOM has extended these templates (and the templates they contain) several times since they wereoriginally introduced and further enhancements are possible. Implementers are reminded that they are responsible
for monitoring such changes and keeping their implementations current.

Acquisition Modality actors which report on irradiation events for Modalities of type CT shall becapable of producing an SR compliant with TID 10011.
Acquisition Modality actors which report on irradiation events for Modalities of type XR, XA,
RF, MG, CR, or DX shall be capable of producing an SR compliant with TID 10001.

3345

3350

The Irradiation Event UID in the template allows receiving systems to recognize duplicate
events. For example, the same dose event might appear in both an SR summarizing a procedure
and an SR summarizing the whole study.
The following attributes are Type 2 and Type 3. Although not required, Acquisition Modalities
which do not fill them in will make their Dose objects more difficult to process and analyze. If
present with a value in the Dose object, these attributes shall be populated as described in Table
4.62-2:
Table 4.62-2: Dose Context Attributes
Attribute Name

Tag

Requirement

Series Description(0008,103E)

Shall have a value in the appropriate language for local use that means
the equivalent of “Radiation Dose Information”, or similar.

Referenced Performed
Procedure Step Sequence(0008,1111)

Shall list the SOP Class UID and Instance UID of the image
acquisition PPS. Typically, only a single PPS is associated with a Doseobject. Since DICOM only permits a single value in this sequence, inthe case where a Dose object summarizes several PPS (e.g., of a whole
multi-step study), this attribute shall be left empty.

Performed Procedure Code
Sequence(0040,A372)

Shall contain the codes for the acquisition procedures performed by themodality (i.e., not a code for “Create Dose Report”). Creation of the
Dose object is to be considered part of the imaging procedure, not a
separate procedure in itself.

Requested Procedure
Description(0032,1060)

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry)

Admitting Diagnoses
Description(0008,1080)

Admitting Diagnoses Code
Sequence(0008,1084)

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry). This can facilitate checking compliance to indication-baseddose policies.

134
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3355

3360

Attribute Name

Tag

Reason for the Requested
Procedure(0040,1002)

Requirement

Reason for Requested
Procedure Code Sequence(0040,100A)

Patient’s Weight(0010,1030)

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry), if present, else obtained by operator entry and may beapproximate. This may facilitate future dose estimation and analysis.

Patient’s Size

(0010,1020)

I.e., height. Shall be copied from the relevant acquisition SPS(Modality Worklist entry), if present, else obtained by operator entry,
and may be approximate. This may facilitate future dose estimation
and analysis.

Patient’s Age(0010,1010)

Shall be filled from any valid source (e.g., computed from Patient’s
Birthdate and Study Date, copied from the relevant acquisition SPS(Modality Worklist entry), if present, else obtained by operator entry)
and may be approximate. This may facilitate future dose estimation
and analysis.

Patient’s Sex(0010,0040)

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry), if present, else obtained by operator entry.

In the event of a Group Case acquisition (see RAD TF-2: 4.6.4.1.2.3) a Dose object shall be
generated, reflecting the single acquisition procedure step performed, and should take its
attribute values from that image set. The procedure type would reflect the combined acquisition.
Allocating subsets of the dose to the pseudo-sub-procedures of the group is not required. If themodality chooses to replicate the dose object under each component accession of the group caseit shall set the Identical Documents Sequence appropriately. In either case the DIR can recognize
the duplication based on the Irradiation Event UIDs.
If the Dose object is not being created by the equipment which actually administered theradiation, the equipment creating the report shall reference itself in the Contributing Equipment
Sequence (0018,A001) and reference the irradiating equipment in the four Type 1 attributes inthe Enhanced General Equipment Module (DICOM 2011 PS 3.3: C.7.5.3).

3365

The Acquisition Modality shall be capable of creating Dose objects for patient scans and forphantom/calibration scans.
4.62.4.1.2.1 Cross-referencing Dose Objects and Image Objects
See RAD TF-2: 4.8.4.1.2.4, which requires Acquisition Modalities to record the Irradiation
Event UID (0008,3010) in related image instances.

3370

3375

The Projection X-Ray Dose Template (TID 10003) mandates that UID references be recorded in
the Acquired Image element for image instances created from the irradiation event. The CT Dose
Template does not include references to images since the instances sent to the ImageManager/Archive are typically generated some time after the irradiation is complete.
Note that it is possible for a study to have dose objects but no image objects. For example, due topoor quality images not being stored, or fluoroscopy images not being captured.

135
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.62.4.1.3 Expected Actions
The Image Manager/Archive shall support Level 2 (Full) storage, which means all DICOM Type1, 2 and 3 attributes (public and private) are stored. It shall accept the Dose objects, store them,and make them available for query/retrieval.
3380

The Dose Information Reporter and Dose Information Consumer shall accept the Dose objects.
The Dose objects shall be processed according to the features, configuration, and business logicof the Dose Information Reporter or Dose Information Consumer product. Possibilities include
display, processing, analysis, printing, export, etc. At a minimum, the Dose Information Reporter
shall provide the capability to the review and do summary analysis of the dose data.

3385

Dose Information Reporter actors shall be capable of processing both TID 10001 and TID
10011.

3390

When multiple Dose objects are received, the same Irradiation Event (as identified by its
Irradiation Event UID) may be referenced in multiple Dose objects. It is the responsibility of therecipient to recognize such duplicate Irradiation Events when processing or generating reports
based on the retrieved data.

4.63 Submit Dose Information
This section corresponds to Transaction RAD-63 of the IHE Technical Framework. Transaction
RAD-63 is used by the Dose Information Reporter and Dose Registry actors.
4.63.1 Scope
3395

This section describes secure FTP transfers of DICOM Structured Report objects which detailirradiation events. A Dose Information Reporter sends Dose objects to a Dose Registry for
subsequent compilation, monitoring and analysis of population and individual radiation exposureand current practices. Dose objects will often be de-identified prior to submission for the
population use case.

3400

4.63.2 Use Case Roles
Dose
Information
Reporter

Dose Register

Submit Dose
Information

Actor: Dose Information Reporter
Role: Submit (de-identified) Dose objects describing irradiation events performed byAcquisition Modalities in its facility.
3405

Actor: Dose Registry
Role: Accept and store Dose objects received from Dose Information Reporters.
136
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.63.3 Referenced Standard
DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD
DICOM 2011 PS 3.10: Media Storage and File Format
3410

DICOM 2011 PS 3.16: X-Ray Radiation Dose SR IOD Templates
DICOM 2011 PS 3.16: CT Radiation Dose SR IOD Templates
IETF RFC-4217 Securing FTP with TLS
4.63.4 Interaction Diagram
Dose
Information
Reporter

Dose Register

FTP (Radiation Dose SR)

3415

4.63.4.1 Submit Dose Information
4.63.4.1.1 Trigger Events
A Dose Information Reporter shall be capable of periodically submitting Dose objects
accumulated since the last submission.

3420

The Dose Information Reporter shall support submitting at a configurable interval, or upon amanual trigger, or both.
Local site policy and preferences will dictate whether periodic submissions take place, at whatfrequency, whether the Dose objects are first de-identified, and which Dose objects are submitted(e.g., the site might submit a random sample, or just reports for certain types of procedures, etc.)
4.63.4.1.2 Message Semantics

3425

3430

Except for de-identification, the Dose objects submitted by the Dose Information Reporter will
generally be copies of reports received via the Store Dose Information or Retrieve Dose
Information transactions.
The Dose Information Reporter shall ensure that the attributes described in RAD-62 in Table
4.62-2 Dose Context Attributes are populated (i.e., not empty and not zero or some other dummy
value), even if this requires a quality control step with additional manual data entry by anoperator.
137
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3435

It may also be desirable to send the localizer images to the registry, since size estimates can beproduced from these by image processing or manual measurement. An individual registry might
require this, so a Dose Information Reporter may have the capability to obtain and include
images with a Modality of CT and an Image Type (0008,0008) value 3 of LOCALIZER (foreither non-enhanced and enhanced SOP classes).
The Dose Information Reporter shall initiate a (Secure) FTP (File Transfer Protocol) session as aclient as specified by IETF RFC-4217 “Securing FTP with TLS”.
When initiating the FTP session, the Dose Information Reporter:

3440

1. Shall use the "firewall-friendly" connection method
2. Shall negotiate TLS first, before any other FTP commands
3. Shall require a protection level of "Private" (i.e., the connection shall fail if a level of“Private” is not successfully negotiated)

3445

4. Shall support AES, although it is acceptable for an alternative encryption to be
dynamically negotiated as part of TLS.
5. Shall support and accept certificate authentication. User authentication shall not be
required.
6. Shall support X.509 based certificates.
7. Shall disconnect when TLS fails.

3450
Note:

3455

Certificate Management by the Dose Information Reporter and the Dose Registry is outside the scope of the
REM Profile. Dose Registries may find it convenient to make their public certificate available on their web
server. Hospitals with Dose Information Reporters might have their public certificate available in a file they
could email to the Dose Registry administrator when joining such a project. A detailed discussion of certificate
management can be found in the “Management of Machine Authentication Certificates” Whitepaper developedby the NEMA Security and Privacy Committee, available on the NEMA
Websiteathttp://www.medicalimaging.org/wp-content/uploads/2011/02/CertificateManagement-2007-05Published.pdf

The Dose Registry shall be capable of accepting a secure FTP session as documented above.
3460

3465

The Dose Registry may require the Dose Information Reporter to identify itself (for audit
purposes) by providing a descriptive string either in the USER login (with no password) or in the
PASS of an anonymous USER login. The Dose Information Reporter shall support configuring
such details.
The Dose Information Reporter shall use the FTP session to submit Dose objects encoded in
DICOM SR and formatted as DICOM Part 10 media files with a Transfer Syntax of Explicit VR
Little Endian.
The Dose objects may be transferred as either:
•
•

3470

individual files, orcomposed into Zip File Media as described in DICOM 2011 PS 3.12 Annex V.

DICOM Zip File Media requires a valid DICOMDIR be present.

138
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________The Dose Information Reporter shall be capable of sending the Dose objects to multiple
configured destinations.
The Dose Information Reporter is responsible for delivery of Dose objects in spite of intermittent
connections (network trouble, or the destination system being down).
3475

4.63.4.1.2.1 De-identification
The Dose Information Reporter shall be capable of de-identifying Dose objects before submitting
them.

3480

There is considerable variation in what attributes need to be removed to achieve sufficient deidentification for any particular purpose. See the discussion in RAD TF-3: Appendix I andDICOM 2011 PS 3.15 Annex E.
Accordingly, this transaction does not require the removal of all text attribute values, nor theremoval of all private attribute values.

3485

3490

3495

3500

The Dose Information Reporter may provide a mechanism to allow the user to configure those
attributes that will be removed or replaced. At minimum the Dose Information Reporter shallsupport the ability to configure removal and replacement of all those attributes listed in the Basic
Application Level Confidentiality Profile in DICOM 2011 PS 3.15. It shall be configurable to
use:
•
•
•
•

the Retain Longitudinal Option
Retain Patient Characteristics Option
Retain Device Information Option
Retain UIDs Option

This configurability is particularly important since details such as patient sex, approximate age
and weight, anatomy imaged and type of procedure are typically part of population dose analysis
and such analysis would be severely limited without the ability to leave such information insubmitted data. If the value in the Patient Birth Date (0010,0030) is removed from a Dose object
during de-identification, then the Patient Age (0010,1010) attribute shall be included with anappropriate value.
When de-identification has been performed, the Dose Information Reporter shall add to the
DICOM dataset of each instance the Patient Identity Removed (0012,0062) attribute with a valueof YES, and add a value for De-identification Method (0012,0063) or De-identification Method
Code Sequence (0012,0064).
The Dose Information Reporter shall be configurable to perform no de-identification at all.

3505

In some scenarios, it may be appropriate to perform no de-identification, such as when the Dose
Registry is doing a longitudinal study for specific patients (and necessary consents and/or
privacy agreements have been taken care of). In such cases, if the Patient Identity Removed(0012,0062) attribute is present in the dataset it shall not be changed before submitting thedataset; if the attribute is absent it shall be added with a value of NO.
The Dose Information Reporter shall be capable of different de-identification configuration
settings for each submission destination.
139
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3510

In some de-identification scenarios, the UIDs might need to be replaced. This transaction does
not require that the Dose Information Reporter have the ability to replace UIDs, but if UIDs are
replaced, internal consistency within the exported set of instances and across multiple exports
over time shall be maintained. This entails adherence to the following rules:
•

3515
•

3520

3525

3530

•

The same replacement UID is used for all composite instances of the same entity within
the set, e.g., if the Study Instance UID is replaced, it is replaced with the same value in all
dose objects within the same original study.
References by UID to other instances or entities within the set are updated, e.g.,references to the SOP Instance UIDs of predecessor documents, reference images andsource images.
References by UID to other instances or entities not included within the set are removed
or replaced with consistent, well-formed, dummy references.

If the same instances are exported multiple times on different occasions, the identifying attributesand UIDs therein shall be replaced with the same values on each occasion. That is, thistransaction requires deterministic behavior for replacement of identifying attributes and UIDs.
This assures that the receiving Dose Registry can detect duplicate submissions and notaccumulate the same dose multiple times. The safest way to assure detection of duplicate
submissions from a single or multiple sites is not to replace the UIDs in the first place, but local
regulations or policy may not permit this.
The Dose Information Reporter performing de-identification shall not create invalid IODs.
Specifically:
•
•
•

3535
•

Mandatory and conditional attributes may not be removed, but rather must be replaced.
Type 1 attributes must be given a value.
Type 2 attributes may be encoded zero length, but it is often advisable to encode a value,
especially for attributes likely to be used in browsers such as Patient Name, Patient ID,
Study ID and Accession Number.
UIDs shall have valid roots and be genuinely globally unique.

The Dose Information Reporter is not required to be able to pseudonymize Dose objects. For a
description of pseudonymization, see RAD TF-3: 4.51.4.1.4.
4.63.4.1.3 Expected Actions
3540

3545

The Dose Registry shall accept the received Dose objects. What it does with the Dose objects
will depend on the features, configuration, and business logic of the product. Some details of
several Dose Registry projects are discussed in RAD TF-1: Appendix I – Deployment of Dose
Registries.
Although the Dose Information Reporter may keep track of which Dose objects have beenpreviously submitted to avoid duplicates or missing objects, the Dose Registry cannot depend on
every object being sent, and should also be prepared to check for duplicates (by checking theIrradiation Event UIDs, though these may have been affected by de-identification during thecurrent and previous submission, particularly if the same information is received multiple times
from different Dose Information Reporters).

140
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3550

4.64 Query Dose Information
This section corresponds to Transaction RAD-64 of the IHE Technical Framework. Transaction
RAD-64 is used by the Dose Information Reporter, Dose Information Consumer and ImageManager/Archive actors.
4.64.1 Scope

3555

A Dose Information Reporter or Dose Information Consumer requests and receives from theImage Manager/Archive a list of instance metadata describing Dose objects matching a specified
filter.
4.64.2 Use Case Roles
Dose
Information
ReporterImage Manager/
Archive

Query Dose
Information
Dose
Information
Consumer

3560

Actor: Dose Information Reporter
Role: Query for a list of Dose objects (generally in order to retrieve them).
Actor: Dose Information Consumer
Role: Query for a list of Dose objects (generally in order to retrieve them).
Actor: Image Manager/Archive

3565

Role: Respond to queries from Dose Information Reporters and Dose Information Consumers
for Dose objects matching the specified filter.
4.64.3 Referenced Standard
DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes

3570

DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD

141
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.64.4 Interaction Diagram
Dose
Information
ReporterImage
Manager/Archive
Query Dose Reports (C-FIND)

Query Responses (C-FIND)

Note: In the above diagram, the Dose Information Consumer may also receive and respond to the C-FIND message.

4.64.4.1 Query Dose Information
3575

The Query (Study Root – FIND and optionally Patient Root – FIND) SOP Classes shall besupported. Refer to DICOM 2011 PS 3.4: Query/Retrieve Service Class for detailed descriptive
semantics.
4.64.4.1.1 Trigger Events
The Dose Information Reporter needs to obtain information about Dose objects.

3580

3585

Often this will be triggered by the Dose Information Reporter preparing to produce reports,
preparing to perform analyses or preparing to submit data to a dose registry based on local
policies. Examples of such triggers might include generating a daily report of procedures
exceeding Diagnostic Reference Levels for certain procedure types, producing a summary ofdose to a particular patient over the past year, or submitting reports for all procedures performedin the past week to a national dose registry.
The Dose Information Consumer needs to obtain information about Dose objects.

3590

Often this will be triggered by the Dose Information Consumer preparing to display or further
process the contents of one or more Dose objects. Examples of such triggers might include
processing the contents of a dose object together with the generated images in order to produce adose map. Refer to the Use Cases in RAD TF-1: 22.3 Radiation Exposure Monitoring Process
Flow for more details.
4.64.4.1.2 Message Semantics
The message semantics are defined by the DICOM Query/Retrieve SOP Classes.

3595

The Dose Information Reporter and Dose Information Consumer actors shall implement theQuery/Retrieve SOP Classes in the role of SCU. The Image Manager/Archive Actor shall
implement the Query/Retrieve SOP Classes in the role of SCP.
A C-FIND Request from the DICOM Study Root Query/Retrieve Information Model – FIND
SOP Class or the DICOM Patient Root Query/Retrieve Information Model – FIND SOP Class
142
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3600

shall be sent from the Dose Information Reporter or Dose Information Consumer to the ImageManager/Archive.
The Dose Information Reporter or Dose Information Consumer uses one or more matching keys
as filter criteria to obtain the list of matching entries in the Image Manager/Archive at the
selected level (Patient & Study/Series/Instance).

3605

In addition to the required and unique keys defined by the DICOM Standard, the Dose Report
Query SCU and SCP shall support the matching and return keys defined for Study, and Series
level queries as defined in RAD TF-2: 4.14.4.1.2 and Table 4.14-1.
The Dose Information Reporter (SCU), the Dose Information Consumer (SCU) and the ImageManager/Archive (SCP) shall also support the Dose Report Instance-specific keys defined inTable 4.64-1.

3610
Table 4.64-1: Dose Report Instance Specific Query Matching and Return Keys
Attribute Name

Tag

Query Keys Matching

Query Keys Return

SCU

SCU

SCP

SCP

Dose Report Instance Specific Level
SOP Class UID(0008,0016)

O

R+

O

R+

SOP Instance UID(0008,0018)

O

R

O

R

Content Date

(0008,0023)

O

O

O

R+

Content Time

(0008,0033)

O

O

O

R+

Referenced Request Sequence(0040,A370)>Study Instance UID(0020,000D)

O

O

R+*

R+

>Accession Number(0008,0050)

O

O

R+

R+

>Requested Procedure ID(0040,1001)

O

O

R+

R+

>Requested Procedure Code
Sequence(0032,1064)>>Code Value(0008,0100)

O

O

O

R+

>>Coding Scheme Designator(0008,0102)

O

O

O

R+

>>Coding Scheme Version(0008,0103)

O

O

O

R+

>>Code Meaning(0008,0104)

O

O

O

R+

Content Template Sequence(0040,A504)>Template Identifier(0040,DB00)

O

O

R+

R+

Concept Name Code Sequence(0040,A043)>Code Value(0008,0100)

O

O

R+*

R+

>Coding Scheme Designator(0008,0102)

O

O

R+*

R+

>Coding Scheme Version(0008,0103)

O

O

O

R+

>Code Meaning(0008,0104)

O

O

R+

R+

The requirement conventions for key usage in the above table are defined in RAD TF-2: 2.2.

143
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.64.4.1.2.1 Filtering Strategies
3615

Since it may not be immediately obvious how to perform certain dose object filtering based on
the available matching keys, return keys and object content, some suggestions are provided here.

3620

Filtering can occur at three points. Matching keys allow filtering on the server side; only
instances that pass the filter have metadata returned. Return keys allow filtering on the clientside; only instances whose metadata passes the filter are subsequently retrieved. Finally object
attributes or content tree elements allow further client side filtering; only retrieved instances thatpass the filter are processed further.
Client-side filtering of the object attributes and content is the most flexible, but to avoid
retrieving an unnecessarily large number of objects, the use of matching and return keys is very
helpful.
To filter for Dose objects:

3625

•

Matching key - SOP Class UID (0008,0016) allows selection of the X-ray Radiation
Dose SR Storage SOP Class.

To filter for a specific date range:•
3630

Matching key – Study Date (0008,0020) and/or Performed Procedure Step Start Date
(0040,0244) allows selection of a particular date or range.

To filter for specific modalities:•

Matching key - Modalities in Study (0008,0061) allows selection of a desired modality(e.g., CT, XA, DR, DX, CR, MX)

Note:

3635

•

•
3640

Some studies might have multiple irradiating modalities so it will still be necessary to confirm the modality in thedose report. Note also that the series level Modality attribute will always be SR for dose reports.

Return key - Template ID (0040,DB00) allows identification of either CT or Projection
X-Ray dose reports. Future dose reports will also be identifiable by new Template ID
values, making this a potentially valuable attribute for the Archive to support as amatching key.
Object Content Tree - Procedure Reported allows differentiation of Mammography fromother types of projection x-ray

To filter for specific procedure types:
•

3645
•

Object Attribute - Performed Procedure Code Seq. (0040,A372) is Type 2, but if filled in
the Dose object, will contain the acquisition procedures performed, allowing
identification of the procedure. Since these are local codes and tend to change, systems
will likely need to use a lookup table to map the variety of procedure/anatomy codes to asmaller set for performing analysis and reporting.
Object Content Tree – Acquisition Protocol, if present, may also help identify theprocedure type.

Note:

3650

Series Description (0008,103E) is a Type 3 attribute which, if present, in a Dose object will have a value of“Radiation Dose Information”.

To filter for specific body regions:
144
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•

Object Content Tree – Target Region allows identification of body regions.

Note:

3655

•

Some implementations may provide a very specific region and the filter will want to generalize; other
implementations may be unable to identify the exact region and will provide an overly generalized region instead.

Object Content Tree – Anatomical Structure, if present, may also identify body regions inprojection x-ray dose reports.

To filter for patient age category:
•
3660

•

Return key – Patient’s Birth Date (0010,0030) allows identification of patients in an age
range.
Return key - Patient’s Age (0010,1010) is a Type 3 attribute and an optional return key
but may allow identification of some patients in an age range.

To filter for patient weight category:•
3665

Return key - Patient’s Weight (0010,1030) is a Type 3 attribute and an optional return
key but may allow identification of some patients in a weight range.

To filter for patient sex:•

Return key – Patient’s Sex (0010,1040) allows identification of patient’s sex (e.g., formonitoring policies relating to women of childbearing age).

4.64.4.1.3 Expected Actions
3670

The Image Manager/Archive receives the C-FIND request, performs the matching on theprovided keys and sends the list of matching records back to the Dose Information Reporter or
Dose Information Consumer via C-FIND responses.
The Dose Information Reporter or Dose Information Consumer may use the value of certain
return keys to identify specific Dose objects for subsequent retrieval. See Section 4.64.4.1.2.1 fordetails. Some details are only available by first retrieving and then parsing the dose objects.

3675

4.65 Retrieve Dose Information
This section corresponds to Transaction RAD-65 of the IHE Technical Framework. Transaction
RAD-65 is used by the Dose Information Reporter, Dose Information Consumer and ImageManager/Archive actors.
4.65.1 Scope

3680

A Dose Information Reporter or Dose Information Consumer requests and receives from theImage Manager/Archive specified instances of Dose objects.

145
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.65.2 Use Case Roles
Dose
Information
ReporterImage Manager/
Archive

Retrieve Dose
Information
Dose
Information
Consumer

Actor: Dose Information Reporter
3685

Role: Request and receive specific Dose objects from the Image Manager/Archive.
Actor: Dose Information Consumer
Role: Request and receive specific Dose objects from the Image Manager/Archive.
Actor: Image Manager/Archive

3690

Role: Provide specified Dose objects requested by Dose Information Reporters and Dose
Information Consumers.
4.65.3 Referenced Standard
DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes
DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD

3695

4.65.4 Interaction Diagram
Dose
Information
ReporterImage
Manager/Archive

Request Dose Reports (C-MOVE)Store Dose Reports (C-STORE)

Note:

In the above diagram, the Dose Information Consumer may also submit a C-MOVE request and receive a CSTORE message.

146
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.65.4.1 Retrieve Dose Information
3700

The Retrieve (Study Root – MOVE and optionally Patient Root – MOVE) SOP Classes shall besupported. This requires that C-MOVE also be supported at the Series Level. Refer to the
DICOM 2011 PS 3.4 Annex C for detailed descriptive semantics.
The Image Manager/Archive, Dose Information Reporter and Dose Information Consumer actors
shall support the SOP Classes shown in Table 4.65-1 below.

3705
Table 4.65-1: Dose Storage SOP Classes
SOP Class UID
1.2.840.10008.5.1.4.1.1.88.67

SOP Class Name
X-Ray Radiation Dose SR

4.65.4.1.1 Trigger Events
3710

The Dose Information Reporter or Dose Information Consumer decides it needs a specific Doseobject.
4.65.4.1.2 Message Semantics

3715

The message semantics are defined in the DICOM Query/Retrieve Service Class Section of the
DICOM 2011 PS 3.4: Query/Retrieve Service Class. The Dose Information Reporter or Dose
Information Consumer is the DICOM C-Move SCU and DICOM Storage SCP and the ImageManager/Archive is the DICOM C-Move SCP and DICOM Storage SCU.
The contents of the X-Ray Radiation Dose SR objects are generally based on Baseline Template
TID 10001 "Projection X-ray Radiation Dose" or Baseline Template TID 10011 "CT Radiation
Dose" but it should be noted that those templates are extensible, and the use of additional
templates is not prohibited.

3720

3725

It is the responsibility of the Image Manager/Archive to assure that the patient and procedure
information is current in the Dose objects when they are retrieved from the ImageManager/Archive.
The Image Manager/Archive receives the C-MOVE request, establishes a DICOM association
with the Dose Information Reporter or Dose Information Consumer, and uses the DICOM CSTORE command to transfer the requested Dose objects.
4.65.4.1.3 Expected Actions

3730

The Dose Information Reporter and Dose Information Consumer shall accept the Dose objects.
The Dose objects shall be processed according to the features, configuration, and business logicof the Dose Information Reporter or Dose Information Consumer product. Possibilities include
display, processing, analysis, printing, export, etc.
Dose Information Reporter actors shall be capable of processing both TID 10001 and TID
10011.

147
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3735

The Dose Information Reporter or Dose Information Consumer shall not return an error to theArchive due to not recognizing the template used or the retrieved document content. The
retrieved results may simply be discarded instead.
The same Irradiation Event (as identified by its Irradiation Event UID) may be referenced in
multiple Dose objects. For example, the same dose event might appear in both an SR
summarizing a procedure and an SR summarizing the whole study.

3740

The Dose Information Reporter and Dose Information Consumer shall recognize duplicate
Irradiation Events based on the Irradiation Event UIDs in the Dose object.
The Dose Information Reporter shall be capable of presenting some form of report to the user
based on the retrieved dose information. The format, contents and analysis of such reports are
not defined by the REM Profile. Such details should be worked out as part of the product design.

4.66 Rejection Note Stored
3745

This section corresponds to Transaction RAD-66 of the IHE Radiology Technical Framework.
Transaction RAD-66 is used by the Acquisition Modality, Evidence Creator, ImageManager/Image Archive and Change Requester actors.
4.66.1 Scope

3750

In this transaction, the Acquisition Modality, Change Requester or the Evidence Creatortransmits a specific DICOM Key Object Selection (Rejection Note) to the Image Manager /Image Archive for marking referenced images as "rejected". Beforehand, a user will have:•selected specific images to be rejected for quality reasons, including a reason forrejection, or•

corrected certain images so that the original incorrect images are to be rejected forpatient safety reasons, or•associated certain images to the correct modality worklist entry so that the original
images are to be rejected for incorrect modality worklist selection reason

3755

Alternatively, a user or the Image Manager / Archive selected specific instances to be deleted
due to data retention policy expiration, including a reason for deletion.
3760

4.66.2 Use Case Roles
Acqusition
Modality

Image Manager /Image Archive

Evidence
Creator

ChangeRequester

Image Rejection
Note Stored

Fig. 4.66.2-1: Use Case Diagram

148
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Actor: Acquisition Modality3765

Role: Flags acquired available images that are incorrect or rejected for quality reasons bycreating a Rejection Note and sending it to the Image Manger/ Image Archive.
Actor: Evidence Creator
Role: Flags images that are incorrect or rejected for quality reasons by creating a Rejection Noteand sending it to the Image Archive.
Actor: Image Manager/ Image Archive

3770

Role: Image Archive receives, processes and stores the Rejection Notes received from theAcquisition Modality or Evidence Creator. Image Manager/ Image Archive applies defined logic
to the images that are referenced in the Rejection Note.
Actor: Change Requester

3775

Role: Flags available instances that are (1) associated with an incorrect modality worklist entry,(2) expired for data retention policy or (3) rejected due to quality or patient safety reasons bycreating a Rejection Note, and sending it to the Image Manager / Archive.
4.66.3 Referenced Standards
DICOM 2011 PS 3.4: Key Object Selection Document Storage SOP ClassDICOM 2011 PS 3.4: Storage SOP Class

3780

DICOM 2011 PS 3.4: Query/Retrieve SOP ClassDICOM 2011 PS 3.16: TID 2010, CID 7011
4.66.4 Interaction Diagram
Image Manager/
Image Archive

Acquisition
Modality

Evidence Creator

Rejection Note Stored

Rejection Note Stored(C-STORE)(C-STORE)

Figure 4.66.4-1 Interaction Diagram: Rejection Note Stored
Image Manager/
Image Archive

ChangeRequester

Rejection Note Stored(C-STORE)

3785
Figure 4.66.4-1: Interaction Diagram: Rejection Note Stored in IOCM

149
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3790

This transaction relates to the “DICOM C-STORE” event between the Acquisition Modality, theEvidence Creator, or the Change Requester and the Image Manager/ Archive in the above
interaction diagram. The Acquisition Modality, the Evidence Creator or the Change Requester isthe DICOM Storage SCU and the Image Manager / Archive is the DICOM Storage SCP.
The following table summarizes Key Object Selection Document Titles usage in different
profiles:3795

Table 4.66.4-1: Profile Supported Key Object Selection Document Title
KOS Document Title

MAWF

IOCM

(113001, DCM, "Rejected for Quality
Reasons")

X

X(113037, DCM, "Rejected for Patient
Safety Reasons")

X

X(113038, DCM, “Incorrect Modality
Worklist Entry”).

X(113039, DCM, “Data Retention
Policy Expired”)

X

4.66.4.1 Rejection Note Stored (for Quality Reasons)4.66.4.1.1 Trigger Events

3800

An operator at the Acquisition Modality, the Evidence Creator or the Change Requester detectsthat certain images just acquired are of insufficient quality. She marks these images using thecapability provided by the systems implementing these actors. Thereby, she generates a
Rejection Note which the Acquisition Modality, Evidence Creator or the Change Requester
sends to the Image Manager / Archive.
4.66.4.1.2 Message Semantics

3805

The Acquisition Modality, Evidence Creator or Change Requester shall create a new Key Object
Selection instance in a new Series of the rejected images' Study. Integration-critical values shallbe filled as defined in the Evidence Document Attribute Mapping (RAD TF-2: A.2). The
instance shall be constructed as defined in DICOM PS 3.3 and 3.4, and shall have the following
values in the DICOM template TID 2010:•

A Key Object Selection Document Title code of (113001, DCM, "Rejected for Quality
Reasons").

•

At least one Document Title Modifier code from DICOM Context Group 7011.

•

References to all rejected images.

3810

4.66.4.1.3 Expected Actions
3815

The Image Manager / Archive receives the Key Object Selection with the Document Title valued(113001, DCM, "Rejected for Quality Reasons") and shall store it. The Image Manager/ Image
Archive shall support the two behaviors listed below. The behavior chosen shall be configurable.
150
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

3820

3825

•

Regular use: For the Key Object Selection instance and all instances referenced therein,
the Image Manager / Archive shall return SOP Instance UIDs in Query Responses andthe instances in Patient, Study, Series, or Instance level retrievals.

•

Hide rejected instances: For the rejected instances referenced in the Key Object
Selection, the Image Manager / Archive shall neither return SOP Instance UIDs in Query
Responses nor return the instances in Patient, Study, Series, or Instance level retrievals.

If the complete series is rejected according to the specified behavior as described above, then the
Image Manager / Archive may or may not return the empty series in the C-FIND response when
it receives a SERIES level C-FIND request.
4.66.4.1.3.1 Access to Rejected Instances
The contents of this section are required for Image Manager / Archive actors in the Imaging
Object Change Management Profile.

3830

The Image Manager / Archive shall provide two Application Entities for each C-FIND service
and each C-MOVE service; one AE associated with the Regular Use behavior, and one AE
associated with the Hide Rejected Instances behavior (See 4.66.4.1.3).
The Image Manager / Archive shall be configurable to restrict access to the “Regular Use”
Application Entity to a limited set of calling AE Titles.
4.66.4.2 Rejection Note Stored (for Patient Safety Reasons)3835

4.66.4.2.1 Trigger Events

3840

An operator at the Acquisition Modality, the Evidence Creator or the Change Requester detectsthat certain just acquired images or just created evidence documents are incorrect. She corrects
these images or evidence documents using the capability provided by the systems implementing
these actors. Thereby, she generates a Rejection Note which the Acquisition Modality, Evidence
Creator or Change Requester sends to the Image Manager / Archive.
4.66.4.2.2 Message Semantics
The Acquisition Modality, the Evidence Creator or the Change Requester shall be able to let auser correct one or more attributes in images that are displayed or in evidence documents that are
applied.

3845

3850

•

The user shall be able to store new, corrected images or evidence documents at theAcquisition Modality as defined in RAD TF-2:4.8.4.1.2.4 or at the Evidence Creator as
defined in RAD TF-2:4.18.4.1.2.5.

The Acquisition Modality, Evidence Creator or Change Requester shall create a new Key Object
Selection instance in a new Series of the incorrect instances' Study. Integration-critical values
shall be filled as defined in the Evidence Document Attribute Mapping (RAD TF-2: A.2). The
instance shall be constructed as defined in DICOM PS 3.3 and 3.4, and shall:•

have the Key Object Selection Document Title value (113037, DCM, "Rejected forPatient Safety Reasons")
151

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•
3855

reference all incorrect instances and derived instances (e.g., FOR PRESENTATION
and FOR PROCESSING).

This Key Object Selection instance shall be stored to the Image Manager / Archive. It serves as a
trigger to disallow routine use of these incorrect instances that it references.
4.66.4.2.3 Expected Actions
3860

The Image Manager / Archive receives incorrect and corresponding corrected instances, as wellas the Key Object Selection (KOS) instance with the Document Title value (113037, DCM,
"Rejected for Patient Safety Reasons"). The Image Manager / Archive shall be triggered by thisspecific Key Object Selection to hide the incorrect instances and shall:•

3865

Not provide the incorrect instances referenced in this KOS in responses to an image
query/ retrieve transaction (RAD-14, RAD-16) or presentation state query/retrievetransaction (RAD-15, RAD-17).

If the complete series is rejected according to the specified behavior as described above, then the
Image Manager / Archive may or may not return the empty series in the C-FIND response when
it receives a SERIES level C-FIND request.
3870

Note:

This hiding of incorrect instances is only triggered by a KOS with this specific title (in contrast to the general useof KOS as defined for Key Image Note, see RAD TF-1: 8).

4.66.4.2.3.1 Additional Requirements for Image Manager / Archive in IOCM
The Image Manager / Archive shall be triggered by this specific Key Object Selection to hide theincorrect instances as specified in Section 4.66.4.2.3 and it shall:
3875•

Not accept subsequent occurrence of instances that have been hidden.

4.66.4.3 Rejection Note Stored (for Incorrect Modality Worklist)
4.66.4.3.1 Trigger Events

3880

An operator at the Change Requester (grouped with an Acquisition Modality or Image Manager /Archive) detects that certain images just acquired and transmitted are associated with anincorrect modality worklist entry. She corrects the images to the correct modality worklist entry
using the capability provided by the systems implementing these actors. Thereby, she generates a
Rejection Note and sends it to the Image Manager / Archive.
4.66.4.3.2 Message Semantics

3885

The Change Requester shall enable a user to associate one or more objects in the study with thecorrect modality worklist entry. The Change Requester shall create a new Key Object Selection
instance in a new Series of the study referencing the instances associated with the incorrect
modality worklist entry. Integration-critical values shall be filled as defined in the Evidence
Document Attribute Mapping (RAD TF-2: A.2). The instance shall be constructed as defined in
DICOM PS 3.3 and 3.4, and shall have the following values in the DICOM template TID 2010:

152
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
3890•

A Key Object Selection Document Title code of (113038, DCM, “Incorrect Modality
Worklist Entry”).

•

References to all instances associated with the incorrect modality worklist entry.

4.66.4.3.3 Expected Actions
3895

The Image Manager / Archive receives incorrect instances and the corresponding corrected
instances, as well as the Key Object Selection (KOS) instance with the Document Title values(113038, DCM, “Incorrect Modality Worklist Entry”). The Image Manager / Archive shall be
triggered by this specific Key Object Selection instance to hide the incorrect instances and shall:•

Not provide the incorrect instances referenced in this KOS in responses to an image
query/retrieve transaction (RAD-14, RAD-16) or presentation state query/retrievetransaction (RAD-15, RAD-17).

•

Not accept subsequent occurrence of instances that have been hidden.

3900

3905

If the complete series is rejected according to the specified behavior as described above, then the
Image Manager / Archive may or may not return the empty series in the C-FIND response when
it receives a SERIES level C-FIND request.
4.66.4.4 Rejection Note Stored (for Data Retention Expiry)
4.66.4.4.1 Trigger Events

3910

A manual or automatic procedure in the Change Requester (grouped with Image Manager /Archive) determines that certain instances exceed the required period of data retention andautomatically deletes them locally. Based on configuration, the Change Requester communicatesthe expiry of instances to an external Image Manager / Archive (e.g., Centralized Archive).
Thereby, it generates a Rejection Note and sends to the external Image Manager / Archive.
4.66.4.4.2 Message Semantics

3915

The Change Requester shall create a new Key Object Selection instance in a new Series for eachstudy with the expired instances. Integration-critical values shall be filled as defined in the
Evidence Document Attribute Mapping (RAD TF-2: A.2). The instance shall be constructed as
defined in DICOM PS 3.3 and 3.4, and shall have the following values in the DICOM template
TID 2010:•

A Key Object Selection Document Title code of (113039, DCM, “Data Retention Policy
Expired”).

•

References to all instances within the study that have exceeded the required data retention
period.

3920

4.66.4.4.3 Expected Actions
3925

The Image Manager / Archive receives the Key Object Selection (KOS) instance with theDocument Title values (113039, DCM, “Data Retention Policy Expired”). The Image Manager /153
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Archive shall be triggered by this specific Key Object Selection instance to delete the expired
instances.
If the complete content of a series is deleted according to the specified behavior as describedabove, then the Image Manager / Archive may or may not also delete the series itself.
3930

If the Image Manager / Archive later receives the same expired instances that have beenpreviously deleted due to the expiry of data retention period and not other reasons, then it shallreceive the instances as defined in one of the corresponding instance stored transactions (RAD-8,
RAD-9, RAD-18, RAD-19, RAD-29, RAD-43, RAD-61).

4.68 Provide and Register Imaging Document Set – MTOM/XOP
3935

3940

This section corresponds to Transaction RAD-68 of the IHE Technical Framework. “Provide andRegister Imaging Document Set – MTOM/XOP” is used by the Imaging Document Source toprovide a set of XDS imaging documents to the Document Repository, and to request that therepository store these documents and then register them with the Document Registry. Thistransaction is derived from the Transaction ITI-41 of the IHE IT Infrastructure Technical
Framework. It adds new document content types as well as additional semantics and constraints
on the metadata defined in Transaction ITI-41.
4.68.1 Scope
The Provide and Register Imaging Document Set – MTOM/XOP transaction passes a Repository
Submission Request from an Imaging Document Source to a Document Repository.

3945

A Provider and Register Document Set – MTOM/XOP transaction carries:
•

3950

•
•
•
•

Metadata describing zero or more new documents (e.g., metadata describing zero
documents may be used to describe folders containing references to documents that werepreviously submitted)
Within metadata, one XDSDocumentEntry object per document
Submission Set definition along with the linkage to new documents and references toexisting documents
Zero or more XDS Folder definitions along with linkage to new or existing documents.
Zero or more documents

154
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.68.2 Use Case Roles
ImagingDocument
SourceDocument
Repository

Provide and Register
Imaging Document
Set – MTOM/XOP

3955
Actor: Imaging Document Source
Role: Submits document(s) with associated metadata to a Document Repository.
Actor: Document Repository
Role: receives documents and associated metadata and:
3960

•
•
•

Stores the documents
Augments submitted metadata with repository information to enable later retrieval of
documents
Forwards the enhanced metadata to the Document Registry.

4.68.3 Referenced Standards
3965

For a list of the standards inherited from the underlying ITI-41 Provide and Register Document
Set-b, see ITI TF-2b: 3.41.3.
In addition, the following standards are used to define the radiology-specific content:
DICOM 2011 PS 3.3: Key Object Selection Document (KOS)DICOM 2011 PS 3.16: Content Mapping Resource

3970

DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)
PDF/A ISO 19005-1. Document management - Electronic document file format for long-termpreservation - Part 1: Use of PDF (PDF/A)
HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)

3975

HL7 Implementation Guide for CDA® Release 2: Imaging Integration; Basic Imaging Reports in
CDA and DICOM; Diagnostic Imaging Reports (DIR) – Universal Realm, Release 1, March2009.
4.68.4 Interaction Diagram

155
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Imaging Document
SourceDocument
Repository

Provide and Register Imaging
Document Set – MTOM/XOP Request

Provide and Register Imaging
Document Set – MTOM/XOP Response

3980

4.68.4.1 Provide and Register Imaging Document Set – MTOM/XOP Request
message
An Imaging Document Source Actor sends documents and associated metadata to a Document
Repository Actor. This message is an extension of the Provide and Register Document Set-b
transaction as defined in ITI TF-2b: 3.41.

3985

4.68.4.1.1 Trigger Events
The triggers for this transaction are:
•
•

3990

The Imaging Document Source Actor is instructed to submit a set of one or more newimaging documents for sharing, orA previously submitted document or the contents of a previously submitted manifestchanges, requiring the Imaging Document Source to submit an update.

4.68.4.1.2 Message Semantics
This transaction extends the message semantics of the ITI-41 Provide and Register Document
Set-b by specifying additional document content types, to allow the sharing of the following
types of documents:
3995

1.

Sets of DICOM SOP instances

2.

Imaging diagnostic reports

To support these content types and their usage, additional requirements and constraints on the
XDS document metadata are specified.
4000

The Provide and Register Imaging Document Set – MTOM/XOP Request message semantics are
specified in the following subsections:1.

Sharing of Persistent DICOM Instances via a Manifest document

2.

Sharing of radiology diagnostic report in PDF or CDA Structured or CDA Wrapped
Text formats
156

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4005

4010

3.

XDS-I.b document metadata specification

4.

Use of XDS Submission Set concept in sharing of radiology imaging information.

The wsdl definition for this Provide-and-Register transaction sent by the Imaging Document
Source is no different than the Provide-and-Register transaction sent by the XDS.b Document
Source in ITI-41. The wsdl definition for the Provide-and-Register transaction can be found on
the IHE FTP server at:
ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/XDS.b_DocumentRepository.wsdl
4.68.4.1.2.1 Sharing of Set of DICOM Instances

4015

The Imaging Document Source creates a manifest that describes and collects references to
DICOM SOP instances that are intended for sharing. The manifest, a Key Object Selection(KOS) Document Instance, is the actual document provided to the Document Repository andregistered at the Document Registry.

4020

As specified in IHE ITI XDS.b Integration Profile, the structure of the message between theDocument Source and the Document Repository is an MTOM/ XOP formatted message. In thistransaction, the source actor is the Imaging Document Source, but the above requirement still
applies. The KOS Document Instance is encoded in the message as a DICOM Part 10 File format
having a MIME type of “application/dicom”.

4025

The Imaging Document Source shall ensure that the DICOM SOP Instances referenced fromwithin the manifest are available to be retrieved. If the Imaging Document Source makes one ormore SOP Instances unavailable that are referenced in a published manifest, then it shall submit
a new manifest as a replacement for the published manifest already in the Document Repository
and Document Registry (see IHE ITI TF-3:4.2.2.2 “Document Relationships”). The newmanifest shall have the updated list of DICOM SOP Instances with the unavailable instances
removed. If the Imaging Document Source makes all referenced DICOM SOP Instances
unavailable in a published manifest, then it shall deprecate the published manifest without any
replacement (IHE ITI XDS Metadata Update Supplement).

4030

4.68.4.1.2.1.1 Manifest KOS Document
The references to the DICOM SOP Instances shall be included in the Current Requested
Procedure Evidence Sequence (0040,A375) attribute of the KOS Manifest Document.

4035

The Imaging Document Source shall support a number of attributes in Current Requested
Procedure Evidence Sequence (0040,A375), which are represented in the Hierarchical SOP
Instance Reference Macro, as described in the following table:
Table 4.68.4.1.2.1-1: Attributes of Hierarchical SOP Instance Reference Macro in KOS
Manifest Document
Attribute Name

Tag

Imaging Document Source

Study Instance UID(0020,000D)

R

Referenced Series Sequence(0008,1115)

R> Series Instance UID(0020,000E)

R> Retrieve AE Title(0008,0054)

R+> Retrieve Location UID(0040,E011)

R+

157
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Attribute Name

4040

Tag

Imaging Document Source> Storage Media File-Set ID(0088,0130)

O> Storage Media File-Set UID(0088,0140)

O> Referenced SOP Sequence(0008,1199)

R>> Referenced SOP Class UID(0008,1150)

R>> Referenced SOP Instance UID(0008,1155)

R

Some of these requirements build on attributes which are Type 2 or Type 3 in DICOM (suchattributes are indicated with R+). Specifically, the Imaging Document Source shall include its
own identification in the Retrieve AE Title (0008,0054) and Retrieve Location UID (0040,E011)
attributes. These attributes will enable subsequent retrieval of the DICOM objects referenced
within the KOS manifest.
4.68.4.1.2.2 Sharing of Report

4045

4050

Since text reports address many of the weaknesses of PDF reports and vice versa, it is requiredthat the Imaging Document Source shall support shared reports in at least one of the following
three formats:•••

CDA Imaging Report with Structured Headings
CDA Wrapped Text Report
PDF Report

To maximize interoperability of the chosen formats:•For a PDF Report:
•

4055

•

4060
•

For a CDA Imaging Report with Structured Headings:• The CDA R2 Header and Body shall conform to the HL7 Clinical Document
Architecture Release 2.0. The report content shall be encoded in the StructuredBody
element and shall use Section elements identified with a code and there shall be no
nonXMLBody element. It is recommended that the CDA R2 Body also conform to
the “HL7 Standard for CDA® Release 2: Imaging Integration; Basic Imaging Reports
in CDA and DICOM, Release 1.
For a CDA Wrapped Text Report:•

4065

A specific PDF version is not specified, but use of PDF/A (ISO 19005-1) isrecommended.

The CDA R2 Header shall conform to the HL7 Clinical Document Architecture
Release 2.0. The CDA Body shall be text encoded with UTF-8 UNICODE format.
Refer to Section 4.68.4.1.2.3.5 for constraints on the CDA wrapper.

A report (no matter what document format is chosen) can be shared with or without image
reference(s).

158
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4070

If a shared report includes image reference(s), it can embed selected images in its PDF format or
it can include fully resolved hyperlinks that point to the selected images; these hyperlinks can beinteractively clickable (e.g., PDF) or can be processed or copied (e.g., text).
The Imaging Document Source that provides and registers the shared report is responsible forformatting the hyperlink to reference relevant images. The referenced images within a sharedimaging report are meant to be accessed without the need for specialized (e.g., DICOM) viewing
applications.

4075

The hyperlink that references the selected image shall be formatted as a DICOM WADO URI.
Since the sharing environment is inherently cross-enterprise, the secured version of HTTP (i.e.,
HTTPs) shall be used when formatting the hyperlink.
The Imaging Document Source is required to ensure that image references are valid links.

4080

Even though significant images can be shared as non-DICOM format (embedded picture in PDF
report or hyperlinks in PDF or Text report), it is required that sharing of a large set of DICOM
images be achieved by sharing a set of DICOM SOP instances by providing and registering amanifest document. This is to avoid registration of a large number of individual documents in the
XDS Document Registry.
4.68.4.1.2.3 Metadata

4085

The Provide and Register Imaging Document Set – MTOM/XOP Request message shall include
the metadata attributes that will be forwarded by the XDS Document Repository Actor to the
XDS Registry Actor using the Register Document Set-b Transaction (ITI-42).
The Imaging Document Source supplies all necessary registry object attributes of an
XDSDocumentEntry.

4090

4095

4100

4105

4.68.4.1.2.3.1 Metadata Attributes: Author Information and Document CreationTime
In XDS, a registered document directly contains the clinical information of interest for sharing.
Therefore, its metadata for registration can be populated directly from the document content. For
example, a discharge letter is submitted to the Document Repository, so its author and creation
information is populated into the XDS Document metadata.
In XDS-I.b, the Manifest document submitted to the Document Repository usually does notdirectly constitute clinical information of interest for sharing, but rather is a set of references tosuch clinical information. Thus, the metadata of the Manifest document shall be related to thereferenced source content or its creation process, to reflect the clinical nature of the shared
information. This affects the metadata attributes including, but not limited to, authorSpecialty,
authorInstitution, authorPerson, authorRole, creationTime, and title.
If the manifest references source data from multiple authors, then one primary author, source
data creation time and document title shall be chosen. Note that this metadata shall be populated
from the part of the source data that most closely represents the main content for sharing in order
to best support a user query to the Registry for finding this data. For example, a manifest
referencing a current report, a current study as well as a prior report and study, will register
metadata populated from the current report (which is the clinical content of interest for sharing).
159
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4110

In cases where the data to be shared is transformed from its original format (e.g., DICOM) toanother format (e.g., PDF) in advance of sending it to the Repository, the metadata of such newly
generated shared information shall be populated from the original source data (e.g., DICOM
data)
In summary, XDS-I.b metadata always reflects the main clinical content of a shared document,
which may be described directly in the document, or in the source data referenced within the
document, or in the source data from which the document is transformed.

4115

4.68.4.1.2.3.2 XDSDocumentEntry Metadata
Table 4.68.4.1.2.3-1 lists XDS document metadata elements that are either further constrained by
XDS-I.b, or have XDS-I.b specific instructions for how the Imaging Document Source is
expected to populate them. Unless otherwise specified, the “optionality” of the attributes listed in
the table below is the same as what is required by XDS for the source actor.

4120

For a full description of all the metadata attributes associated with an XDS document, see Table
4.2.3.2-1 “DocumentEntry Metadata Attribute Definition” in ITI TF-3: 4.2.3.2.
Table 4.68.4.1.2.3-1: XDS-I.b-specific Metadata Requirements
XDSDocumentEntry
Attribute

XDS-I.b-specific Requirements

creationTime

This attribute value shall be populated by the Imaging Document Source Actor to record thedate and time at which the clinical content conveyed in the shared document is created.
If the published document is a DICOM object or is transformed from a DICOM information
object, this attribute value should be taken from the tags Instance Creation Date
(0008,0012) and Instance Creation Time (0008,0013) of the DICOM object.

eventCodeList

This attribute is required to be included in the metadata if known by the Imaging Document
Source. In other words, it is “promoted” from an optional (O) attribute in XDS to a“required if known” (R2) attribute in XDS-I.b.
This attribute shall be populated by the Imaging Document Source to describe both theAcquisition Modality and Anatomic Region.
•
Acquisition Modality: The eventCodeList shall contain a code from the DICOM
Content Mapping Resource (PS3.16) Context Group CID 29 for each distinct
acquisition modality with which images were acquired in the study. In cases
where a study contains images from multiple acquisition modalities, multiple
codes shall be included in the eventCodeList.
Notes:The Imaging Document Source Actor needs to consider all series in the Submission
Set to determine the complete set of modality codes.
The Acquisition Modality (0008,0060) attribute for some objects in the study may
contain values that do not represent imaging modalities (e.g., SR, Presentation
States, Segmentations, etc.). There is no corresponding entry for these values in
CID 29 and these values shall not be represented in the eventCodeList.
•

Anatomic Region: the eventCodeList shall contain code(s) from the DICOM Content
Mapping Resource (PS3.16) Context Group CID 4.

For example, for a lung CT study which contains 3 CT acquisition series, one SR series, andone Segmentation series, will have a two entries in eventCodeList: a single entry for
Acquisition Modality using the code triplet “(CT, DCM, Computed Tomography) and an
entry for Anatomic Region using the code triplet; “(T-28000, SRT, Lung)”.

160
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
XDSDocumentEntry
Attribute

XDS-I.b-specific Requirements

eventCodeDisplayNameList

This attribute is required to be included in the metadata if the eventCodeList attribute ispresent.
This attribute contains the Code Meaning text(s) of the code(s) for Acquisition Modality
and for Anatomic Region valued in eventCodeList, from DCMR Context Group CID 29
and from DCMR Context Group CID 4, respectively. See DICOM 2011 PS 3.16 for
DICOM Context Group definitions.
Note that the ordering of the Code Meaning texts populated in this attribute shall be sorted
in the same order of the corresponding codes in eventCodeList.

formatCode

This attribute shall be populated by the Imaging Document Source as follows:•
Shall use “1.2.840.10008.5.1.4.1.1.88.59” (DICOM KOS SOP Class UID) as theFormat Code Value and “1.2.840.10008.2.6.1” (DICOM UID Registry UID) as theFormat Coding Scheme OID for a DICOM Manifest document.
•
Shall use “urn:ihe:rad:TEXT” for a CDA Wrapped Text Report•
Shall use “urn:ihe:rad:PDF” for a PDF Report•
Shall use “urn:ihe:rad:CDA:ImagingReportStructuredHeadings:2013” for a CDA
Imaging Report with Structured Headings unless overridden by a requirement in aContent Profile (such as IHE Cardiology CIRC or CRC).

mimeTypeThis attribute shall be populated by the Imaging Document Source from one of thefollowing values:•“application/dicom” for a DICOM Manifest document•“text/xml” for a CDA Wrapped Text Report•“text/xml” for a CDA Imaging Report with Structured Headings•“application/pdf” for a PDF ReportpracticeSettingCode

This attribute shall be populated by the Imaging Document Source describe the high-level
imaging specialty such as (R-3027B, SRT, “Radiology”), (R-3026B, SRT, “Pathology”), or(R-30248, SRT, “Cardiology”). The list of acceptable values is constrained by theorganization managing the XDS Registry (i.e., the XDS Affinity Domain).
It is strongly recommended to use the values from the DICOM Content Mapping Resource(PS3.16) Context Group CID 7030.

referenceIdList

This attribute shall be populated by the Imaging Document Source with the Accession
Number and assigning authority of the Order Filler for each Order associated with the
Imaging Document, if the Accession Number is known.
The format shall conform to the Data Type CXi where CXi.5 (Identifier Type Code) is
urn:ihe:iti:xds:2013:accession. The Data Types are specified in ITI TF 3: Table 4.2.3.1.7-2.
An Imaging Document may be referenced by multiple Accession Numbers, so this attribute
may contain multiple values, e.g., for images from a grouped acquisition or when images
are acquired and read in different facilities.
This is an additional slot not originally part of XDS. XDS Document Registries supporting
the Reference ID Option store this value. When the Reference ID Option is not declared by
the XDS Registry, then this extra metadata is handled according to the rules outlined in ITI
TF 3: 4.1.14 “Extra Metadata Elements”. Note that support for the Reference ID Option by
the XDS Registry is necessary to enable the Document Consumer to perform a successful
FindDocumentsByReferenceId Stored Query.
The Accession Number identifies the Imaging Service Request of the Originating HL7
Imaging Order Message (OMI) Imaging Procedure Control (IPC) Segment, Sequence 1 forAccession Identifier.
The CXi.1 component value may also be found in the DICOM attribute Accession Number(0008,0050) and the information to construct the CXi.4 component value may be found in
the DICOM attribute Issuer of Accession Number Sequence (0008,0051) in the top level

161
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
XDSDocumentEntry
Attribute

XDS-I.b-specific Requirements
DICOM Data Set when the instances have a single Accession Identifier, otherwise they may
be nested within items of the Request Attributes Sequence (0040,0275). See Section
4.68.4.1.2.3.3.7 for CXi Transformation of DICOM VR to XDS Data Types.
An example encoding two Accession Numbers in the referenceIdList is as follows:<rim:Slot name="urn:ihe:iti:xds:2013:referenceIdList "><rim:ValueList><rim:Value>642356235^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession</rim:Value><rim:Value>STN-238432^^^&1.2.3.4&ISO^^urn:ihe:iti:xds:2013:accession</rim:Value></rim:ValueList></rim:Slot>serviceStartTime

This attribute shall be populated by the Imaging Document Source for a date and time thatindicates the imaging service start time.
As an example, the Imaging Document Source could take the value of Study Date
(0008,0020) and Study Time (0008,0030) from the associated DICOM study

sourcePatientInfo

This attribute allows multiple values for different pieces of patient demographics, see
metadata specification of the IHE ITI XDS Integration Profile (Table 4.2.3.2-1 in ITI TF3:4.2.3.2).
As an example, this information can be transformed from DICOM Patient’s Name
(0010,0010), Patient’s Birth Date (0010,0030), and Patient’s Sex (0010,0040).

typeCodeThis attribute shall be populated by the source actor from a coding system of the Requested
Procedure Code of the Requested Procedure, to which the document is associated. In certain
special cases previously defined in other IHE Profiles some sort of user intervention will benecessary to select the single Procedure Code used to populate this attribute. For example,
handling the “Group Case” as defined in Scheduled Workflow will require the user to selecta single, pre-coordinated procedure code that represents the multiple Requested Proceduresthat were acquired as a single study.
The coding system of the Radiology Imaging Requested Procedure Code will be designatedby the XDS Affinity Domain and shared by all Imaging Document Sources in the XDS
Affinity Domain.

typeCodeDisplayName

This attribute shall be filled by the source actor using the code meaning text of thecorresponding Requested Procedure Code valued in typeCode.

uniqueId

This attribute shall contain the Document unique ID generated by the source actor. It shallbe an ISO OID.
For a DICOM Manifest document, this attribute value shall be the same as the SOP Instance
UID of the corresponding DICOM KOS object. In the event that any information in the
manifest changes and it needs to be resubmitted from the Imaging Document Source to theDocument Repository, the Imaging Document Source shall generate a new SOP Instance
UID for the DICOM KOS object to ensure that its submission to the Repository will
succeed.
For a CDA Imaging Report with Structured Headings or a CDA Wrapped Text Report, thisvalue shall be formulated from the HL7 CDA R2 header as follows:
ClinicalDocument/id@root.ClinicalDocument/id@extension

162
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4125

4130

4.68.4.1.2.3.3 Transformation of DICOM VR to XDS Document Metadata Data
Types
A number of XDS document metadata attributes use HL7 data types for value representation.
Some of the metadata attributes may be transformed from data elements of the corresponding
DICOM SOP Instance. In this section, transformations of DICOM VR (Value Representation) to
the HL7 data types used in XDS metadata are described.
Note that term HL7 Data Type in the following transformations refers to their specified usage in
XDS document metadata as defined in IHE ITI TF 3:4.2.3.1-7 “DataTypes ”.
4.68.4.1.2.3.3.1 CX – Extended Composite ID

4135

Table 4.68.4.1.2.3-2 describes the transformation of data element of DICOM VR to CX data typeas specified in IHE ITI TF-3:4.2.3.1.7 “Metadata Attribute Data Types”.:
Table 4.68.4.1.2.3-2: CX Data type mapping
CX DataComponent

Component NameDICOM VR

Comment

1

ID Number

LO

This attribute represent the value of Patient
ID issued by an Assigning Authority as
indicated in component 3. In DICOM, it isdata element (0010,0020) when used withsourcePatientId.

4.2

Assigning Authority –Universal ID

UTThis attribute represents the universal or
unique identifier for the Patient ID
Assigning Authority. In DICOM it is data
element of the Issuer of Patient ID
Qualifiers Sequence (0010,0024)>Universal Entity ID (0040,0032) whenused with sourcePatientId.
If this attribute is not present or the
Assigning Authority – Universal ID Typeis not ISO, then he Imaging Document
Source shall use its local configuration to
populate this subcomponent, to indicate thePatient ID Domain, from which the Patient
ID value in component 1 has been issued.
This component shall be an ISO OID

4.3

Assigning Authority –Universal ID TypeCSThis component represents the standard
defining the format of the Universal Entity
ID. In DICOM it is data element of theIssuer of Patient ID Qualifiers Sequence(0010,0024) >Universal Entity ID Type
(0040,0033).
If this attribute is not present or the
Assigning Authority – Universal ID Typeis not ISO, then the Imaging Document
Source shall use its local configuration to
populate this subcomponent, to indicate thePatient ID Domain, from which the Patient
ID value in component 1 has been issued.
This component shall be “ISO”

163
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
HL7 CX data components not listed in the table are not used in XDS document metadata andshall be left empty.
4140

4.68.4.1.2.3.3.2 DTM – Date / TimeHL7 DTM Data Type can be represented in the following regular expression:
YYYY[MM[DD[HH[MM[SS]]]]]
This can be transformed from DICOM elements of VR DA (format: YYYYMMDD) and TM(format: HHMMSS.fraction).

4145

4.68.4.1.2.3.3.3 XCN – Extended Composite ID Number and Name for Person
Table 4.68.4.1.2.3-3 describes the transformation of DICOM VR of PN to XCN data type as
specified in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-3: XCN Data type mapping
XCN Data
Component

4150

Component NameDICOM Data
Element

1

ID Number

2

Family Name

1st Component of PN

3

Given Name

2nd Component of
PN

4Second or Further Given
Names or Initials thereof

3rd Component ofPN

5Suffix5th Component of
PN

6Prefix4th Component ofPN

7

DegreeComment
The Imaging Document Source shall use its
local configuration or personnel directory
service to populate this component.
An example of transcoding a data elementof VR PN into XCN, is when (0008,1070)
Operator’s Name is used for authorPerson(0010,0010) for Patient Name

This attribute component is not included in
DICOM.

HL7 XCN data components not listed in the table are not used in XDS document metadata andshall be left empty.
4.68.4.1.2.3.3.4 XON – Extended Composite Name and Identification Number for
Organization

4155

Table 4.68.4.1.2.3-4 describes the transformation of DICOM Data Elements to XON data typeas specified in IHE XDS Integration Profile:
Table 4.68.4.1.2.3-4: XON Data type mapping
XON Data
Component
1

Component Name
Organization NameDICOM Data
Element
LO

Comment
Institution Name (0008,0080) or Institution
Code Sequence (0008,0082) >Code164
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Meaning (0008,0104)
If not populated, the Imaging Document
Source may use its local configuration to
populate this component.
6.2

Assigning Authority
Universal Id

6.3

Assigning Authority
Universal Id Type

10

Organization IdentifierSH

Institution Code Sequence (0008,0082)>Coding Scheme Designator (0008,0102)
This component shall be an ISO OID.
If not populated, the Imaging Document
Source may use its local configuration to
populate this component.
Shall have the value “ISO” if XON.6.2 hasa valueSH

Institution Code Sequence (0008,0082)>Code Value (0008,0104)
The Imaging Document Source may use its
local configuration to populate thiscomponent.

HL7 XON data components not listed in the table are not used in XDS document metadata andshall be left empty.
4160

4.68.4.1.2.3.3.5 CXi – Extended Composite ID of a Reference Object for Accession
NumberTable 4.68.4.1.2.3-5 describes the transformation of data element of DICOM VR to CXi data
type as specified in IHE ITI TF 3:4.1.7 “Document Definition Metatdata” Table 4.2.3.1.7-2“Data Types”.

4165
Table 4.68.4.1.2.3-5: CX Data type mapping
CXi Data
Component

Component NameDICOM VR

Comment

1

ID NumberLO

Accession Number (0008,0050).
For a grouped acquisition study, this field
will be empty in the top level DataSet, but
may be obtained from within Request
Attributes Sequence (0040,0275
For an unscheduled acquisition study, thisfield may be empty in the top level DataSet
and Request Attributes Sequence(0040,0275) may be empty or absent. The
Imaging Document Source will not
populate this field if no Accession Number
has been issued.
For an acquisition study with an Accession
Number which no Assigning Authority –Universal ID in subcomponent 4.2, this slot
will not be filled in
The Imaging Document Source will not
populate this slot if a qualified Accession
Number has not been issued.

4.2

Assigning Authority –UTIssuer of Accession Number Sequence

165
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________CXi Data
Component

Component NameDICOM VR

Universal ID

Comment(0008,0051) >Universal Entity ID(0040,0032).
If this attribute is not present or the
Assigning Authority – Universal ID Typeis not ISO, then the Imaging Document
Source shall use its local configuration to
populate this subcomponent, to indicate theAssigning Authority, from which theAccession Number value in component 1
has been issued.
This component shall be an ISO OID.

4.3

Assigning Authority –Universal ID Type

6

homeCommunityId

CS

Issuer of Accession Number Sequence(0008,0051) >Universal Entity ID Type
(0040,0033).
If this attribute is not present or the
Assigning Authority – Universal ID Typeis not ISO, then the Imaging Document
Source must use its local configuration to
populate this subcomponent, to indicate
the Assigning Authority, from which theAccession Number value in component 1
has been issued
This component shall be “ISO”
Not present in DICOM.
May be omitted, or the Imaging Document
Source may use its local configuration to
populate this component.

HL7 CX data components not listed in the table are not used in XDS document metadata andshall be left empty.
4.68.4.1.2.3.4 XDS/XDS-I.b Metadata Values represented as HL7 v2.5 Data Types
4170

4175

XDS/ XDS-I.b Metadata that is represented as an HL7 v2.5 data type will require transformationfrom its corresponding HL7 CDA R2 header component. The following table (4.68.4.1.2.3-6)
guides this transformation and indirectly imposes requirements on the configuration of and/or
user interaction with implementations supporting this transaction. Additionally, this table further
restricts the HL7 CDA R2 specification. IDs in metadata that correspond to IDs in the CDA
header (as II types) are required to have both a root and an extension attribute.
Table 4.68.4.1.2.3-6: HL7 v2.5 and CDA Data type mapping
XDS/ XDS-I.b Metadata
HL7
v2.5
Data
Type

Subcomponent
index

HL7 CDA Header

Subcomponent
name

CX
(SEE
NOTE 1)HL7 CDAR2 Dataelement

HL7 CDA R2 Sub-element or
attribute

II

166
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
XDS/ XDS-I.b Metadata
HL7
v2.5
Data
Type

HL7 CDA Header

Subcomponent
index

Subcomponent
name

HL7 CDAR2 Dataelement

1

Id number

II@extension

4.2

AssigningAuthority.
uid

II

@root

CXi
(SEE
NOTE 1)DTM

HL7 CDA R2 Sub-element or
attributeII1

Id number

II@extension

4.2

AssigningAuthority.
uid

II

@root

1 (only)

Date/TimeTS or
IVL_TS@value(NOTE: format is compatible with DTM)

XCN

II and PN
1

Id number

II@extension

2.1

FamilyName.surnName

PN

Family3

Given Name

PN

Given

4

Second (middle)
Name

PN

Given

5

SuffixPN

Suffix6

PrefixPN

Prefix9.2

AssigningAuthority.
uid

II

@root

XON

II and ON
1

Organization Name

3

Id number

II@extension

5.1

AssigningAuthority.
namespaceII@assigningAuthorityName

5.2

AssigningAuthority.
uid

II

@root

Note 1: XDS restricts the formatting of the CX and CXi datatype. See ITI TF-3:Table 4.2.3.1.7-2.

4180

4.68.4.1.2.3.5 CDA Wrapper – CDA Wrapped Text Report Option

4185This section outlines the content of the HL7 CDA R2 wrapper for the text content. We note herethat requirements specified below are to ensure the presence of a minimum amount of wrapper
data in order to enhance description and facilitate sharing of the document. It should be notedthat the "nullFlavor" value expresses missing values in the CDA, e.g., it may be appropriate if
such information cannot be derived from DICOM objects.

167
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Implementers of the “CDA Wrapped Text Report” Profile Option can and should make use ofadditional annotation within the CDA header to provide richer context. The examples in thefollowing sections contain the minimal amount of wrapper data, as specified, and in many cases
do make use of additional CDA header elements for enriched context.
4190

4195

To the extent possible, the specification for the CDA wrapper for the report text has been madeconsistent with the CDA metadata specified in the ITI XDS Scanned Documents (XDS-SD)
Profile (see ITI TF-3: 5.2.2 and 5.2.3) and has been replicated here for the readers’ convenience.
Elements and attributes that apply to the XDS-SD use case(s) but not to the use case of sharing
an electronically transmitted radiology report have been omitted, where allowed by the CDA R2
specification. Descriptions for how to populate certain elements and attributes consistent with the“sharing a text-based radiology report” use case have been included.
4.68.4.1.2.3.5.1 Wrapper Format – HL7 CDA R24200

The CDA metadata wrapper for plain text reports is the same as defined in the ITI XDS-SD
Profile (see the metadata specification Table in ITI TF-3: 5.2.3) with the exceptions described
below and in the following subsections:•

The ClinicalDocument/dataEnterer element, as it is defined in XDS-SD, does not apply tothe report sharing use case and thus may be omitted.

4.68.4.1.2.3.5.1.1 ClinicalDocument Child-less Elements
4205

The requirements for the ClinicalDocument Child-less elements for CDA-wrapped plain text
reports is the same as defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.1), with thefollowing exceptions/ clarifications:
•
•

•
•
•
•

4210

•
4215

The ClinicalDocument/templateId element shall be 1.3.6.1.4.1.19376.1.2.21
The ClinicalDocument/code element shall be set with the following attribute values:
code=“11528-7”
codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC”
displayName=“Radiology Report”/>

The ClinicalDocument/effectiveTime shall denote the time at which the CDA text
document was recorded. At a minimum, the time shall be precise to the day and shall
include the time zone offset from GMT.

168
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Example:<ClinicalDocument xmlns=“urn:hl7-org:v3”><typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/><templateId root=”1.3.6.1.4.1.19376.1.2.21”><id root=“1.3.6.4.1.4.1.2835.2.7777”/><code code=“11528-7” codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC” displayName=“Radiology Report”/><title>Chest X-Ray</title><effectiveTime value=“20050329224411+0500”/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code=“en-US”/>

4.68.4.1.2.3.5.1.2 ClinicalDocument/recordTarget
4220

The requirements and example for the ClinicalDocument/recordTarget element for CDAwrapped plain text reports is the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.2).
4.68.4.1.2.3.5.1.3 ClinicalDocument/author (original)

4225

The requirements and example for the ClinicalDocument/author element (that represents theoriginal author of the report) for CDA-wrapped plain text reports is the same as defined in the
ITI XDS-SD Profile (see ITI TF-3: 5.2.3.3).
4.68.4.1.2.3.5.1.4 ClinicalDocument/author (reporting system)

4230

The requirements for the ClinicalDocument/author element (that represents the reporting systemand software used to produce the report content) for CDA-wrapped plain text reports is the sameas defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.4), with the following exceptions/clarifications:
•
•

4235

When reading the XDS-SD specification, references to scanned, scanning, scanned
content etc. refer to reporting, report content etc. in this context.
When reading the XDS-SD specification concerning theClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code element
references to CDA-wrapped PDF can be ignored since they do not apply to the radiology
report sharing use case.

169
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Example:<author><time value=“20050329224411+0500”/><assignedAuthor><templateId root=”1.3.6.1.4.1.19376.1.2.20.2”/><id root=“1.3.6.4.1.4.1.2835.2.1234”/><assignedAuthoringDevice><code code=“WSD” displayName=“Workstation” codeSystem=“
1.2.840.10008.2.16.4” /><manufacturerModelName>SOME REPORTING NAME AND MODEL</manufacturerModelName><softwareName> REPORTING SOFTWARE NAME v0.0</softwareName></assignedAuthoringDevice><representedOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME REPORTING Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country></addr></representedOrganization></assignedAuthor></author>

4240
4.68.4.1.2.3.5.1.5 ClinicalDocument/custodian

4245

The requirements and example for the ClinicalDocument/custodian element for CDA-wrappedplain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3: 5.2.3.6). Its
context is left up to the reporting facility to define in accordance with local policies and to reflect
the entity responsible for the report content. In most cases this will be the reporting facility.
4.68.4.1.2.3.5.1.6 ClinicalDocument/legalAuthenticator

4250

The requirements and example for the ClinicalDocument/legalAuthenticator element for CDAwrapped plain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.7) and its context is left up to the reporting facility to define in accordance with local
policies.
4.68.4.1.2.3.5.1.7 ClinicalDocument/documentationOf
The requirements and example for the ClinicalDocument/documentationOf element for CDAwrapped plain text reports are the same as defined in the ITI XDS-SD Profile (see ITI TF-3:
5.2.3.8).

170
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4255

4.68.4.1.2.3.5.1.8 ClinicalDocument/component/nonXMLBody
This ClinicalDocument/component/nonXMLBody element shall be present and used to wrap thetext content. The requirements for the nonXMLBody are the same as defined in the ITI XDS-SD
Profile (see ITI TF-3: 5.2.3.9), with the following exceptions/ clarifications:
•

4260
•
•
4265

4270

When reading the XDS-SD specification, references to scanned, scanning, scanned
content etc. refer to reporting, report content etc. in this context.
When reading the XDS-SD specification concerning theClinicalDocument/component/nonXMLBody element, references to CDA-wrapped PDF
can be ignored since they do not apply to the radiology report sharing use case.
The XDS-SD specification requires Base 64 encoding for the value of theClinicalDocument/component/nonXMLBody/text element, even if the unencoded text
consists of characters that can be encoded legally within XML (i.e.,
ClinicalDocument/component/nonXMLBody/text@representation is required to be"B64" rather than "TXT"); currently, this XDS-SD requirement is not overridden, though
it contrasts with the use of unencoded text in the CDA Imaging Report with Structured
Headings Option, in which text occurs in various structured elements (e.g.,
component/TextObservation/text), rather than in a nonXMLBody element.

Example (report text content is in the same language as the wrapper):<component><nonXMLBody><text mediaType=“text/plain” representation=“B64”>
UmFkaW9sb2d5IFJlcG9ydCBmb3IgSmFuZSBEb2UKQ29uY2x1c2lvbjogTm9ybWFsLgo=</text></nonXMLBody></component></ClinicalDocument>

4275

4.68.4.1.2.4 Use of XDS Submission Set
4.68.4.1.2.4.1 Linking Report to Set of DICOM Instances
Figure 4.68.4.1.2.4-1 shows examples of three Submission Sets:
•

4280
•

4285

•

Submission Set 1 includes a report and a manifest that are stored in the Document
Repository. The manifest references DICOM instances that are archived in the IM/IA.
The referenceIdList for the manifest and the report includes the same fully qualified
Accession Number associated with the originating Requested Procedure for the prior.
Submission Set 2 includes one single manifest. The referenceIdList for the manifest
includes the fully qualified Accession Number associated with the originating Requested
Procedure for the current study.
Submission Set 3 includes a report and references the manifest from Submission Set 2
metadata. The referenceIdList for the report includes the fully qualified Accession
Number associated with the originating Requested Procedure for the current study, since
it was generated by interpreting the images referenced by the manifest in Submission Set
171

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4290

2 metadata. Submission Set 3 also references the report and the manifest from
Submission Set 1 since that report and images that are referenced by that manifest wereused for the interpretation.
PRIOR

CURRENT
Submission
Set 2

XDS

Submission
Set 1

Submission
Set 3

Optional References

Imaging
ManifestDocument 2

Imaging
ManifestDocument 1

Radiology
Diagnostic
Report 2

DICOM

Radiology
Diagnostic
Report 1

Images and Evidence
Documents Referenced in
Manifest

Images and Evidence
Documents Referenced in
Manifest

Figure 4.68.4.1.2.4-1: Imaging Information Sharing Submission Set

4295

If the submitted reports and an image manifests are for the same Requested Procedure, then themetadata for the report and the Image Manifest may include the same fully qualified Accession
Number in the referenceIdList. This will enable the unambiguous association of reports to the setof DICOM instances related to the Requested Procedure.
4.68.4.1.2.4.2 Linking Report to prior report

4300

The Report Submission Set can reference the manifest for a set of prior images published if theprior images were used in creating the interpretation. Likewise the report submission set canreference a report from a previous submission. The Accession Number(s) of the prior images andreports will be different from the Accession Number(s) for the current images and reports.
4.68.4.1.3 Expected Actions

4305

The Document Repository Actor will receive this message and will process it according to therequirements specified in ITI TF-2b: 3.41.4.1.3.
4.68.4.2 Provide and Register Imaging Document Set – MTOM/XOP Response
message
The Document Repository sends a Provide and Register Imaging Document Set – MTOM/XOP
Response message when the processing of a Provide and Register Imaging Document Set –172
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4310

4315

MTOM/XOP Request message is complete. The specification of the trigger events, message
semantics and expected actions are the same as those specified in ITI TF-2b: 3.41.4.2.
The conditions of failure and possible error messages are given in the ebRS standard. The
Imaging Document Source shall handle all error messages detailed for the Provide and Registertransaction in ITI TF-3: Table 4.22.4.2-1 “[ITI-42] Provide and Register Document Set-b
Responses”.

4.69 Retrieve Imaging Document Set
This section corresponds to Transaction RAD-69 of the IHE Technical Framework. “Retrieve
Imaging Document Set” is used by:
4320

4325

•
•
•

an XDS-I.b Imaging Document Consumer to retrieve from an Imaging Document Source
an XCA-I Imaging Document Consumer to retrieve from an Initiating Imaging Gateway
an XCA-I Responding Imaging Gateway to retrieve from an Imaging Document Source

The objects retrieved are those that are referenced within an XDS-I.b manifest document as
described in RAD TF-3: 4.68. This transaction is derived from, and is nearly identical to, the“Retrieve Document Set” Transaction (ITI-43) of the IHE IT Infrastructure Technical
Framework. It adds minor additional semantics and constraints on the requirements defined inTransaction ITI-43.
4.69.1 Scope

4330

4335

This transaction is used by the Imaging Document Consumer to retrieve a set of DICOM objects
from the Imaging Document Source or an Initiating Imaging Gateway. This transaction is also
used by a Responding Imaging Gateway to retrieve a set of DICOM objects from an Imaging
Document Source in its own community.
The Imaging Document Consumer gains access to the manifest object (KOS) previously
retrieved from the Document Repository by the grouped Document Consumer Actor via the
Retrieve Document Set transaction. The Imaging Document Consumer extracts the
XDSDocumentEntry.uniqueId and a repositoryUniqueId associated with the Imaging Document
Source from the manifest (KOS) object for use in creating the retrieval request.

173
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.69.2 Use Case Roles

ImagingDocument
SourceInitiating
Imaging
Gateway

Imaging Document
Consumer

Responding
Imaging
Gateway

Retrieve Imaging
Document Set

Actor: Imaging Document Consumer
4340

Role: Issues a web service request to retrieve a set of DICOM instances from an Imaging
Document Source or from remote communities through an Initiating Imaging Gateway.
Actor: Responding Imaging Gateway
Role: Issues a web service request to retrieve a set of DICOM instances from an Imaging
Document Source.

4345

Actor: Imaging Document Source
Role: Receives a web service request from an Imaging Document Consumer or Responding
Imaging Gateway for retrieval of a set of DICOM instances and generates the web service
response with the appropriate content.
Actor: Initiating Imaging Gateway

4350

Role: Receives a web service request from an Imaging Document Consumer for retrieval of a setof DICOM instances and generates the web service response with the appropriate content.
4.69.3 Referenced Standards
For a list of the standards inherited from the underlying ITI-43 Retrieve Document Set, see ITI
TF-2b: 3.43.3.

174
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4355

4.69.4 Interaction Diagrams
Imaging Document
Consumer

Imaging Document
Source or Initiating
Imaging Gateway

Retrieve Imaging Document Set
RequestRetrieve Imaging Document Set
Response

Responding Imaging
Gateway

Imaging Document
SourceRetrieve Imaging Document Set
RequestRetrieve Imaging Document Set
Response

4.69.4.1 Retrieve Imaging Document Set Request message
4360

This message is an extension of the Retrieve Document Set transaction as defined in ITI TF-2b:
3.43.
•
•

4365

•

In XDS-I.b, an Imaging Document Consumer sends a request to an Imaging Document
Source to retrieve the set of images referenced within a manifest object.
In XCA-I, an Imaging Document Consumer sends a request to an Initiating Imaging
Gateway to retrieve the set of images referenced within a manifest object.
In XCA-I, a Responding Imaging Gateway sends a request to an Imaging Document
Source in the responding community to retrieve the set of images referenced within amanifest object.

4.69.4.1.1 Trigger Events
4370

The Imaging Document Consumer wishes to retrieve a set of DICOM instances that arereferenced within a DICOM Manifest. The Imaging Document Consumer obtains the
documents’ uniqueIds (i.e., the SOP Instance UIDs referenced within the DICOM manifest)
175
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4375

along with the associated study and series instance UIDs. The Imaging Document Consumer will
either compute the repositoryUniqueId(s) from the Retrieve AE Title attribute(s) within the
DICOM manifest or populate the repositoryUniqueId(s) using the Retrieve Location UID
attribute(s) within the DICOM manifest. The Imaging Document Consumer also maps therepositoryUniqueId(s) to web services endpoint(s) which are the targets of the message.
The Imaging Document Consumer obtains the homeCommunityID for the Imaging Document
Source from the Registry Stored Query response.

4380

Once the documents’ homeCommunityIDs, uniqueIds and repositoryUniqueId(s) have beenobtained, the Imaging Document Consumer will send the Retrieve Imaging Document Set
Request to the Imaging Document Source.
In response to the Cross Gateway Retrieve Imaging Document Set [RAD-75], the Responding
Imaging Gateway initiates a Retrieve Imaging Document Set request to the Imaging Document
Source in the responding community.

4385

4.69.4.1.2 Message Semantics
The Retrieve Imaging Document Set Request shall carry the following information:
•

4390
•
4395
•
•
4400
•
•
4405

A required repositoryUniqueId that identifies the Imaging Document Source from which
the DICOM instance is to be retrieved. This value shall either be “computed” based on
the Retrieve AE Title (0008, 0054) attribute(s) present in the DICOM manifest or be
populated from the Retrieve Location UID (0040,E011) attribute(s) that is present in the
DICOM manifest. For a description of how this “computation” can be achieved, see IHE
RAD TF-3: Appendix G.3.
A required list of one or more documentUniqueIds that identify the documents within the
Imaging Document Source. These values correspond to the SOP Instance UIDs
referenced within the DICOM manifest.
A required list of one or more DICOM transfer syntax UIDs that the Imaging Document
Consumer is capable of processing.
A required Study Instance UID value that identifies the study containing the DICOM
images/ objects to be retrieved. The Study Instance UID is extracted from the KOS
manifest.
A required Series Instance UID value that identifies the series containing the DICOM
images/ objects to be retrieved. The Series Instance UID is extracted from the KOS
manifest.
A homeCommunityID, required if:• the Retrieve Imaging Document Set request is to an Initiating Imaging Gateway.

the Retrieve Imaging Document Set request is from a Responding Imaging Gateway to a
Imaging Document Source.
The message shall be structured as described in Section 4.69.5 Protocol Requirements.
4.69.4.1.3 Expected Actions
4410

When receiving a Retrieve Imaging Document Set Request, an Imaging Document Source orInitiating Imaging Gateway shall generate a Retrieve Imaging Document Set Response.
176
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________4415

In XCA-I, an Initiating Imaging Gateway initiates a Cross Gateway Retrieve Imaging Document
request to all Responding Imaging Gateways that can satisfy the request, to obtain theinformation from responding communities in order to construct the Retrieve Imaging Document
Set Response.
4.69.4.2 Retrieve Imaging Document Set Response message
4.69.4.2.1 Trigger Events
This message will be triggered by receipt of a Retrieve Imaging Document Set Request Message.
4.69.4.2.2 Message Semantics

4420

The semantics of the Retrieve Imaging Document Set Response Message are identical to thoseinherited from the ITI-43 transaction and are specified in ITI TF-2b: 3.43.4.2.2.
4.69.4.2.3 Expected Actions

4425

4430

An Imaging Document Source or Initiating Imaging Gateway shall provide the Imaging
Document Set(s) indicated in the request. The Imaging Document Source or Initiating Imaging
Gateway shall return the imaging document(s) or an error code in case the document could not
be returned. The pixel data shall be encoded using one of the DICOM transfer syntaxes includedin the Retrieve Imaging Document Set Request Message. If the Imaging Document Sourcecannot encode the pixel data using any of the requested transfer syntaxes then an error status
shall be returned.
If the Imaging Document Consumer or Responding Imaging Gateway specifies a transfer syntax
field of 1.2.840.10008.1.2.4.94 (DICOM JPIP Referenced Transfer Syntax) or
1.2.840.10008.1.2.4.95 (DICOM JPIP Referenced Deflate Transfer Syntax), and the Imaging
Document Source supports the requested transfer syntax, the following behavior is expected:
•

4435
•

4440
•
4445
•

If the DICOM Image Object(s) already have the same JPIP transfer syntax as the one
indicated in the request, the Retrieve Imaging Document Set Response shall include the
DICOM Image Objects unchanged.
If the DICOM Image Object(s) have a transfer syntax that differs from that of the request,
the Retrieve Imaging Document Set Response shall include the DICOM image with thetransfer syntax changed to the requested transfer syntax. In addition, the pixel data
Attribute (7Fe0,0010 tag) will have been removed and replaced with a Pixel Data
Provider URL (0028,7FE0 tag). The URL represents the JPIP request and will include thespecific target information.
Upon receipt of this Retrieve Imaging Document Set Response, the Imaging Document
Consumer may request the pixel data from the pixel data provider using the supplied
URL. Additional parameters required by the application may be appended to the URL
when accessing the pixel data provider.
For example, a JPIP request for a 200 by 200 pixel rendition of the entire image can beconstructed from the Pixel Data Provider URL as follows:•

4450

Pixel Data Provider URL (0028,7FE0) =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2,
177

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•URL Generated by the application =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,2004455

The conditions of failure and possible error messages are given in the ebRS standard and detailedin ITI TF-3: Table 4.2.4.2-4 “[ITI-43] Retrieve Document Set and [ITI-39] Cross Gateway
Retrieve Responses”.

4460

In XCA-I, the Initiating Imaging Gateway can act as a JPIP proxy and accept the JPIP requestfrom the Imaging Document Consumer and make the corresponding request to the Imaging
Document Source. If a direct route is available from the Imaging Document Consumer to the
Imaging Document Source, the Imaging Document Consumer is allowed to make a direct JPIP
request to the Imaging Document Source, assuming security considerations are observed.
4.69.4.3 Asynchronous Web Services Exchange Method
An Image Document Consumer that supports the Asynchronous Web Services Option shall use
the Asynchronous Web Services Exchange method if the Initiating Imaging Gateway also
supports the Asynchronous Web Services Option.

4465

The Initiating Imaging Gateway that supports the Asynchronous Web Services Option, shall
respond to an Image Document Consumer using the use the Asynchronous Web Services
Exchange method.
A Responding Imaging Gateway shall use the Asynchronous Web Services Exchange method if
the Image Document Source supports the Asynchronous Web Services Option.

4470

The Image Document Source that supports the Asynchronous Web Services Option, shall
respond to an Image Document Consumer using the Asynchronous Web Services Exchange
method.
The Image Document Consumer or the Responding Imaging Gateway supporting this method
shall use the non-anonymous response EPR in the WS-Addressing replyTo header.

4475

The Initiating Imaging Gateway, Responding Imaging Gateway, the Image Document Source
and the Image Document Consumer shall support the Asynchronous Web Services Methods in
the ITI TF-2x: Appendix V.5: Web Services for IHE Transactions, which also includes
additional considerations for implementers.
4.69.5 Protocol Requirements

4480

Implementers of this transaction shall comply with all requirements described in ITI TF-2x:
Appendix V: Web Services for IHE Transactions.
The Retrieve Imaging Document Set transaction shall use SOAP12 and MTOM with XOP
encoding (labeled MTOM/XOP in this specification). See ITI TF-2x: Appendix V for details.
The Imaging Document Source or Initiating Imaging Gateway shall:

4485

•
•

Accept the Retrieve Imaging Document Set Request message in MTOM/XOP format.
Generate the Retrieve Imaging Document Set Response message in MTOM/XOP format

The Imaging Document Consumer shall:•

Generate the Retrieve Imaging Document Set Request message in MTOM/XOP format.
178

Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•

Accept the Retrieve Imaging Document Set Response message in MTOM/XOP format.

4490
WSDL Namespace Definitions
iheradurn:ihe:rad:xdsi-b:2009

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

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

lcm

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

query

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

These are the requirements for the Retrieve Imaging Document Set transaction presented in theorder in which they would appear in the WSDL definition:•

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

4495

•

namespace="urn:ihe:rad:xdsi-b:2009", schema="
XDSI.b_ImagingDocumentSource.xsd"
The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema=”
XDS.b_DocumentRepository.xsd”)

•

4500

4505

4510

4515

The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
Request message shall be defined as “iherad:RetrieveImagingDocumentSetRequest”• The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
Response message shall be defined as “ihe:RetrieveDocumentSetResponse”• The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve
Imaging Document Set Request message shall be defined as“urn:ihe:rad:2009:RetrieveImagingDocumentSet”
The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Imaging
Document Set Response message shall be defined as“urn:ihe:iti:2007:RetrieveDocumentSetResponse”
These are the requirements that affect the wire format of the SOAP message. The other WSDL
properties are only used within the WSDL definition and do not affect interoperability. Fullsample request and response messages are in Section 4.69.5.1 Sample SOAP Messages.
For informative WSDL for the Imaging Document Source and Responding Imaging Gateway
Actor see example on the IHE FTP server at:
ftp://ftp.ihe.net/TF_Implementation_Material/RAD.
The <iherad:RetrieveImagingDocumentSetRequest/> element for use with the Retrieve Imaging
Document Set Request Message is defined as:•

4520

One or more <iherad:StudyRequest/> elements each of which includes a“studyInstanceUID” attribute identifying the study associated with the DICOM images/
objects being retrieved. Each <iherad:StudyRequest/> element shall contain:

179
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•

One or more <iherad:SeriesRequest/> elements each of which includes a“seriesInstanceUID” attribute identifying the series associated with the DICOM
images/ objects being retrieved. Each <iherad:SeriesRequest/> element shall contain:
•

4525
•
4530
•
•
4535

•
4540

One or more <ihe:DocumentRequest/> elements, each one representing an
individual document that the Imaging Document Consumer or Responding
Imaging Gateway wants to retrieve from the Imaging Document Source. Each<ihe:DocumentRequest/> element contains:
A required <ihe:RepositoryUniqueId/> element that identifies the Imaging
Document Source from which the document is to be retrieved. This value
corresponds to XDSDocumentEntry.repositoryUniqueId.
A required <ihe:DocumentUniqueId/> element that identifies the document
within the Imaging Document Source. This value corresponds to the SOP Instance
UID referenced within the DICOM manifest.
A conditionally required <ihe:HomeCommunityId/> element that corresponds tothe home attribute of the Identifiable class in ebRIM. The element shall be
populated if the request is to an Initiating Imaging Gateway. Otherwise, it may beabsent.

A required <iherad:TransferSyntaxUIDList/> element which contains a list of one ormore <ihe:TransferSyntaxUID> elements. Each of the <iherad:TransferSyntaxUID>
elements represent one of the transfer syntax encodings that the Imaging Document
Consumer is capable of processing.

This allows the Imaging Document Consumer to specify one or more documents to retrieve fromthe Imaging Document Source or Initiating Imaging Gateway.
4545

The <ihe:RetrieveDocumentResponse/> element for use with the Retrieve Imaging Document
Set Response Message is defined as:••

A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
A conditionally required sequence, if a matching document exists with
<ihe:DocumentResponse/> elements containing
•

4550

4555

4560

•

A conditionally required <ihe:HomeCommunityId/> element. The value of thiselement shall be the same as the value of the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Retrieve Document Set Request Message. If the<ihe:HomeCommunityId/> element is not present in the Retrieve Document Set
Request Message, this value shall not be present.
A required <ihe:RepositoryUniqueId/> that identifies the Imaging Document Sourcefrom which the document is to be retrieved. The value of this element shall be thesame as the value of the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/RepositoryUniqueId element in the original Retrieve Imaging Document Set
Request Message. This value corresponds to RetrieveLocation UID in the DICOM
manifest.

180
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
•

4565

•
4570
•

A required <ihe:DocumentUniqueId/> that identifies the document within the
Imaging Document Source. The value of this element shall be the same as the valueof the/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/DocumentUniqueId element in the original Retrieve Imaging Document Set
Request Message. This value corresponds to the SOP Instance UID referenced within
the DICOM manifest.
A required <ihe:Document/> element that contains the retrieved document as an XOP
Infoset.
A required <ihe:mimeType/> element that indicates the MIME type of the retrieved
document

The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall
status of the request: It shall contain one of the following values:4575

urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

See ITI TF-3:Table 4.2.4.2-4 “[ITI-43] Retrieve Document Set and [ITI-39] Cross Gateway
Retrieve Responses” for the interpretation of these values.
4580

For each document requested in a
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:
•

•
•
•
•

4585

•
4590
•

•

@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning@errorCode is specified@codeContext contains the warning message@location contains the DocumentUniqueId of the document requested

The document shall be returned in an instance of/RetrieveDocumentSetResponse/DocumentResponse/Document as an XOP Infoset. The
returned document and warning are correlated via the DocumentUniqueId.
If an error is reported when retrieving a document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:
•
•
•
•

4595

4600

If a warning is reported when retrieving the document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error@errorCode is specified@codeContext contains the error message@location contains the DocumentUniqueId of the document requested

No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned

181
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•

4605

If the document is successfully retrieved (without warning) then no/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be present and a/RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned
containing the document as an XOP Infoset.

The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not
used in this transaction.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in thistransaction.
4610

A full XML Schema Document for the XDS.b and XDS-I.b types is available online on the IHE
FTP site at: ftp://ftp.ihe.net/TF_Implementation_Material/RAD (for XDS-I.b) and
ftp://ftp.ihe.net/TF_Implementation_Material/ITI (for XDS.b).
4.69.5.1 Sample SOAP Messages

4615

4620

The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
IHE ITI TF-2x: Appendix V: Web Services for IHE Transactions. The body of the SOAP
message is omitted for brevity; in a real scenario the empty element will be populated with theappropriate metadata.
Samples presented in this section are also available online on the IHE FTP site, see
ftp://ftp.ihe.net/TF_Implementation_Material/RAD.
4.69.5.1.1 Sample Retrieve Imaging Document Set SOAP Request

4625

4630

4635

4640

4645

4650

4.69.5.1.1.1 Synchronous Web Services Exchange<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:rad:2009:RetrieveImagingDocumentSet </a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo s:mustUnderstand="1"><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To >http://localhost:2647/XdsService/IHEXDSIDocSource.svc</a:To></s:Header><s:Body><RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"><SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest>

182
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4655</StudyRequest><TransferSyntaxUIDList><TransferSyntaxUID> 1.2.840.10008.1.2.1</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.57</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList></RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4660

4.69.5.1.1.2 Asynchronous Web Services Exchange

4665

4670

4675

4680

4685

4690

4695

<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:rad:2009:RetrieveImagingDocumentSet</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo s:mustUnderstand="1"><a:Address>http://192.168.2.4:9080/XcaService/ImagingDocumentConsumer.svc</a:ReplyTo><a:To >http://localhost:2647/XdsService/IHEXDSIDocSource.svc</a:To></s:Header><s:Body><RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"><SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest></StudyRequest><TransferSyntaxUIDList><TransferSyntaxUID> 1.2.840.10008.1.2.1</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.57</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList></RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.69.5.1.2 Sample Retrieve Document Set SOAP Response
4.69.5.1.2.1 Synchronous Web Services Exchange
4700

4705

4710

4715

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId>

183
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

4720

4725

<mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>

4.69.5.1.2.2 Asynchronous Web Services Exchange
4730

4735

4740

4745

4750

4755

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body></s:Envelope>4.70 – 4.73 Temporarily, intentionally, left blank
4.74 Replacement Instances Stored
4760

This section corresponds to Transaction 74 of the IHE Radiology Technical Framework.
Transaction 74 is used by the Change Requester and Image Manager / Archive actors.
4.74.1 Scope

4765

In the Replacement Instances Stored transaction, the Change Requester sends to the ImageManager / Archive new instances (images, presentation states, key image notes, etc.) that
represent versions of existing instances that have been corrected in some way (e.g., corrected
demographics, view information, or updated annotations).
Acquisition of additional SOP Instances, such as if correction of a Modality Worklist Selection
requires additional SOP Instances to be acquired, is out of scope of this transaction, as this iscovered by the Scheduled Workflow Profile.
184
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4770

4.74.2 Use Case Roles
ChangeRequester

Image Manager /Image Archive

Replacement
Instances Stored

Actor: Change Requester
Role: Transmit updated instances to Image Manager / Archive.
Actor: Image Manager / Archive
4775

Role: Accept updated instances from Change Requester.
4.74.3 Referenced Standard
DICOM 2011 PS 3.4: Storage Service Class.
4.74.4 Interaction Diagram
ChangeRequester

Image Manager/ Image Archive

Instances Stored (C-STORE)

4780

4.74.4.1 Instances Stored
4.74.4.1.1 Trigger Events
The Change Requester has created new replacement instances and needs to send them to the
Image Manager / Archive.
4.74.4.1.2 Message Semantics

4785

The Change Requester uses the DICOM C-STORE message to transfer the new instances. The
Change Requester is the DICOM Storage SCU and the Image Manager / Archive is the DICOM
Storage SCP.
A replacement instance created by the Change Requester shall:

4790

•

Have the same SOP Class as the replaced instance•

Belong to a new series

185
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________•

Set the header information according to the correct modality worklist entry if correctionis the result of new modality worklist selection (see 4.74.4.1.2.1)•

Update the Critical Attributes as described in Table 4.74.4.1.2-1

4795

Table 4.74.4.1.2-1: Critical Attributes for Replacement Instances
DICOM Attribute

4800

DICOM
Tag

Type

Description

Study Instance UID(0020,000D)R

Use Study Instance UID of the target study [IHE-1]

Series Instance UID(0020,000E)

R

Generate new UID [IHE-2]

SOP Instance UID(0008,0018)

R

Generate new UID [IHE-3]

Contributing Equipment
Sequence(0018,A001)

RC

Identification of the equipment that creates the replacement
instances
Required if the Change Requester is not the same as theoriginal creator of the replaced instances.

> Purpose of Referenced
Code Sequence(0040,A170)

R

Describes the purpose for which the related equipment is beingreferenced. Use an appropriate code from Table 4.74.4.1.2-3> Manufacturer(0008,0070)

R

Manufacturer of the Change Requester> Institution Name

(0008,0080)

R+

Institution where the Change Requester locates> Station Name

(0008,1010)

R+

AE Title of the Change Requester> Contribution DateTime(0018,A002)

R+

The creation date and time of the replacement instances

IHE-1:The new instances shall be associated with the study that they are targeted for. Therefore if the new instancereplaces an existing instance within the same study, then the Study Instance UID shall remain the same. On theother hand, if the new instance is created due to correction of the modality worklist entry, then the Study Instance
UID shall be the Study Instance UID associated with the correct modality worklist entry.

IHE-2:New Series Instance UID means that the newly created instance will not reuse any existing Series Instance UID.
According to DICOM, an existing series can only be expanded with new objects if the new objects are created by
the same equipment while the procedure step is still in progress. This is not the case for IOCM. As a result, a newseries is required for the replacement instances.

IHE-3:New SOP Instance UID means that the instance is a new instance, not the same existing instance with updated
header information. See Section 4.74.4.1.2.1 for details about replacement of SOP Instance UID.

4805

Table 4.74.4.1.2-2: Codes for Contributing Equipment
Code Value
DCM

4810

Code Scheme Designator
109103

Code Meaning
Modifying Equipment

A Change Requester grouped with an Acquisition Modality shall also support the semantics
defined in Modality Images Stored [RAD-8] and Modality Presentation State Stored [RAD-9].
A Change Requester grouped with an Evidence Creator shall also support the semantics definedin the Creator Images Stored [RAD-18] and Creator Presentation State Stored [RAD-19].

4815

A Change Requester grouped with an Image Manager/Archive that supports the Scheduled
Workflow Multiple Identity Resolution Option, shall also support the semantics defined in ImageManager Instances Stored [RAD-70].

186
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.74.4.1.2.1 Correction of Scheduled Procedure Information

4820

4825

Correction of scheduled procedure information in the corrected instances will be based on
information from the modality worklist entry when the Change Requester is an Acquisition
Modality. When a Change Requester is an Image Manager / Archive, it can get the same
information from the Procedure Scheduled transaction [RAD-4]. The following text will refer
only to the modality worklist case. The use of RAD-4 information should be understood. Notethat when using Table 4.74.4.1.2.1-1 and Tables defined in RAD TF-2: Appendix A.1, theModality Worklist column refers to the correct Modality Worklist item, and theImage/Standalone IOD and MPPS IOD columns are for the replacement SOP Instances and theircorresponding MPPS.
During correction of scheduled procedure information, the Change Requester shall create new
instances from the originally acquired instances which replace these original instances.

4830

4835

Two alternative scenarios can follow, depending upon whether or not the acquired images are
relevant to the actual scheduled procedure for the correct patient. Regardless, of which scenario
occurs, if additional images need to be acquired for the actual scheduled procedure for thecorrect patient then this shall be done according to Scheduled Workflow.
If it is determined that the originally acquired images are relevant to the actual scheduled
procedure for the correct patient, or if a new scheduled procedure has been created on the
DSS/OF for these images, then the patient and procedure attribute values can be taken from thisscheduled information. The required mapping of attributes shall be as defined in RAD TF-2:
Appendix A.1, unless the mapping rules are overridden by the attribute mapping defined in in
Table 4.74.4.1.2.1-1.
Table 4.74.4.1.2.1-1: Critical Attributes Mapping Exception
DICOM attribute

Modality Worklist
Filling values for:(return attributevalues)Image/ Standalone IOD

MPPS IOD
Copy from the Original
Instance or Original MPPS.
The Performed Procedure
Step for a corrected SOP
Instance will still be that of
the originally selected
Modality Worklist item (andthus may not correspond tothe correct one).

Performed Protocol Code
Sequence (0040,0260)

n.a.

Copy from the Original
Instance or Original MPPS.
The Performed Procedure Stepfor a corrected SOP Instancewill still be that of theoriginally selected Modality
Worklist item (and thus may
not correspond to the correctone).

Performed Procedure Step
ID (0040,0253)

n.a.

Copy from the Original
Instance or Original MPPS.

Performed Procedure Step
Start Date (0040,0244)

n.a.

Copy from the Original
Instance or Original MPPS.

Copy from the Original
Instance or Original MPPS.

Performed Procedure Step
Start Time (0040,0245)

n.a.

Copy from the Original
Instance or Original MPPS.

Copy from the Original
Instance or Original MPPS.

187
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________DICOM attribute

Modality Worklist
Filling values for:(return attributevalues)

4840

Image/ Standalone IOD

MPPS IOD

n.a.

Copy from the Original
Instance or Original MPPS.

Copy from the Original
Instance or Original MPPS.

Protocol Name (0018,1030)

n.a.

Copy from the Original
Instance or Original MPPS.

Copy from theOriginal
Instance orOriginal
MPPS.

Performed
SeriesSequence(0040,0340)

Performed Procedure Step
Description (0040,0254)

Alternatively, if the originally acquired images are not relevant to the actual scheduled procedure
for the correct patient, and no new scheduled procedure has been created on the DSS/OF forthese images, then the images could be manually corrected as for an unscheduled exam.
4.74.4.1.2.2 Maintenance of Instance Reference Integrity

4845

4850

4855

Since SOP Instance UIDs are sometimes used as references in other related instances (e.g.,
Referenced Images Sequence in GSPS objects), if the Change Requester decided that these
related instances remain valid and kept them, then the Change Requester shall ensure theconsistency of SOP Instance references for all instances that were originally created by the samegrouped Acquisition Modality or Evidence Creator. For example, if the Change Requester
replaces the original object Image1 (SOP Instance UID 1.2.3) by replacement object Image2(SOP Instance UID 1.2.3.1), then the Change Requester shall also correct existing GSPS object
GSPS1 that has a reference to Image1 by replacing it with a new GSPS object GSPS2 that has
the corrected reference to Image2, provided that GSPS1 was originally created by the same
Change Requester.
The Image Manager / Archive is not required to maintain the referential integrity of the instances
within a study. If the Image Manager / Archive receives instances for the same study frommultiple sources, then it is possible that the referential integrity of some instances (e.g., GSPS
object created by Evidence Creator) are broken upon receiving corrected instances from anothersource (e.g., Acquisition Modality).
4.74.4.1.3 Expected Actions

4860

The Image Manager / Archive shall store the received DICOM objects such that they can be later
retrieved (See RAD TF-2:4.16 Retrieve Images) in a fashion meeting the requirements definedfor a DICOM Level 2 Storage SCP (Refer to DICOM PS 3.4 B.4.1).

4.75 Cross Gateway Retrieve Imaging Document Set
4865

This section corresponds to Transaction 75 of the IHE Radiology Technical Framework.
Transaction 75 is used by the Initiating Imaging Gateway and Responding Imaging Gateway
actors.

188
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.75.1 Scope

4870

4875

The scope of the Cross Gateway Retrieve Imaging Document Set transaction is semantically thesame as the Retrieve Imaging Document Set transaction [RAD-69]. Differences from theRetrieve Imaging Document Set transactions are:
• The Cross Gateway Retrieve Imaging Document Set is between an Initiating Imaging
Gateway and a Responding Imaging Gateway.
• The ‘homeCommunityId’ parameter is required. This means that the homeCommunityId
parameter which is conditionally required on the Retrieve Imaging Document Set transaction
is required by this transaction.
• The Responding Imaging Gateway is required to support Asynchronous Web Services
Exchange on the Cross Gateway Retrieve Imaging Document Set.

4.75.2 Use Case Roles
Initiating
Imaging
Gateway

Responding
Imaging
Gateway

Cross Gateway
Retrieve Imaging
Document Set

4880
Figure 4.75.2: Use Case Roles

Actor: Initiating Imaging Gateway
Role: To formulate a Cross Gateway Retrieve Imaging Document Set request
4885

Actor: Responding Imaging Gateway
Role: To return the Imaging Document Set(s) requested.
4.75.3 Referenced Standard
For a list of the standards inherited from the underlying ITI-43 Retrieve Document Set, see ITI
TF-2b: 3.43.3.

189
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4890

4.75.4 Interaction Diagram
Initiating
Imaging
Gateway

Responding
Imaging
Gateway

Cross Gateway Retrieve
Imaging Document Set(Request)
Cross Gateway Retrieve
Imaging Document Set(Response)

4.75.4.1 Cross Gateway Retrieve Imaging Document Set
The Cross Gateway Retrieve Imaging Document Set uses the same syntax and standards as the
Retrieve Imaging Document Set transaction specified in RAD-69. See Section 4.69.
4895

4.75.4.1.1 Trigger Events
This message is initiated by the Initiating Imaging Gateway to retrieve Imaging Document Set(s)from another community represented by a Responding Imaging Gateway. The triggers for theInitiating Imaging Gateway include:
•

4900
•

a Retrieve Imaging Document Set (RAD-69) request initiated by an Imaging Document
Consumer within the Initiating Imaging Gateway’s community.
Prefetch logic as a result of a retrieval of a KOS manifest

4.75.4.1.2 Message Semantics
The message semantics for Cross Gateway Retrieve Imaging Document Set are the same as
Retrieve Imaging Document Set (RAD-69).
4905

The Initiating Imaging Gateway shall specify the homeCommunityId parameter within the Cross
Gateway Retrieve Imaging Document Set. The homeCommunityId shall contain the value that
identifies the community associated with the Responding Imaging Gateway(s).
4.75.4.1.3 Expected Actions

4910

Actors supporting this transaction shall support the Expected Actions described in RAD-69. See
XCA-I Supplement:4.69.
The Responding Imaging Gateway shall determine the Imaging Document Source(s) which holdthe imaging documents requested and initiate a RAD-69 transaction to those Imaging Document
Sources.

4915

If more than one Imaging Document Source is contacted, the Responding Imaging Gateway shallconsolidate the results from the multiple sources into one response to the Initiating Imaging
190
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Gateway. If both successes and failures are received, the Responding Imaging Gateway may
choose to use PartialSuccess status to reflect both failure and success. The Responding Imaging
Gateway may alternatively choose to suppress the failures and report only successes.
4920

4925

Every RegistryError element returned in the response shall have the location attribute set to thehomeCommunityId of the Responding Imaging Gateway.
The Initiating Imaging Gateway Actor shall consolidate results from all Responding Imaging
Gateways. This includes reflecting in the consolidated results returned to the originating Retrieve
Imaging Document Set [RAD-69] all successes and failures received from Responding Imaging
Gateways. If one of more responses with a status of failure or partial successes are received from
Responding Imaging Gateways, the Initiating Imaging Gateway shall respond to the originalRAD-69 request from the Imaging Document Consumer with both DocumentResponse andRegistryErrorList elements in one response and specify PartialSuccess status.
Note: the Responding Imaging Gateway may have suppressed failures resulting in the Initiating Imaging Gateway reportinga success.

4930

4.75.4.2 Asynchronous Web Service Method
An Initiating Imaging Gateway that supports the Asynchronous Web Services Option shall use
the Asynchronous Web Services Exchange method.
The Responding Imaging Gateway shall respond to an Initiating Imaging Gateway using the
Asynchronous Web Service Method.

4935

The Initiating Imaging Gateway supporting this method shall use the non-anonymous response
EPR in the WS-Addressing replyTo header.
The Initiating and Responding Imaging Gateways shall support the Asynchronous Web Services
Methods in the ITI TF-2x: Appendix V.5: Web Services for IHE Transactions, which also
includes additional considerations for implementers.

4940

4.75.5 Protocol Requirements
The Cross Gateway Retrieve Imaging Document Set request and response protocol requirements
are identical to the Retrieve Imaging Document Set Transaction except as noted below.
Table 4.75.5-1: WSDL Namespace Definitions
Soap

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

soap12

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

Wsaw

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

Xsd

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

Iheradurn:ihe:rad:xdsi-b:2009

Iheurn:ihe:iti:xds-b:2007

Rs

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

Lcm

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

Query

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

191
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4945

4950

4955

4960

4965

Responding Imaging Gateway: These are the requirements for the Cross Gateway Retrieve
Imaging Document Set transaction presented in the order in which they would appear in the
Responding Imaging Gateway WSDL definition:
The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:rad:xdsi-b:2009", schema=" XDSI.b_ImagingDocumentSource.xsd"
The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema=”
XDS.b_DocumentRepository.xsd”)
The /definitions/message/part/@element attribute of the Cross Gateway Retrieve Imaging
Document Set Request message shall be defined as“iherad:RetrieveImagingDocumentSetRequest”
The /definitions/message/part/@element attribute of the Cross Gateway Retrieve Imaging
Document Set Response message shall be defined as“urn:ihe:iti:2007:RetrieveDocumentSetResponse”
attributes shall be set as described below Table 4.75.5-2
To support Asynchronous Web Services Exchange on the Imaging Document Consumer or the
Responding Imaging Gateway, the Imaging Document Source or the Initiating Imaging
Gateway shall support the use of a non-anonymous response EPR in the WS-Addressing
replyTo header.
Table 4.75.5-2: Requirements for portType and Binding attributes
Attribute

Web Service Exchange/definitions/portType/operation@nameRespondingGateway_CrossGatewayRetrieveImagingDocumentSet/definitions/portType/operation/input/@wsaw:Action

urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSet/definitions/portType/operation/output/@wsaw:Action

urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse/definitions/binding/operation/soap12:
operation/@soapAction

urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSet

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

4975

The <iherad:RetrieveImagingDocumentSetRequest/> element is defined in RAD-69, Section
4.69.5. When used within the Cross Gateway Retrieve Imaging Document Set the<ihe:HomeCommunityId/> element is required.
A full XML Schema Document, the WSDL and sample messages for the XCA-I types, areavailable online on the IHE FTP site at: ftp://ftp.ihe.net/TF_Implementation_Material/RAD (forXCA-I).

192
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
4.75.5.1 Sample SOAP Messages

4980

The samples in the following two sections show a typical SOAP request and its relative SOAP
response. The sample messages also show the WS-Addressing headers <Action/>,<MessageID/>, <ReplyTo/>…; these WS-Addressing headers are populated according to the
W3C WS-Addressing standard. The body of the SOAP message is omitted for brevity; in a real
scenario the empty element will be populated with the appropriate metadata.
Samples presented in this section are also available online on the IHE FTP site, see
ftp://ftp.ihe.net/TF_Implementation_Material/RAD.
4.75.5.1.1 Sample Cross Gateway Retrieve Imaging Document Set SOAP Request

4985

4.75.5.1.1.1 Synchronous Web Services Exchange<s:Envelope

4990

4995

5000

5005

5010

5015

5020

5025

xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSet</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To s:mustUnderstand="1">http://localhost:2647/XcaService/IHEXCAIGateway.svc</a:To></s:Header><s:Body><RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"><SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest></StudyRequest><TransferSyntaxUIDList><TransferSyntaxUID> 1.2.840.10008.1.2.1</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.57</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList></RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.75.5.1.1.2 Asynchronous Web Services Exchange
5030<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header>

193
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________<a:Action s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSet

5035

5040

5045

5050

5055

5060

5065

</a:Action><a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:MessageID><a:ReplyTo>
http://192.168.2.4:9080/XcaiService/InitiatingImagingGatewayReceiver.svc</a:ReplyTo><a:To
s:mustUnderstand="1">http://localhost:2647/XcaiService/IHEXCAIGateway.svc</a:To></s:Header><s:Body><RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"><SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest></StudyRequest><TransferSyntaxUIDList><TransferSyntaxUID> 1.2.840.10008.1.2.1</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.57</TransferSyntaxUID><TransferSyntaxUID> 1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList></RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

5070
4.75.5.1.2 Sample Cross Gateway Retrieve Imaging Document Set SOAP
Response
4.75.5.1.2.1 Synchronous Web Services Exchange
5075

5080

5085

5090

5095

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse><DocumentResponse>

194
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5100

5105

<homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body>

4.75.5.1.2.2 Asynchronous Web Services Exchange
5110

5115

5120

5125

5130

5135

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse><DocumentResponse><homeCommunityId>urn:oid:1.2.3.4</homeCommunityId><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse></RetrieveDocumentSetResponse></s:Body>

5140

195
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5 Transaction Options on Other Domain Profiles
5145This section lists all the IHE Radiology options on transactions of other domains’ integration
profiles. Transactions from other domains that are reused in Radiology integration profiles are
not listed here, but rather referenced within those profiles. References to the other domains’technical frameworks we are creating options on are listed here as well.
References:
IT Infrastructure Technical Framework Volume-2 Section 3.20 (ITI TF-2a: 3.20)

5150

5155

5.1 ITI-20 Record Audit Event
The Radiology Audit Trail Option defines the specific requirements of the IHE Radiology
transactions for supporting the IHE ITI Audit Trail and Node Authentication Profile. This option
deals largely with the details of the Record Audit Event transaction in the IHE ITI Technical
Framework. The option details the required audit events for each of the IHE Radiology
transactions, based on the different trigger events. Refer to the ITI-ATNA Profile [ITI TF-2a:3.20] for the full definition of this transaction.
Note: No new triggers have been added beyond those previously defined in the Radiology Basic
Security Integration Profile. No new coded values have been added to extend the IHE Audit
Message dictionary.

5160

5.1.1 Trigger Events and Message semantics
An Audit Log is a record of actions performed on data by users. Actions are queries, views,
additions, deletions and changes. The IHE actor shall be able to create an Audit Record when an
IHE transaction-related event occurs or when a non-IHE transaction (e.g., application
functionality outside the IHE scope) event occurs.

5165

5170

IHE specifies that events defined in Table 5.1-1 shall be reportable by means of the IHE Audit
Trail. The deprecated SEC Provisional Audit Message name is only included here for reference,as well as the new IHE Audit Message EventId (code meaning) along with the specialized
EventTypeCode (code meaning) as needed (from DICOM supplement 95).
Table 5.1-1 lists all the trigger events for the generation of Audit Records. This is the table oftrigger events specified in ATNA [ITI TF-2a: 3.20], with the exceptions noted below, and isincluded here to further define the specific Audit Message contents.
The following trigger events from ATNA are not applicable to the Radiology actors andtransactions so they are not included in Table 5.1-1.

5175

•
•
•
•
•

Health-service-event
Medication
Patient-care-assignment
Patient-care-episode
Patient-care-protocol

196
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5180

The “Actor-config” trigger event is an extension of the ATNA triggers to provide continued
support for Basic Security.
Table 5.1-1: Audit Record Trigger Events
Trigger Event

Description

IHE Audit Message
Audit EventID(EventCodeType(s))

Provisional Audit
Message –DeprecatedActor-config

Generated for any configuration change
related to the actor. Applies to all actors.

Application Activity(Software Configuration)

ActorConfig

Actor-start-stop

Startup and shutdown of any actor. Applies
to all actors. Is distinct from hardware
powerup and shutdown.

Application Activity(Application Start,
Application Stop)

ActorStartStop

Audit-Log-Used

The audit trail repository has been accessedor modified by something other than thearrival of audit trail messages.

Audit Log Used

AuditLogUsed

Begin-storing-instances

Begin storing SOP Instances for a study.
This may be a mix of instances. Involved
actors: Acquisition Modality, Evidence
Creator.

Begin Transferring
DICOM Instances

BeginStoringInstances

Images Availability
Query

Image availability query is received.

Query

DICOMQuery

Instances-deleted

SOP Instances are deleted from a specificstudy.

DICOM Study Deleted

DICOMInstancesDeleted

Instances-Stored

Instances for a particular study have been
stored on this system.

DICOM Instances
Transferred

InstancesStored

Mobile-machine-event

Mobile machine joins or leaves securedomain.

Network Entry(Attach, Detach)

NetworkEntry

Node-Authenticationfailure

A secure node authentication failure has
occurred during TLS negotiation, e.g.,
invalid certificate.

Security Alert(Node Authentication)

SecurityAlert

Order-record-event

Order record created, accessed, modified ordeleted. Involved actors: Order Placer,
Order Filler.

Order Record

OrderRecord

Patient-record-event

Patient record created, modified, oraccessed. Involved actors: ADT Patient
Registration.

Patient Record

PatientRecord

PHI-export

Any export of PHI on media, either
removable physical media such as CDROM or electronic transfer of files such as
email. Any printing activity, paper or film,
local or remote, that prints PHI. Applies toall actors.

ExportExportPHI-import

Any import of PHI on media, either
removable physical media such as CDROM or electronic transfers of files such as
email. Applies to all actors.

ImportImportProcedure-record-event

Procedure record created, modified,accessed or deleted. Involved actors:
Department System Scheduled/Order
Filler.

Procedure Record

ProcedureRecord

197
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Trigger Event

5185

Description

IHE Audit Message
Audit EventID(EventCodeType(s))

Provisional Audit
Message –DeprecatedQuery Information

A query has been received, either as part ofan IHE transaction, or as part otherproducts functions. For example:
1. Modality Worklist Query

Query

DICOMQuery

Security Administration

Administrative actions create, modify,
delete, query, and display the following:(from ITI ATNA ITI TF-2a: Table 3.20.61 – not all numbered items included here.)
10. User authentication, authentication
failure, authentication revocation, or
signoff.
Security administration events should
always be audited.

User Authentication(Login, Logout)

UserAuthenticatedStudy-Object-Event

Study is created, modified, or accessed.
This reports on addition of new instances
to existing studies as well as creation of
new studies.

DICOM Instances
Accessed

DICOMInstancesUsed

Study-used

SOP Instances from a specific study are
created, modified or accessed. One event
covers all instances used for the particularstudy.

DICOM Instances
Accessed

DICOMInstancesUsed

Table 5.1-2 lists all the Radiology transactions which cause the corresponding Trigger Events
found in Table 5.1-1. The last column specifies whether the sender or receiver side of thetransaction is required to audit this transaction.
Note: There are a number of trigger events in Table 5.1-1 that are not related to an IHE transaction in Table 5.1-2. Trigger
events like “Actor-config” or “Actor-start-stop” are application activities. The audit of these events is required
when these types of triggers occur within your application.

5190

Note: No status notifications are audited (PPS messages, Status Updates), since both the sender and receiver have an
established trust relationship and they contain minimal amount of PHI.
Note: The Acquisition Modality and the Evidence Creator shall be able to report the Instances-deleted event when they
delete instances after Storage Commitment.

5195

Note: The receiver node of the query request, not the initiator of the request, shall be able to report any of the Query
transactions. The audit message records the query request not the query results.

Table 5.1-2: IHE Radiology transactions and resulting ATNA trigger events
IHE Radiology
Transaction

ATNA Trigger Event(s)Actor(s) that shall be able to record audit
event

Patient Registration [RAD-1]

Patient-record-event

ADT
Order Placer, DSS/OF - when PHI is presented

Placer Order Management[RAD-2]

Order-record-event

Order Placer
DSS/OF - when PHI is presented

Filler Order Management[RAD-3]

Order-record-event

DSS/OF

198
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________IHE Radiology
Transaction

ATNA Trigger Event(s)Actor(s) that shall be able to record audit
event

Procedure Scheduled [RAD-4]

Procedure-record-event

DSS/OF

Query Modality Worklist[RAD-5]

Query Information

DSS/OF

Modality Procedure Step In
Progress [RAD-6]

None

Modality Procedure Step
Completed [RAD-7]

None

Modality Images Stored [RAD8]

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive

Modality Presentation StateStored [RAD-9]

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive

Storage Commitment [RAD-10]

None

Images Availability Query[RAD-11]

Images Availability Query

Image Manager/Image Archive

Patient Update [RAD-12]

Patient-record-event

ADT
Order Placer, DSS/OF - when PHI is presented

Procedure Update [RAD-13]

Procedure-record-event

DSS/OF

Query Images [RAD-14]

Query Information

Image Manager/Image Archive

Query Presentation States[RAD-15]

Query Information

Image Manager/Image Archive

Retrieve Images [RAD-16]

Instances-Stored

Image Manager/Image Archive, Imaging Document
SourceStudy-used

Image Display, Imaging Document Consumer

Retrieve Presentation States[RAD-17]

Instances-Stored

Image Manager/Image Archive

Study-used

Image Display

Creator Images Stored[RAD-18]

Begin-storing-instances

Evidence Creator

Instances-Stored

Image Manager/Image Archive

Creator Presentation StateStored [RAD-19]

Begin-storing-instances

Evidence Creator

Instances-Stored

Image Manager/Image Archive

Creator Procedure Step In
Progress [RAD-20]

None

Creator Procedure Step
Completed [RAD-21]

None

Print Request with Presentation
LUT [RAD-23]

PHI-export

Print Composer

Report Submission [RAD-24]

Begin-storing-instances

Report Creator

Instances-Stored

Report Manager

Begin-storing-instances

Report Manager

Report Issuing [RAD-25]

Instances-Stored

Report Repository

Query Reports [RAD-26]

Query Information

Report Repository/External Report Repository

Retrieve Reports [RAD-27]

Instances-Stored

Report Repository/External Report Repository

Study-used

Report Reader

199
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________IHE Radiology
Transaction

ATNA Trigger Event(s)Actor(s) that shall be able to record audit
event

Structured Report Export[RAD-28]

Instances-Stored

Report Manager

Key Image Note Stored[RAD-29]

Begin-storing-instances

Evidence Creator, Acquisition Modality

Instances-Stored

Image Manager/Image Archive

Query Key Image Notes[RAD-30]

Query Information

Image Manager/Image Archive

Retrieve Key Image Notes[RAD-31]

Instances-Stored

Image Manager/Image Archive

Study-used

Image Display

Authenticate Node [ITI-19]

Node-Authentication-failure

Any secure node

Maintain Time [ITI-1]

None

Record Audit Event [ITI-20]

None

Charge Posted [RAD-35]

PHI-export

DSS/OF

Account Management[RAD-36]

PHI-export

ADT

Query Post-Processing Worklist[RAD-37]

Query Information

Post-Processing Manager

Workitem Claimed [RAD-38]

None

Workitem PPS In-Progress[RAD-39]

None

Workitem PPS Completed[RAD-40]

None

Workitem Completed[RAD-41]

None

Performed Work Status Update[RAD-42]

None

Evidence Document Stored[RAD-43]

Begin-storing-instances

Acquisition Modality / Evidence Creator

Instances-Stored

Image Manager/Image Archive

Query Evidence Documents[RAD-44]

Query Information

Image Manager/Image Archive

Retrieve Evidence Documents[RAD-45]

Instances-Stored

Image Manager/Image Archive

Study-used

Image Display

Query Reporting Worklist[RAD-46]

Query Information

Report Manager

Distribute Imaging Information
on Media [RAD-47]

PHI-export

Portable Media Creator

PHI-import

Portable Media Importer

Study-used

Image Display, Report Reader, Print Composer

Appointment Notification[RAD-48]

None

Instance Availability
Notification [RAD-49]

None

Store Instances [RAD-50]

Begin-storing-instances

Export Selector

Instances-Stored

Export Manager

Store Export Selection[RAD-51]

Begin-storing-instances

Export Selector

Instances-Stored

Export Manager

200
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________IHE Radiology
Transaction
Store Additional Teaching File
Information [RAD-52]
Export Instances [RAD-53]
WADO Retrieve [RAD-55]

ATNA Trigger Event(s)Actor(s) that shall be able to record audit
event

Begin-storing-instances

Export Selector

Instances-Stored

Export Manager

Begin-storing-instances

Export Manager – when PHI is exported

Instances-Stored

Receiver – when PHI is exported

Instances-Stored

Imaging Document Source

Study-used

Imaging Document Consumer

Import Procedure Step In
Progress [RAD-59]

None

Import Procedure Step
Completed [RAD-60]

None

Imported Objects Stored [RAD61]

Begin-storing-instances

Sender Importer shall audit

Instances-Stored

Receiver (IM/IA) shall audit

Store Dose Information [RAD62]

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive, Dose Information
Reporter, Dose Information Consumer

Submit Dose Information[RAD-63]

Begin-storing-instances

Dose Information Reporter – when PHI is exported

Instances-Stored

Dose Registry – when PHI is exported

Query Dose Information [RAD64]

Query Information

Image Manager/Image Archive

Retrieve Dose Information[RAD-65]

Instances-Stored

Image Manager/Image Archive

Study-used
Instances-deletedDose Information Reporter, Dose Information Consumer

Rejection Note Stored [RAD66]

Sender: Acquisition Modality, Evidence Creator, Change
Requester.

Instances-deleted

Note: The Actor rejecting/ correcting images must assume
that the Image Archive may hide the images (similar tological deletion).
Receiver: Image Archive.

Patient Demographics Query[ITI-21]

Query Information

Note: Although an Archive may be configured to provide
rejected images, this may be changed any time by users.
Thus, it is valuable to log this.
Patient Demographics Supplier shall audit

Provide and Register Imaging
Document Set – MTOM/XOP[RAD-68]

PHI-export

Imaging Document Source

Retrieve Imaging Document Set[RAD-69]

Instances-Stored

Imaging Document Source

Study-used

Imaging Document Consumer

Replacement Instances Stored[RAD-74]

Begin-storing-instances
Instances-stored

Sender: Change Requester

Instances-stored

Receiver: Image Manager / Archive.

Instances-Stored

Responding Imaging Gateway

Study-used

Initiating Imaging Gateway

Cross Gateway Retrieve
Imaging Document Set [RAD75]

201
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix A:

Deprecated

5200

202
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix B:

Deprecated203
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5205

Appendix C:

Attribute Consistency between General Purpose
Worklist, SPS, PPS and Resulting Composite IODs in
Post-Processing Workflow

5210

This appendix provides requirements for the use of attributes in the objects generated by thedifferent participants of the Post-Processing Workflow. In particular, it specifies which attributes
provided by the Post-Processing Manager shall be used unaltered to populate the attributes in the
GP-PPS objects, objects that may be produced as a result of postprocessing operations, and also
the N-ACTION command that is used to claim and complete workitems.
C.1: Integration-critical Attributes
The table below shall be interpreted as follows:
•

5215

•
5220
•

5225

An Attribute shown in the first column shall be requested by a GPWL SCU (for example,
image processing workstation or CAD device) as a return key in its C-FIND Requests.
The Post-Processing Manager shall return attribute Values in the C-FIND response.
The return Attribute Values shall be used by the performing station in filling the Attributeshown on the corresponding line of Table C.1-1 both for Composite Instances (second
column) and GP-PPS Instances.
The Post-Processing Manager shall be capable of handling the Attributes shown in thecorresponding line of the third column as defined by the SCP Type and the additional
notes.

Table C.1-1: Comparison of Corresponding Attributes of General Purpose Worklist, SPS,
PPS, Images, GSPS and other IODs
GeneralPurposeWorklist

GeneralPurpose SPS
N-ACTION

GeneralPurpose PPS

Images and
GSPS IOD

SR Based
Evidence
Documents

KIN

--

--

Referenced
General Purpose
Scheduled
Procedure Step
Sequence [1C]

--

--

--

SOP Class UID[1]

SOP Class UID[1]>SOP Class UID
[1]

--

--

--

SOP Instance UID[1]

SOP Instance UID[1]>SOP Instance
UID [1]

--

-

--

--

Transaction UID[1]> Referenced
General Purpose
Scheduled
Procedure Step
Transaction UID[1]--General Purpose
Scheduled
Procedure Step
Status [1]General Purpose
Scheduled
Procedure Step
Status[1]

--

--

--

--

204
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
GeneralPurposeWorklist

GeneralPurpose SPS
N-ACTION

GeneralPurpose PPS

Images and
GSPS IOD

SR Based
Evidence
Documents

KIN

Input Information
Sequence [2]

--

--

--

Current
Requested
Procedure
Evidence
Sequence [1C]--

Relevant
Information
Sequence [2]

--

--

--

Pertinent Other
Evidence
Sequence [1C]--

Referenced Study
Component
Sequence [3]Referenced Study
Component
Sequence [2]Referenced Study
Component
Sequence [2]Referenced Study
Component
Sequence [2]ResultingGeneral Purpose
Performed
Procedure Step
Sequence [2]>Referenced SOPClass UID [1]--

SOP Class UID[1]>SOP Class UID[1]>SOP Class UID[1]>SOP Class UID[1]>Referenced SOP
Instance UID [1]--

SOP Instance
UID [1]>SOP Instance
UID [1]>SOP Instance
UID [1]>SOP Instance
UID [1]

Actual Human
Performers
Sequence [2]Actual Human
Performers
Sequence [3]Actual Human
Performers
Sequence [2]

--

--

--

Study Instance
UID [1]----

Study Instance
UID [1]

Study Instance
UID [1]

Study Instance
UID [1]

--

--

--

RequestAttributes
Sequence [3]----Scheduled
Procedure Step
ID [1]>Scheduled
Procedure Step
ID [1C]

Referenced
RequestSequence [1]Referenced
RequestSequence [2]Referenced
RequestSequence[1C]

Referenced
RequestSequence [1C]

>Study Instance
UID [1]>Study Instance
UID [1]>Study Instance
UID [1]>Study Instance
UID [1]>Requested
Procedure ID [1]>Requested
Procedure ID [2]>Requested
Procedure ID [2]>Requested
Procedure ID [2]>Requested
Procedure
Description [1C]

>Requested
Procedure
Description [2]>Requested
Procedure
Description [2]>Requested
Procedure
Description [2]>Requested
Procedure Code
Sequence [1C]

>Requested
Procedure Code
Sequence [2]>Requested
Procedure Code
Sequence [2]>Requested
Procedure Code
Sequence [2]>Referenced
Study Sequence[2]>Referenced
Study Sequence[2]

Referenced Study
Sequence [3]>Referenced
Study Sequence[2]>Referenced
Study Sequence[2]>Accession>Accession

Accession>Accession>Accession>Requested
Procedure ID
[1C]

205
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
GeneralPurposeWorklist

GeneralPurpose SPS
N-ACTION

GeneralPurpose PPS

Images and
GSPS IOD
Number [2]SR Based
Evidence
Documents

KIN

Number [2]Number [2]Number [2]Number [2]>Placer Order
Number/Imaging
Service Request[3]>Placer Order
Number/Imaging
Service Request[3]>Placer Order
Number/Imaging
Service Request[2]>Placer Order
Number/Imaging
Service Request[2]>Filler Order
Number/Imaging
Service Request[3]>Filler Order
Number/Imaging
Service Request[3]>Filler Order
Number/Imaging
Service Request[2]>Filler Order
Number/Imaging
Service Request[2]>Requesting
Physician [2]>Requesting
Physician [2]>Requesting
Physician [2]>Requesting
Physician [2]Performed
Procedure Step
ID [1]

Performed
Procedure Step
ID [3]

Performed
Procedure Step
Start Date [1]Performed
Procedure Step
Start Date [3]Performed
Procedure Step
Start Time [1]Performed
Procedure Step
Start Time [3]Performed
Procedure Step
Description [1]Performed
Procedure Step
Description [3]206Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix D:
5230

5235

Attribute Consistency between General Purpose
Worklist, SPS, PPS and Resulting Composite IODs In
Reporting Workflow

This appendix provides requirements for the use of attributes in the diagnostic reports generated
by the Report Creator as a participant of Reporting Workflow. These reports are encoded as
DICOM SR objects. In particular, it specifies which attributes provided by the Report Manager
shall be used unaltered to populate the attributes in the GP-PPS objects, resulting DICOM SR
objects, and also the N-ACTION command that is used to claim and complete workitems.
D.1: Integration-critical Attributes
The table below shall be interpreted as follows:
•

5240
•
•
5245

An Attribute shown in the first column shall be requested by a GPWL SCU (ReportCreator) as a return key in its C-FIND Requests. The Report Manager shall return
attribute Values in the C-FIND response.
The return Attribute Values shall be used by the Report Creator in filling the Attributeshown on the corresponding line of Table D.1-1 both for Composite Instances (fourthcolumn) and GP-PPS Instances.
The Report Manager shall be capable of handling the Attributes shown in thecorresponding line of the third column as defined by the SCP Type and the additional
notes.

Table D.1-1: Comparison of Corresponding Attributes of General Purpose Worklist, SPS,
PPS, Images, GSPS and other IODs
General Purpose
Worklist

General Purpose
SPS N-ACTION

General Purpose
PPS

SR Based Report
Documents----

Referenced General
Purpose Scheduled
Procedure Step
Sequence [1C]--

SOP Class UID [1]

SOP Class UID [1]>SOP Class UID [1]--

SOP Instance UID [1]

SOP Instance UID [1]>SOP Instance UID [1]---Transaction UID [1]> Referenced General
Purpose Scheduled
Procedure Step
Transaction UID [1]General Purpose
Scheduled Procedure
Step Status [1]General Purpose
Scheduled Procedure
Step Status[1]----Input Information
Sequence [2]----Current Requested
Procedure Evidence
Sequence [1C]

Relevant Information
Sequence [2]----Pertinent Other
Evidence Sequence
[1C]

207
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
General Purpose
Worklist

General Purpose
SPS N-ACTION

General Purpose
PPS

SR Based Report
Documents

Referenced Study
Component Sequence[2]
Resulting General
Purpose Performed
Procedure Step
Sequence [2]Referenced Study
Component Sequence[2]>Referenced SOP ClassUID [1]--

SOP Class UID [1]>SOP Class UID [1]>Referenced SOP
Instance UID [1]--

SOP Instance UID [1]>SOP Instance UID [1]--Actual Human
Performers Sequence[3]

Actual Human
Performers Sequence[2]

Actual Human
Performers Sequence[2]

Study Instance UID [1]----Study Instance UID [1]

--

--

--

--

Referenced Request
Sequence [1]Referenced Request
Sequence [2]Referenced Request
Sequence[1C]>Study Instance UID [1]>Study Instance UID[1]>Study Instance UID[1]>Requested Procedure
ID [1]>Requested Procedure
ID [2]>Requested Procedure
ID [2]>Requested Procedure
Description [1C]

>Requested Procedure
Description [2]>Requested Procedure
Description [2]>Requested Procedure
Code Sequence [1C]

>Requested Procedure
Code Sequence [2]>Requested Procedure
Code Sequence [2]>Referenced Study
Sequence [2]>Referenced Study
Sequence [2]>Referenced Study
Sequence [2]>Accession Number [2]>Accession Number[2]>Accession Number [2]>Placer Order
Number/Imaging Service
Request [3]>Placer Order
Number/Imaging
Service Request [3]>Placer Order
Number/Imaging
Service Request [2]>Filler Order
Number/Imaging
Service Request [3]>Filler Order
Number/Imaging
Service Request [3]>Filler Order
Number/Imaging
Service Request [2]>Requesting Physician[2]>Requesting Physician[2]>Requesting Physician[2]

Scheduled Procedure
Step ID [1]Performed Procedure
Step ID [1]Performed Procedure
Step Start Date [1]Performed Procedure
Step Start Time [1]Performed Procedure
Step Description [1]

5250
208
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix E:

5255

DICOM Media Interchange – Critical DICOM
Compatibility Tips

This appendix presents a number of compatibility issues that result from not following the
DICOM Media Interchange standard (PS 3.10, PS 3.11 and PS 3.12). This appendix is simply
intended to be a reminder for the most common DICOM issues that have resulted in the past inincompatibilities between file set creators and readers.
This list shall not be interpreted, as being the only DICOM requirements that implementersshould pay attention to. DICOM has proven to be a very effective and thorough specification that
implementers of this IHE profile shall be familiar with.

5260

1.

The CD Media shall be formatted according to ISO 9660 Level 1. Extensions such as
Joliet or Rock Ridge are not forbidden by DICOM and hence are permitted by the PDIProfile. A UDF file system is not allowed unless an ISO 9660 Level 1 Filesystem isalso present. Such extensions may be necessary to encode non-DICOM content on the
media, such as long filenames for viewing software. Such extensions may result in ISO
9660 Level 1 uppercase filenames being presented to application software as lowercase
or mixed case depending on the operating system’s mount behavior; accordingly, allPortable Media Displays and Portable Media Importers shall be case insensitive in thisrespect.

2.

The DICOMDIR file shall be at the root directory of the Interchange Media

3.

All DICOM file names shall contain only uppercase letters, numeric digits and theunderscore character, and the file name size without extensions shall not exceed 8
characters.

4.

All Directory names in DICOM paths shall contain only uppercase characters, numeric
digits and the underscore character. Directory names shall not contain extensions.

5.

Non-DICOM files may have extensions with more than 3 characters.

6.

DICOM files shall have no extension.

7.

DICOM files shall have an ISO 9660 version of 1, which may be displayed by some
operating systems as a ".;1" at the end. However, the ".;1" should not be included in thename of the file itself.

8.

The version number of the file name shall not be included in the reference data elementin the DICOMDIR.

9.

Only 8 levels of Directories are allowed, including the root directory (i.e., there may be
up to 7 levels of sub-directories below the root).

10.

Objects in DICOM files shall be stored in Explicit VR Little Endian (not Implicit)

11.

DICOM File Meta-Information shall be in Explicit VR Little Endian (not Implicit)

12.

File Meta Information Version (0002,0001) shall contain a two byte OB value
consisting of a 0x00 byte, followed by 0x01 byte, and not the value 0x0001 encoded asa little endian 16 bit short value, which would be the other way around.

5265

5270

5275

5280

5285

209
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
13.

The file meta information shall include the Media Storage SOP Class UID (0002,0002)
data element, and its value shall be equal to the SOP Class UID data element in the data
set.

14.

The file meta information shall include the Media Storage SOP Instance UID(0002,0003) data element, and its value shall be equal to the SOP Instance UID data
element in the data set.

15.

No private elements shall be included in the file meta information.

16.

The file meta information header shall contain an attribute (0002,0000) Group Lengthwith a correct value as specified in DICOM PS 3.10.

17.

The physical format of the DICOM CD-R discs shall comply with the application
definitions within ISO/IEC 10149 Part II as specified in PS3.12. This allows discs to be
written with:

5290

5295

5300

•
•

Mode 1 sectors orMode 2, Form 1 sectors with CD-ROM-XA File Number = 0, Channel Number =0 and Coding Information Byte = 0.

210
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5305

Appendix F:

Example Created Media Instance Content

5310

Example F-1. Media containing a DICOM CT imaging study, a DICOM Presentation States anda DICOM Structured Report. The creator supports the Web Content Option and includes webviewable data derived from DICOM data on the media. Also a DICOM Viewer is included on
the media.
Content element(s)Description

Identification Marking

Marker with content per 4.47.4.1.2.2:
patient namecreation datename of the institution that created the media/README.TXT

File with content per 4.47.4.1.2.2/INDEX.HTM

File with content per 4.47.4.1.2.2:
media type: “DICOM PLUS WEB”
links to XHTML report and to another page (THUMBS.HTM) with thumbnails
that link the full resolution JPEG images
link to a launch point for the DICOM viewer in the VIEWERS directorylink to the list of importable data

/DICOMDIRDICOM Directory file referencing all DICOM instances:
all DICOM images
the PS object
the SR object/ DICOM//DICOM /12296/DICOM /12297.
.
.
/DICOM /NNNNN/DICOM /98732/DICOM /12312

Directory with content per 4.47.4.1.2.2:
Image object 1
Image object 2.
.
.
Image object N
DICOM Presentation State object
Basic Text DICOM Structured Report object/IHE_PDI /REPORT.HTM/IHE_PDI /THUMBS.HTM/IHE_PDI /T_12296.JPG/IHE_PDI /T_12297.JPG/IHE_PDI /I_12296.JPG/IHE_PDI /I_12297.JPG

XHTML reportnavigation page derived from DICOM data that displays T_12296.JPG and
T_12297.JPG
thumbnail of Image object 1
thumbnail of Image object 2
full resolution JPEG image for view within browser
full resolution JPEG image for view within browser/VIEWERS//VIEWERS/VIEWER.EXE

Optional directory:
executable viewer

211
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

5315

Example F-2. Media containing a DICOM US imaging study and a DICOM SR diagnostic
report. The creator does not support the Web Content Option but chose to optionally include the
README.TXT file. No web-viewable data derived from DICOM data is included on the media.
Content element(s)Identification Marking

Description

Marker with content per 4.47.4.1.2.2:
patient namecreation datename of the institution that created the media/README.TXT

media type: “DICOM ONLY”
File with content per 4.47.4.1.2.2/DICOMDIRDICOM Directory file referencing all DICOM instances:/DICOM//DICOM/78567856/DICOM/78567857.
.
.
/DICOM/NNNNNNN/DICOM/12343412

all DICOM images
the SR object
Directory with content per 4.47.4.1.2.2:
Image object 1
Image object 2.
.
.

Image object N
Basic Text DICOM Structured Report object

212
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix G:
5320

G.1:

Configuration for Accessing DICOM, WADO and Web
Services Retrieve Services

Mapping DICOM AE Title to DICOM AE Network Address

When an Imaging Document Consumer wants to retrieve DICOM instances that are referenced
within a shared manifest Document using DICOM C-Move/C-Store, the following configurationis necessary.
5325

5330

5335

5340

The Key Object Selection Document Instance includes an AE Title but does not include any IP
address or any port number. As AE Title alone is not sufficient to retrieve DICOM objects, theImaging Document Consumer needs to get the IP address and the port number of the Imaging
Document Source from its local configuration file.
Similarly, the Imaging Document Source needs to know the AE Title, the IP address and the port
number of the Imaging Document Consumer in order to store the DICOM objects. The Imaging
Document Source needs to get the IP address, the AE Title, the port number of the Imaging
Document Consumer from its local configuration file.
In this profile, it is assumed that mapping of AE Titles of Imaging Document Source andImaging Document Source to their network presentation addresses (IP and port) is supported byexchanging configuration files of the related actors, under the guidance of affinity domain
policies and processes. The method of configuration file exchange is out of the scope of thisprofile. In the future, DICOM Supplement 67 (Configuration Management) and its proper
extension in cross-enterprise use can be employed to automate this mapping. This may be a
future Integration Profile candidate of IHE IT Infrastructure domain.
As IP addresses and port numbers need to be resolved from AE titles, a special attention isrequired to ensure that AE titles of actors that are involved in this profile are uniquely allocatedin an affinity domain.

G.2:
5345

5350

5355

Mapping DICOM AE Title to WADO Service Network Address

In order for an Imaging Document Consumer to retrieve DICOM instances referenced within ashared Manifest Document using WADO Access transaction (RAD-55), it needs to build a
WADO HTTP Request-URI for the SOP instance. Though SOP instance identification
information is fully specified in the Manifest, the Imaging Document Consumer needs anauxiliary method to map the Retrieve AE Title specified for a referenced SOP Instance in the
Manifest to the server network address, which supports the WADO retrieve service.
The Imaging Document Consumer needs to maintain a mapping configuration of the server
network addresses of all Imaging Document Source in the Affinity Domain, and their Retrieve
AE Titles. Using this mapping, the Retrieve AE Title of a referenced SOP instance in the
Manifest can be translated to WADO service server address, which is then used to build the
WADO HTTP Request-URI together with SOP instance identification information, andoptionally other standard WADO HTTP parameters.

213
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________To achieve an unambiguous, automated mapping of Retrieve AE Title and WADO accessservice server network address, some policy needs to be in place to ensure unique Retrieve AE
Titles of Imaging Document Source in the entire Affinity Domain.

G.3:
5360

5365

5370

Mapping DICOM AE Title to Web Services Address

To use the Retrieve Imaging Document Set transaction (RAD-69) to retrieve DICOM instancesreferenced within a manifest document, an Imaging Document Consumer must pass arepositoryUniqueId attribute in the Retrieve Imaging Document Set Request.
The Imaging Document Consumer needs to maintain a list that associates the web service
addresses of all Imaging Document Sources in the XDS Affinity Domain and their Retrieve AE
Titles and/or Retrieve Location UIDs. Using this mapping, the Retrieve AE Title of a referenced
SOP instance in the manifest can be translated to a repositoryUniqueId, which is then passed in
the Retrieve Imaging Document Set Request together with a documentUniqueId (SOP instanceidentification information). Alternatively, a Retrieve Location UID can be used directly as therepositoryUniqueId in the Retrieve Imaging Document Set Request.
To achieve an unambiguous, automated mapping from Retrieve AE Title to a web service
address, some policy needs to be in place to ensure unique Retrieve AE Titles of Imaging
Document Sources within the entire XDS Affinity Domain.

214
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix H:
5375

Included here is a DICOM 2011 PS 3.16 style template containing:
•
•

5380
•
•
5385

5390

Example Template for Teaching File Structured Report
Manifests

section headings (container concept names) for plain text blocks to mirror the MIRC
concepts of history, findings, discussion, plus coded alternatives where likely (e.g.,history and findings)
section headings (container concept names) and code concept names for differential
diagnosis, diagnosis, pathology, anatomy and organ system, etc.
context groups for coded values for differential diagnosis, diagnosis, pathology, anatomy
and organ system (likely from SNOMED +/- ICD9CM, +/- ACR Index)
diagnosis confirmation flag

The idea is to provide for the partial or complete authoring of teaching files on the Image
Display. The concepts are derived from those in the RSNA MIRC Document Schema Version
16.
Note that this template will not replicate the function of the Key Object Selection document in its
role as a manifest; hence neither a listing of the referenced instances to be included, nor the
person observer context for the receiver of the manifest to route it to the correct user will be
required.

215
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Table H-1: Example Additional Teaching File Information Template
NL

Rel with
parent1

Value Type

Concept Name

VM

Req
Type

CONTAINER

EV (TCE006, IHERADTF,“Additional Teaching File
Information”)

1

M

Cond

Value Set Constraint
Root node

2>

CONTAINSTEXT

EV (TCE101, IHERADTF,“Author”)

1

M

3

>>

HAS
PROPERTIESTEXT

EV (TCE102, IHERADTF,“Affiliation”)

1

U

4

>>

HAS
PROPERTIESTEXT

EV (TCE103, IHERADTF,“Contact”)

1

U

5

>

CONTAINSTEXT

EV (TCE104, IHERADTF,“Abstract”)

1

M

6

>

CONTAINSTEXT

EV (TCE105, IHERADTF,“Keywords”)

1-n

MC

XOR row 7

7>

CONTAINS

CODE

EV (TCE105, IHERADTF,“Keywords”)

1-n

MC

XOR row 6 ACR or MESH or ICD9CM Diagnosis
Codes

8

>

CONTAINSTEXT

EV (121060, DCM, "History")

1-n

U

9

>

CONTAINS

CODE

EV (121060, DCM, "History")

1-n

U

10

>

CONTAINSTEXT

EV (121071, DCM, "Finding")

1-n

U

11

>

CONTAINS

CODE

EV (121071, DCM, "Finding")

1-n

U

12

>

CONTAINSTEXT

EV (TCE106, IHERADTF,“Discussion”)

1-n

U

13

>

CONTAINS

TEXT(111023, DCM, “Differential
Diagnosis/ Impression”)

1-n

U

14

>

CONTAINS

CODE(111023, DCM, “Differential
Diagnosis/ Impression”)

1-n

U

15

>

CONTAINSTEXT

EV (TCE107, IHERADTF,“Diagnosis”)

1-n

U

16

>

CONTAINS

CODE

EV (TCE107, IHERADTF,

1-n

U

216
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________NL

Rel with
parentValue Type

Concept Name

VM

Req
Type

Cond

Value Set Constraint“Diagnosis”)
17>

CONTAINSTEXT(112005, DCM, “Radiographic
anatomy”)

1-n

U

18

>

CONTAINS

CODE(112005, DCM, “Radiographic
anatomy”)

1-n

U

19

>

CONTAINS

TEXT(111042, DCM, “Pathology”)

1-n

U

20

>

CONTAINS

CODE(111042, DCM, “Pathology”)

1-n

U

21

>

CONTAINSTEXT

EV (TCE108, IHERADTF,“Organ system”)

1-n

U

22

>

CONTAINS

CODE

EV (TCE108, IHERADTF,“Organ system”)

1-n

U

23

>

CONTAINS

CODE(121139, DCM, “Modality”)

1-nU

DCID (29) Acquisition Modality

24>

CONTAINS

CODE

EV (TCE109, IHERADTF,“Category”)

1

M

BCID Table Q-2 categories of teaching
files

25

>

CONTAINS

CODE

EV (TCE110, IHERADTF,“Level”)

1

U

BCID Table Q-3 levels of teaching
files

27

>

CONTAINS

CODE

EV (TCE111, IHERADTF,“Diagnoses confirmed”)

1

U

DCID (230) Yes-No

217
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
Table H-2: Categories of Teaching Files(American Board of Radiology categories)
CodingSchemeDesignator

Code
Value

Code Meaning

IHERADTF

TCE301

Musculoskeletal

IHERADTF

TCE302

Pulmonary

IHERADTF

TCE303

Cardiovascular

IHERADTF

TCE304

Gastrointestinal

IHERADTF

TCE305

Genitourinary

IHERADTF

TCE306

Neuro

IHERADTF

TCE307

Vascular and Interventional

IHERADTF

TCE308

Nuclear

IHERADTF

TCE309Ultrasound

IHERADTF

TCE310Pediatric

IHERADTF

TCE311

BreastTable H-3: Levels of Teaching Files
CodingSchemeDesignator

Code
Value

Code Meaning

IHERADTF

TCE201Primary

IHERADTF

TCE202

Intermediate

IHERADTF

TCE203

Advanced

218
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________

Appendix I:

I.1:

De-identification, Re-identification, Pseudonymization,
Persistence of Identification and Clinical Trial
Attributes (Informative)

De-identification

Complete de-identification of a DICOM instance to remove all PHI contained within attributes
without a priori knowledge of how the instance was created requires removal of the values all
attributes containing text as well as all private attributes. This is often impractical, since useful
information required for subsequent applications may be contained in some of the text values.
For example, Study Description and Series Description typically contain useful information that
it is often undesirable to remove. De-identification of a report would not typically remove thetext values that are the payload of the report. In some cases it may be useful to provide amechanism for replacement of Study Description and Series Description that are moremeaningful or more correct for a particular teaching file or clinical trial application, e.g., to statethat a series is “T1 axial post-contrast” or similar, when this information is otherwise absent.
Dates and times may or may not be appropriate to remove. For example, it may be desirable toremove any evidence of a particular visit date (e.g., Study Date), though the times may need to
be preserved in order to maintain the temporal relationship between images. In other scenarios,
dates may need to be preserved exactly, in order to correlate with real-world events, such as
therapy.
Ages and dates of birth are particularly problematic, since they are also a form of PHI, but may
be required for the statistical purpose of a clinical trial or the meaningful interpretation of ateaching file case where age affects diagnostic possibilities. A typical technique is to remap ages
into exemplars of an age range, or to make dates the first of the same month, etc. The validity ofsuch techniques requires review by an expert.
In addition, site policy and local regulations may impose specific requirements on removal of
PHI for specific purposes, and these requirements may differ. It is not possible or desirable tostandardize for every use case which attributes must be removed.
One can go to extraordinary lengths to attempt to ensure de-identification by such means as
adding noise to pixel data to confound binary or hash matching, removal of facial features andother such mechanisms. This is rarely, if ever, required in practice and is beyond the scope of
IHE to define.

I.2:

Consistency of Identifiers on Repeated Export

Whilst it is entirely possible to devise reversible and irreversible algorithms to consistently map
identifiers into new values, even if those algorithms are based on cryptographic one-way hashfunctions, anyone with access to a list of all possible inputs (e.g., all patient names and IDs in theinstitution) could identify the subject by a relatively short exhaustive search. Thus while such

219
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________
mechanisms may be effective for de-identification for distribution outside an institution, they
may not be not sufficient within an institution.
An alternative means to provide deterministic mapping would be to maintain a persistent recordof the mapping (such as a database), and to consult that record on the next occasion. Such a
record would need to be well protected.
For the same reason, if auditing export actions, care should be taken not to include both theoriginal and replacement identities in the audit trail.
Reversible mapping might be desirable in some scenarios in which authorized individuals werepermitted to recover the original identity. Means of achieving this are not defined by IHE,
though either a persistent record of mapping as described, or embedded encrypted original
attributes as described in DICOM 2011 PS 3.15 Basic Application Level Confidentiality Profile,
could be used.
An irreversible, but repeatable, mapping may also be useful for later updates of teaching files, as
additional information becomes available. For example, follow-up studies and reports or
pathology information could automatically be re-mapped to the same teaching file identifiers andhence automatically become part of the same teaching file, since the same “pseudonymous”
identifiers would be used.

I.3:

Addition of Clinical Trial Attributes

DICOM defines additional optional attributes that may be added to any composite SOP instancefor the purpose of clinical trials. These are defined in the Clinical Trial Subject, Clinical Trial
Study and Clinical Trial Series Modules in PS 3.3.
These attributes provide:••

Subject identification information that may be used to augment the patient identification,e.g., the combination of Clinical Trial Protocol ID, Clinical Trial Site ID and Clinical
Trial Subject ID
Other trial-specific identifiers useful for the trial workflow, not specifically related to
identification of the subject, e.g., Clinical Trial Timepoint ID

To the extent that this information is known at the time of the Export Instances transaction, it isdesirable to populate these fields.
Since many downstream systems will not be aware of these attributes, however, it is common
practice to also replace the normal DICOM patient and other identification fields with values
corresponding to the clinical trial identifiers. For example, not only might one insert Clinical
Trial Protocol ID, Clinical Trial Site ID and Clinical Trial Subject ID, but also replace Patient ID
with Clinical Trial Subject ID, Patient Name with a concatenation of Clinical Trial Protocol ID,
Clinical Trial Site ID and Clinical Trial Subject ID, and Institution Name with Clinical Trial Site
ID, etc.
The Remap Identifiers Option provides a mechanism to automatically populate these values.

220
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Transactions (continued)______________________________________________________________________________GLOSSARY
Please see RAD TF-1: Appendix E - Glossary

221
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.