Integrating the Healthcare Enterprise

5

10

IHE Radiology (RAD)Technical Framework

Volume 3
IHE RAD TF-3
Transactions (continued)

15

20

Revision 18.0 Final Text
August 9, 201925

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

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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 [RAD-35] .................................................................................................. 16
4.35.1
Scope .................................................................................................................. 16
4.35.2
Use Case Roles ................................................................................................... 174.35.3
Referenced Standards ......................................................................................... 17
Messages............................................................................................................. 174.35.44.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 ..................................................................................... 20
4.35.4.1.2.5 FT1 Segment ...................................................................................... 21
4.35.4.1.2.6 PR1 Segment – Procedures ................................................................ 224.35.4.2
Sources of Information ............................................................................. 24
4.35.4.3
Expected Actions ...................................................................................... 28
4.36 Account Management [RAD-36] ...................................................................................... 28
4.36.1
Scope .................................................................................................................. 29
4.36.2
Use Case Roles ................................................................................................... 29
4.36.3
Referenced Standards ......................................................................................... 29
4.36.4
Messages............................................................................................................. 29
4.36.4.1
Account Management - New Account ...................................................... 30
4.36.4.1.1 Trigger Events ........................................................................................... 30
4.36.4.1.2 Message Semantics ................................................................................... 30
4.36.4.1.2.1 MSH Segment .................................................................................... 31
4.36.4.1.2.2 EVN Segment .................................................................................... 31
4.36.4.1.2.3 PID Segment ...................................................................................... 31
4.36.4.1.2.4 PV1 Segment ..................................................................................... 31
4.36.4.1.2.5 DG1 Segment..................................................................................... 32
4.36.4.1.2.6 GT1 Segment ..................................................................................... 32
4.36.4.1.2.7 IN1 Segment ...................................................................................... 34
4.36.4.1.3 Expected Actions ...................................................................................... 36
4.36.4.2
Account Management – Update Account ................................................. 36
4.36.4.2.1 Trigger Events ........................................................................................... 36
4.36.4.2.2 Message Semantics ................................................................................... 36___________________________________________________________________________
2
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

75

80

85

90

95

100

105

110

115

4.36.4.2.2.1 MSH Segment .................................................................................... 37
4.36.4.2.2.2 EVN Segment .................................................................................... 37
4.36.4.2.2.3 PID Segment ...................................................................................... 37
4.36.4.2.2.4 PV1 Segment ..................................................................................... 37
4.36.4.2.2.5 DG1 Segment..................................................................................... 38
4.36.4.2.2.6 GT1 Segment ..................................................................................... 38
4.36.4.2.2.7 IN1 Segment ...................................................................................... 38
4.36.4.2.3 Expected Actions ...................................................................................... 38
4.36.4.3
Account Management – End Account ...................................................... 38
4.36.4.3.1 Trigger Events ........................................................................................... 38
4.36.4.3.2 Message Semantics ................................................................................... 38
4.36.4.3.2.1 MSH Segment .................................................................................... 39
4.36.4.3.2.2 EVN Segment .................................................................................... 39
4.36.4.3.2.3 PID Segment ...................................................................................... 39
4.36.4.3.2.4 PV1 Segment ..................................................................................... 39
4.36.4.3.3 Expected Actions ...................................................................................... 39
4.37 Query Post-Processing Worklist [RAD-37]..................................................................... 40
4.37.1
Scope .................................................................................................................. 40
4.37.2
Use Case Roles ................................................................................................... 40
4.37.3
Referenced Standards ......................................................................................... 40
4.37.4
Messages............................................................................................................. 41
4.37.4.1
Query General Purpose Worklist Message ............................................... 41
4.37.4.1.1 Trigger Events ........................................................................................... 41
4.37.4.1.2 Message Semantics ................................................................................... 41
4.37.4.1.2.1 Matching Keys and Return Keys ....................................................... 41
4.37.4.1.2.2 Examples for the Use of Matching Key Attributes ........................... 43
4.37.4.1.2.3 Matching Keys and Return Keys ....................................................... 43
4.37.4.1.3 Expected Actions ...................................................................................... 47
4.37.4.2
Receive General Purpose Worklist Message ............................................ 47
4.37.4.2.1 Trigger Events ........................................................................................... 47
4.37.4.2.2 Message Semantics ................................................................................... 47
4.37.4.2.3 Expected Actions ...................................................................................... 48
4.38 Workitem Claimed [RAD-38] .......................................................................................... 48
4.38.1
Scope .................................................................................................................. 48
4.38.2
Use Case Roles ................................................................................................... 48
4.38.3
Referenced Standards ......................................................................................... 49
4.38.4
Messages............................................................................................................. 49
4.38.4.1
General Purpose Scheduled Procedure Step In Progress/Suspend Message
49
4.38.4.1.1 Trigger Events ........................................................................................... 49
4.38.4.1.2 Message Semantics ................................................................................... 49
4.38.4.1.3 Expected Actions ...................................................................................... 50
4.39 Workitem Performed Procedure Step In Progress [RAD-39]........................................... 50
4.39.1
Scope .................................................................................................................. 50___________________________________________________________________________
3
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

120

125

130

135

140

145

150

155

4.39.2
Use Case Roles ................................................................................................... 51
4.39.3
Referenced Standards ......................................................................................... 51
4.39.4
Messages............................................................................................................. 51
4.39.4.1
General Purpose Performed Procedure Step In Progress Message ........... 52
4.39.4.1.1 Trigger Events ........................................................................................... 52
4.39.4.1.2 Message Semantics ................................................................................... 52
4.39.4.1.3 Expected Actions ...................................................................................... 52
4.39.4.1.3.1 Relationship between Scheduled and Performed Procedure Steps.... 53
4.39.4.1.3.1.1
Simple Case ......................................................................... 53
4.39.4.1.3.1.2
Unscheduled Case ............................................................... 53
4.39.4.1.3.1.3
Append Case ....................................................................... 53
4.39.4.1.3.1.4
Abandoned Case .................................................................. 54
4.40 Workitem Performed Procedure Step Completed [RAD-40] ........................................... 54
4.40.1
Scope .................................................................................................................. 54
4.40.2
Use Case Roles ................................................................................................... 54
4.40.3
Referenced Standards ......................................................................................... 55
4.40.4
Messages............................................................................................................. 55
4.40.4.1
General Purpose Performed Procedure Step Completed Message ........... 55
4.40.4.1.1 Trigger Events ........................................................................................... 55
4.40.4.1.2 Message Semantics ................................................................................... 56
4.40.4.1.3 Reporting Message Semantics .................................................................. 56
4.40.4.1.4 Expected Actions ...................................................................................... 56
4.41 Workitem Completed [RAD-41] ...................................................................................... 56
4.41.1
Scope .................................................................................................................. 56
4.41.2
Use Case Roles ................................................................................................... 57
4.41.3
Referenced Standards ......................................................................................... 57
4.41.4
Messages............................................................................................................. 57
4.41.4.1
General Purpose SPS Completed Message ............................................... 58
4.41.4.1.1 Trigger Events ........................................................................................... 58
4.41.4.1.2 Message Semantics ................................................................................... 58
4.41.4.1.3 Expected Actions ...................................................................................... 58
4.42 Performed Work Status Update [RAD-42] ....................................................................... 59
4.42.1
Scope .................................................................................................................. 59
4.42.2
Use Case Roles ................................................................................................... 59
4.42.3
Referenced Standards ......................................................................................... 60
Messages............................................................................................................. 61
4.42.44.42.4.1
Post-Processing Performed Procedure Step Created/Updated Message... 62
4.42.4.1.1 Trigger Events ........................................................................................... 62
4.42.4.1.2 Message Semantics ................................................................................... 62
4.42.4.1.3 Expected Actions ...................................................................................... 63
4.43 Evidence Document Stored [RAD-43] ............................................................................. 63
4.43.1
Scope .................................................................................................................. 63
4.43.2
Use Case Roles ................................................................................................... 64
4.43.3
Referenced Standards ......................................................................................... 64___________________________________________________________________________
4
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
160

165

170

175

180

185

190

195

200

4.43.4
Messages............................................................................................................. 64
4.43.4.1
Evidence Document Stored....................................................................... 65
4.43.4.1.1 Trigger Events ........................................................................................... 65
4.43.4.1.2 Message Semantics ................................................................................... 65
4.43.4.1.3 Expected Actions ...................................................................................... 65
4.43.4.1.3.1 Mammography Image Profile ........................................................... 66
4.44 Query Evidence Documents [RAD-44] ............................................................................ 66
4.44.1
Scope .................................................................................................................. 66
4.44.2
Use Case Roles ................................................................................................... 66
4.44.3
Referenced Standards ......................................................................................... 66
4.44.4
Messages............................................................................................................. 67
4.44.4.1
Query Evidence Documents ..................................................................... 67
4.44.4.1.1 Trigger Events ........................................................................................... 67
4.44.4.1.2 Message Semantics ................................................................................... 67
4.44.4.1.3 Expected Actions ...................................................................................... 68
4.44.4.1.3.1 Mammography Image Profile ........................................................... 68
4.45 Retrieve Evidence Documents [RAD-45] ........................................................................ 68
4.45.1
Scope .................................................................................................................. 68
4.45.2
Use Case Roles ................................................................................................... 69
4.45.3
Referenced Standards ......................................................................................... 69
4.45.4
Messages............................................................................................................. 69
Retrieve Evidence Documents .................................................................. 69
4.45.4.1
4.45.4.1.1 Trigger Events ........................................................................................... 70
4.45.4.1.2 Message Semantics ................................................................................... 70
4.45.4.1.3 Expected Actions ...................................................................................... 70
4.45.4.2
Render Evidence Documents .................................................................... 70
4.45.4.2.1 Trigger Events ........................................................................................... 70
4.45.4.2.2 Invocation Semantics ................................................................................ 70
4.45.4.2.3 Expected Actions ...................................................................................... 71
4.45.4.2.3.1 Mammography Image Profile ........................................................... 71
4.46 Query Reporting Worklist [RAD-46] ............................................................................... 71
Scope .................................................................................................................. 71
4.46.1
4.46.2
Use Case Roles ................................................................................................... 72
4.46.3
Referenced Standards ......................................................................................... 72
4.46.4
Messages............................................................................................................. 72
4.46.4.1
Query General Purpose Worklist Message ............................................... 73
4.46.4.1.1 Trigger Events ........................................................................................... 73
4.46.4.1.2 Message Semantics ................................................................................... 73
4.46.4.1.2.1 Matching Keys and Return Keys ....................................................... 73
4.46.4.1.2.2 Examples for the Use of Matching Key Attributes ........................... 74
4.46.4.1.2.3 Matching Keys and Return Keys ....................................................... 74
4.46.4.1.3 Expected Actions ...................................................................................... 78
4.46.4.2
Receive General Purpose Worklist Message ............................................ 78
4.46.4.2.1 Trigger Events ........................................................................................... 78___________________________________________________________________________
5
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

205

210

215

220

225

230

235

240

245

4.46.4.2.2 Message Semantics ................................................................................... 78
4.46.4.2.3 Expected Actions ...................................................................................... 78
4.47 Distribute Imaging Information on Media [RAD-47] ...................................................... 79
4.47.1 Scope ........................................................................................................................ 79
4.47.2 Use Case Roles ......................................................................................................... 79
4.47.3 Referenced Standard ................................................................................................ 80
4.47.4 Messages .................................................................................................................. 80
4.47.4.1 Distribute Imaging Information on Media ....................................................... 80
4.47.4.1.1 Trigger Events .......................................................................................... 81
4.47.4.1.2 Message Semantics ................................................................................... 81
4.47.4.1.2.1 Media Filesystem and File Naming Restrictions .............................. 81
4.47.4.1.2.2 Content Organization Overview ....................................................... 81
4.47.4.1.2.2.1
DICOM Content .................................................................. 82
4.47.4.1.2.2.2 Web Content Option ................................................................. 82
4.47.4.1.2.2.3 Optional Content ....................................................................... 84
4.47.4.1.2.2.4 Media Identification .................................................................. 84
4.47.4.1.2.3 Content Organization Detail ............................................................. 85
4.47.4.1.2.3.1 DICOM Content ........................................................................ 85
4.47.4.1.2.3.2 Web Content Option ................................................................. 89
4.47.4.1.2.3.3 Content when Grouping with XDM (IHE ITI Technical
Framework) ................................................................................ 91
4.47.4.1.3 Expected Actions ...................................................................................... 92
4.47.4.1.3.1 Expected Actions Common to All Actors ........................................ 92
4.47.4.1.3.2 Image Display ................................................................................... 92
4.47.4.1.3.3 Report Reader ................................................................................... 93
4.47.4.1.3.4 Portable Media Importer ................................................................... 93
4.47.4.1.3.4.1 Grouping with XDM (IHE ITI Technical Framework) ............ 94
4.47.4.1.3.5 Print Composer ................................................................................. 95
4.47.4.1.3.6 Display .............................................................................................. 95
4.47.4.1.4 Media Options .......................................................................................... 95
4.47.4.1.4.1 DVD Media Option........................................................................... 95
4.47.4.1.4.2 USB Media Option ........................................................................... 96
4.48 Appointment Notification [RAD-48]............................................................................... 96
4.48.1 Scope ........................................................................................................................ 97
4.48.2 Use Case Roles ......................................................................................................... 97
4.48.3 Referenced Standard ................................................................................................ 97
4.48.4 Messages .................................................................................................................. 98
4.48.4.1 Appointment Notification -New Bookings ...................................................... 98
4.48.4.1.1 Trigger Events .......................................................................................... 98
4.48.4.1.2 Message Semantics ................................................................................... 98
4.48.4.1.2.1 MSH Segment ................................................................................... 99
4.48.4.1.2.2 SCH Segment .................................................................................... 99
4.48.4.1.2.3 RGS Segment .................................................................................. 100
4.48.4.1.2.4 AIS Segment ................................................................................... 101___________________________________________________________________________
6
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

250

255

260

265

270

275

280

285

290

4.48.4.1.2.5 NTE Segment .................................................................................. 102
4.48.4.1.3 Expected Actions .................................................................................... 102
4.48.4.2 Appointment Notification - Reschedule Bookings......................................... 102
4.48.4.2.1 Trigger Events ........................................................................................ 102
4.48.4.2.2 Message Semantics ................................................................................. 103
4.48.4.2.2.1 MSH Segment ................................................................................. 103
4.48.4.2.2.2 SCH, RGS, NTE Segments ............................................................. 103
4.48.4.2.2.3 AIS Segment ................................................................................... 103
4.48.4.2.3 Expected Actions .................................................................................... 103
4.48.4.3 Appointment Notification - Cancel Bookings ................................................ 104
4.48.4.3.1 Trigger Events ........................................................................................ 104
4.48.4.3.2 Message Semantics ................................................................................. 104
4.48.4.3.2.1 MSH Segment ................................................................................. 104
4.48.4.3.2.2 SCH, RGS, NTE Segments ............................................................. 104
4.48.4.3.2.3 AIS Segment ................................................................................... 104
4.48.4.3.3 Expected Actions .................................................................................... 105
4.49 Instance Availability Notification [RAD-49]................................................................. 105
4.49.1 Scope ...................................................................................................................... 105
4.49.2 Use Case Roles ....................................................................................................... 105
4.49.3 Referenced Standard .............................................................................................. 105
4.49.4 Messages ................................................................................................................ 106
4.49.4.1 Instance Availability Notification .................................................................. 106
4.49.4.1.1 Trigger Events ........................................................................................ 106
4.49.4.1.2 Message Semantics ................................................................................. 107
4.49.4.1.3 Expected Actions .................................................................................... 107
4.50 Store Instances [RAD-50] .............................................................................................. 108
4.50.1
Scope ................................................................................................................ 108
4.50.2
Use Case Roles ................................................................................................. 108
4.50.3
Referenced Standard ......................................................................................... 108
4.50.4
Messages........................................................................................................... 109
4.50.4.1 Store Instances ................................................................................................ 109
4.50.4.1.1 Trigger Events ........................................................................................ 109
4.50.4.1.2 Message Semantics ................................................................................. 109
4.50.4.1.3 Expected Actions .................................................................................... 109
4.51 Store Export Selection [RAD-51] .................................................................................. 109
4.51.1
Scope ................................................................................................................ 109
4.51.2
Use Case Roles ................................................................................................. 110
4.51.3
Referenced Standard ......................................................................................... 110
4.51.4
Messages........................................................................................................... 110
4.51.4.1 Store Export Selection .................................................................................... 111
4.51.4.1.1 Trigger Events ........................................................................................ 111
4.51.4.1.2 Message Semantics ................................................................................. 111
4.51.4.1.3 Expected Actions .................................................................................... 113
4.51.4.1.4 De-identification and Pseudonymization ................................................ 114___________________________________________________________________________
7
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

295

300

305

310

315

320

325

330

335

4.51.4.1.4.1 Baseline De-identification and Pseudonymization Requirements .. 114
4.51.4.1.4.2 Manifest Coercion ........................................................................... 115
4.51.4.1.4.3 Remap Identifiers Option ................................................................ 115
4.51.4.1.4.4 De-identify Pixel Data Option ........................................................ 116
4.51.4.1.4.5 De-identification of Non-Image Instances ...................................... 117
4.51.4.1.5 Delay for Reason .................................................................................... 117
4.52 Store Additional Teaching File Information [RAD-52] ................................................ 117
4.52.1
Scope ................................................................................................................ 117
4.52.2
Use Case Roles ................................................................................................. 118
4.52.3
Referenced Standard ......................................................................................... 118
4.52.4
Messages........................................................................................................... 118
4.52.4.1 Store Additional Teaching File Information .................................................. 119
4.52.4.1.1 Trigger Events ........................................................................................ 119
4.52.4.1.2 Message Semantics ................................................................................. 119
4.52.4.1.3 Expected Actions .................................................................................... 119
4.53 Export Instances [RAD-53] ........................................................................................... 119
4.53.1
Scope ................................................................................................................ 119
4.53.2
Use Case Roles ................................................................................................. 120
4.53.3
Referenced Standard ......................................................................................... 120
4.53.4
Messages........................................................................................................... 120
4.53.4.1 Export Instances ............................................................................................. 121
4.53.4.1.1 Trigger Events ........................................................................................ 121
4.53.4.1.2 Message Semantics ................................................................................. 121
4.53.4.1.3 Expected Actions .................................................................................... 121
4.54 Provide and Register Imaging Document Set - DEPRECATED................................... 122
4.55 WADO Retrieve [RAD-55] ........................................................................................... 122
4.55.1 Scope ...................................................................................................................... 122
4.55.2 Use Case Roles ....................................................................................................... 122
4.55.3 Referenced Standard .............................................................................................. 122
4.55.4 Messages ................................................................................................................ 123
4.55.4.1 WADO Retrieve ............................................................................................. 123
4.55.4.1.1 Trigger Events ........................................................................................ 123
4.55.4.1.2 Message Semantics ................................................................................. 123
4.55.4.1.2.1 Example of WADO Request-URI .................................................. 125
4.55.4.1.3 Expected Actions .................................................................................... 126
4.55.4.1.4 Audit Trail Trigger Events...................................................................... 126
4.56 Temporarily, intentionally, left blank ............................................................................ 126
4.57 Temporarily, intentionally, left blank ............................................................................ 126
4.58 Temporarily, intentionally left blank ............................................................................. 126
4.59 Import Procedure Step In Progress [RAD-59] ............................................................... 127
4.59.1
Scope ................................................................................................................ 127
4.59.2
Use Case Roles ................................................................................................. 127
4.59.3
Referenced Standards ....................................................................................... 128
4.59.4
Messages........................................................................................................... 128___________________________________________________________________________
8
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

340

345

350

355

360

365

370

375

4.59.4.1
Procedure Step In Progress Message ...................................................... 129
4.59.4.1.1 Trigger Event .......................................................................................... 129
4.59.4.1.2 Message Semantics ................................................................................. 129
4.59.4.1.2.1 Patient/Procedure/Scheduled Procedure Step Information .............. 129
4.59.4.1.2.2 Required Attributes .......................................................................... 129
4.59.4.1.2.3 Relationship between Scheduled and Performed Procedure Steps andthe Imported DICOM Composite Object ........................................ 130
4.59.4.1.2.3.1
Scheduled Import .............................................................. 130
4.59.4.1.2.3.2
Unscheduled Import .......................................................... 130
4.59.4.1.2.3.3
Performed Protocol Sequence for Import .......................... 131
4.59.4.1.3 Expected Actions .................................................................................... 131
4.60
Import Procedure Step Completed/Discontinued [RAD-60] ................................... 131
4.60.1
Scope ................................................................................................................ 131
4.60.2
Use Case Roles ................................................................................................. 132
4.60.3
Referenced Standards ....................................................................................... 132
4.60.4 Messages ................................................................................................................ 132
4.60.4.1
Procedure Step Completed/Discontinued ............................................... 133
4.60.4.1.1 Trigger Event .......................................................................................... 133
4.60.4.1.2 Message Semantics ................................................................................. 133
4.60.4.1.2.1 Retrieve AE Title ............................................................................. 134
4.60.4.1.2.2 Import PPS Exception Management ................................................ 134
4.60.4.1.2.3 Billing and Material Management Option ....................................... 135
4.60.4.1.3 Expected Actions .................................................................................... 136
4.60.4.1.3.1 Import PPS Exception Management ................................................ 137
4.60.4.1.3.2 Billing and Material Management Information Option ................... 137
4.61 Imported Objects Stored [RAD-61] ............................................................................... 137
4.61.1Scope ....................................................................................................................... 138
4.61.2
Use Case Roles ................................................................................................. 138
4.61.3
Referenced Standards ....................................................................................... 138
4.61.4Messages ................................................................................................................. 138
4.61.4.1
Evidence Objects Stored ......................................................................... 139
4.61.4.1.1 Trigger Events ......................................................................................... 139
4.61.4.1.1.1 UIDs ................................................................................................. 139
4.61.4.1.2 Message Semantics ................................................................................. 139
4.61.4.1.2.1 Original Attributes Sequence ........................................................... 139
4.61.4.1.2.2 Contributing Equipment Sequence .................................................. 140
4.61.4.1.3 Expected Actions .................................................................................... 141
4.61.4.1.3.1 DICOM Storage SOP Classes ......................................................... 142
4.62 Store Dose Information [RAD-62] ................................................................................. 142
4.62.1 Scope ...................................................................................................................... 142
4.62.2 Use Case Roles ....................................................................................................... 142
4.62.3 Referenced Standard .............................................................................................. 143
4.62.4 Messages ................................................................................................................ 143
4.62.4.1 Store Dose Information .................................................................................. 143___________________________________________________________________________
9
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
380

385

390

395

400

405

410

415

420

4.62.4.1.1 Trigger Events ........................................................................................ 144
4.62.4.1.1.1 Digitization ...................................................................................... 144
4.62.4.1.2 Message Semantics ................................................................................. 145
4.62.4.1.2.1 Cross-referencing Dose Objects and Image Objects ....................... 147
4.62.4.1.3 Expected Actions .................................................................................... 147
4.63 Submit Dose Information [RAD-63] ............................................................................. 147
4.63.1 Scope ...................................................................................................................... 147
4.63.2 Use Case Roles ....................................................................................................... 148
4.63.3 Referenced Standard .............................................................................................. 148
4.63.4 Messages ................................................................................................................ 148
4.63.4.1 Submit Dose Information ............................................................................... 149
4.63.4.1.1 Trigger Events ........................................................................................ 149
4.63.4.1.2 Message Semantics ................................................................................. 149
4.63.4.1.2.1 De-identification ............................................................................. 150
4.63.4.1.3 Expected Actions .................................................................................... 151
4.64 Query Dose Information [RAD-64] ................................................................................ 152
4.64.1 Scope ...................................................................................................................... 152
4.64.2 Use Case Roles ....................................................................................................... 152
4.64.3 Referenced Standard .............................................................................................. 152
4.64.4 Messages ................................................................................................................ 153
4.64.4.1 Query Dose Information ................................................................................. 153
4.64.4.1.1 Trigger Events ........................................................................................ 153
4.64.4.1.2 Message Semantics ................................................................................. 153
4.64.4.1.2.1 Filtering Strategies .......................................................................... 155
4.64.4.1.3 Expected Actions .................................................................................... 156
4.65 Retrieve Dose Information [RAD-65] ............................................................................ 156
4.65.1 Scope ...................................................................................................................... 156
4.65.2 Use Case Roles ....................................................................................................... 157
4.65.3 Referenced Standard .............................................................................................. 157
4.65.4 Messages ................................................................................................................ 157
4.65.4.1 Retrieve Dose Information ............................................................................. 158
4.65.4.1.1 Trigger Events ........................................................................................ 158
4.65.4.1.2 Message Semantics ................................................................................. 158
4.65.4.1.3 Expected Actions .................................................................................... 158
4.66 Rejection Note Stored [RAD-66] ................................................................................... 159
4.66.1 Scope ...................................................................................................................... 159
4.66.2 Use Case Roles ....................................................................................................... 159
4.66.3 Referenced Standards ............................................................................................. 160
4.66.4 Messages ................................................................................................................ 160
4.66.4.1
Rejection Note Stored (for Quality Reasons) ......................................... 161
4.66.4.1.1 Trigger Events ........................................................................................ 161
4.66.4.1.2 Message Semantics ................................................................................. 161
4.66.4.1.3 Expected Actions .................................................................................... 161
4.66.4.1.3.1 Access to Rejected Instances ........................................................... 163___________________________________________________________________________
10
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

425

430

435

440

445

450

455

460

465

4.66.4.2 Rejection Note Stored (for Patient Safety Reasons)....................................... 163
4.66.4.2.1 Trigger Events ........................................................................................ 163
4.66.4.2.2 Message Semantics ................................................................................. 163
4.66.4.2.3 Expected Actions .................................................................................... 164
4.66.4.2.3.1 Additional Requirements for Image Manager / Archive in IOCM.. 164
4.66.4.3 Rejection Note Stored (for Incorrect Modality Worklist) .............................. 164
4.66.4.3.1 Trigger Events ........................................................................................ 164
4.66.4.3.2 Message Semantics ................................................................................. 164
4.66.4.3.3 Expected Actions .................................................................................... 165
4.66.4.4 Rejection Note Stored (for Data Retention Expiry) ....................................... 165
4.66.4.4.1 Trigger Events ........................................................................................ 165
4.66.4.4.2 Message Semantics ................................................................................. 165
4.66.4.4.3 Expected Actions .................................................................................... 166
4.67 Temporarily, intentionally, left blank ............................................................................ 166
4.68 Provide and Register Imaging Document Set – MTOM/XOP [RAD-68] ..................... 166
4.68.1 Scope ...................................................................................................................... 166
4.68.2 Use Case Roles ....................................................................................................... 167
4.68.3 Referenced Standards ............................................................................................. 167
4.68.4 Messages ................................................................................................................ 168
4.68.4.1 Provide and Register Imaging Document Set – MTOM/XOP Request message.......................................................................................................................... 168
4.68.4.1.1 Trigger Events ........................................................................................ 168
4.68.4.1.2 Message Semantics ................................................................................. 169
4.68.4.1.2.1 Sharing of Set of DICOM Instances ................................................ 169
4.68.4.1.2.1.1 Manifest KOS Document ........................................................ 170
4.68.4.1.2.2 Sharing of Report ............................................................................. 170
4.68.4.1.2.3 Document Sharing Metadata ........................................................... 171
4.68.4.1.2.3.1 Metadata Attributes: Author Information and Document
Creation Time ........................................................................... 172
4.68.4.1.2.3.2 DocumentEntry Metadata ....................................................... 172
4.68.4.1.2.3.3 Transformation of DICOM VR to Document Sharing Metadata
Data Types ................................................................................ 175
4.68.4.1.2.3.4 Document Sharing Metadata Values represented as HL7 v2.5
Data Types ................................................................................ 178
4.68.4.1.2.3.5 CDA Wrapper – CDA Wrapped Text Report Option ............. 180
4.68.4.1.2.4 Use of Document Sharing Submission Set ...................................... 183
4.68.4.1.2.4.1 Linking Report to Set of DICOM Instances ........................... 183
4.68.4.1.2.4.2 Linking Report to prior report ................................................. 184
4.68.4.1.3 Expected Actions .................................................................................... 184
4.68.4.2 Provide and Register Imaging Document Set – MTOM/XOP Response
message............................................................................................................. 185
4.69 Retrieve Imaging Document Set [RAD-69] ................................................................... 185
4.69.1 Scope ...................................................................................................................... 185
4.69.2 Use Case Roles ....................................................................................................... 186___________________________________________________________________________
11
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

470

475

480

485

490

495

500

505

510

4.69.3 Referenced Standards ............................................................................................. 186
4.69.4 Messages ................................................................................................................ 187
4.69.4.1 Retrieve Imaging Document Set Request message ........................................ 187
4.69.4.1.1 Trigger Events ........................................................................................ 188
4.69.4.1.2 Message Semantics ................................................................................. 188
4.69.4.1.3 Expected Actions .................................................................................... 189
4.69.4.2 Retrieve Imaging Document Set Response message...................................... 189
4.69.4.2.1 Trigger Events ........................................................................................ 189
4.69.4.2.2 Message Semantics ................................................................................. 189
4.69.4.2.3 Expected Actions .................................................................................... 189
4.69.4.3 Asynchronous Web Services Exchange Method ............................................ 190
4.69.5 Protocol Requirements ........................................................................................... 191
4.69.5.1
Sample SOAP Messages ......................................................................... 194
4.69.5.1.1 Sample Retrieve Imaging Document Set SOAP Request....................... 195
4.69.5.1.1.1 Synchronous Web Services Exchange ............................................ 195
4.69.5.1.1.2 Asynchronous Web Services Exchange.......................................... 195
4.69.5.1.2 Sample Retrieve Document Set SOAP Response .................................. 196
4.69.5.1.2.1 Synchronous Web Services Exchange ............................................ 196
4.69.5.1.2.2 Asynchronous Web Services Exchange.......................................... 196
4.70 Temporarily, intentionally, left blank ............................................................................. 197
4.71 Temporarily, intentionally, left blank ............................................................................. 197
4.72 Temporarily, intentionally, left blank ............................................................................. 197
4.73 Temporarily, intentionally, left blank ............................................................................. 197
4.74 Replacement Instances Stored [RAD-74] ...................................................................... 197
4.74.1 Scope ...................................................................................................................... 197
4.74.2 Use Case Roles ....................................................................................................... 198
4.74.3 Referenced Standard .............................................................................................. 198
4.74.4 Messages ................................................................................................................ 198
4.74.4.1 Instances Stored .............................................................................................. 198
4.74.4.1.1 Trigger Events ........................................................................................ 198
4.74.4.1.2 Message Semantics ................................................................................. 198
4.74.4.1.2.1 Correction of Scheduled Procedure Information ............................ 200
4.74.4.1.2.2 Maintenance of Instance Referential Integrity ................................ 201
4.74.4.1.3 Expected Actions .................................................................................... 202
4.75 Cross Gateway Retrieve Imaging Document Set [RAD-75] ......................................... 202
4.75.1 Scope ...................................................................................................................... 202
4.75.2 Use Case Roles ....................................................................................................... 203
4.75.3 Referenced Standard .............................................................................................. 203
4.75.4 Messages ................................................................................................................ 203
4.75.4.1 Cross Gateway Retrieve Imaging Document Set ........................................... 204
4.75.4.1.1 Trigger Events ........................................................................................ 204
4.75.4.1.2 Message Semantics ................................................................................. 204
4.75.4.1.3 Expected Actions .................................................................................... 204
4.75.4.2 Asynchronous Web Service Method .............................................................. 205___________________________________________________________________________
12
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

515

520

525

530

535

540

545

4.75.5 Protocol Requirements ........................................................................................... 205
4.75.5.1 Sample SOAP Messages ................................................................................ 206
4.75.5.1.1 Sample Cross Gateway Retrieve Imaging Document Set SOAP Request................................................................................................................. 207
4.75.5.1.1.1 Synchronous Web Services Exchange ............................................ 207
4.75.5.1.1.2 Asynchronous Web Services Exchange.......................................... 207
4.75.5.1.2 Sample Cross Gateway Retrieve Imaging Document Set SOAP Response................................................................................................................. 208
4.75.5.1.2.1 Synchronous Web Services Exchange ............................................ 208
4.75.5.1.2.2 Asynchronous Web Services Exchange.......................................... 208
5 Transaction Options on Other Domain Profiles ..................................................................... 210
5.1 Record Audit Event [ITI-20] ............................................................................................ 210
5.1.1 Trigger Events and Message semantics.................................................................... 210
Appendix A: Deprecated ........................................................................................................ 216
Appendix B: Deprecated ........................................................................................................ 217
Appendix C: Attribute Consistency between General Purpose Worklist, SPS, PPS and
Resulting Composite IODs in Post-Processing Workflow .................................................... 218
C.1 Integration-critical Attributes .......................................................................................... 218
Appendix D: Attribute Consistency between General Purpose Worklist, SPS, PPS and
Resulting Composite IODs In Reporting Workflow.............................................................. 221
D.1: Integration-critical Attributes.......................................................................................... 221
Appendix E:
DICOM Media Interchange – Critical DICOM Compatibility Tips ................ 224
Appendix F:
Example Created Media Instance Content ....................................................... 226
Appendix G: Configuration for Accessing DICOM, WADO and Web Services Retrieve
Services228
G.1: Mapping DICOM AE Title to DICOM AE Network Address ....................................... 228
G.2: Mapping DICOM AE Title to WADO Service Network Address ................................. 228
G.3: Mapping DICOM AE Title to Web Services Address.................................................... 229
Appendix H: Example Template for Teaching File Structured Report Manifests ................. 230
Appendix I:
De-identification, Re-identification, Pseudonymization, Persistence of
Identification and Clinical Trial Attributes (Informative) ..................................................... 234
I.1: De-identification ............................................................................................................. 234
I.2: Consistency of Identifiers on Repeated Export .............................................................. 234
I.3: Addition of Clinical Trial Attributes............................................................................... 235
GLOSSARY ............................................................................................................................... 236___________________________________________________________________________
13
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1 Introduction
550

555

560

565

570

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.

575

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
580

585

This document, the IHE Radiology Technical Framework, defines specific implementations ofestablished standards 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, and maintained 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 Radiology Technical Framework defines a subset of the functional components of thehealthcare enterprise, called IHE actors, and specifies their interactions in terms of a set ofcoordinated, standards-based transactions. It defines this body of transactions in progressively
greater depth. Volume 1 provides a high-level view of IHE functionality, showing thetransactions organized into functional units called Integration Profiles that highlight their___________________________________________________________________________
14
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

590

capacity to address specific clinical needs. Volume 2 provides detailed technical descriptions of
IHE transactions [RAD-1] through [RAD-31], along with a description of the conventions used
to define IHE transactions and an overview of the concepts of IHE actors and transactions.
Volume 3 provides detailed technical descriptions of IHE transactions [RAD-32] through [RAD75].

1.2 Overview of Volume 3
595

600

The body of this volume is a continuation of Section 4 in Volume 2. It defines transactions[RAD-32] through [RAD-75], specifying the roles for each actor, the standards employed, theinformation exchanged, 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 RAD TF-2:2. The
appendices following the main body of this volume provide clarification of technical details of
the IHE data model and transactions. The final section of the volume is a glossary of terms andacronyms used in the IHE Radiology Technical Framework, including those from relevant
standards (such as HL7®1, DICOM®2, IETF, W3C, ISO/CCITT, etc.).

1

HL7 is the registered trademark of Health Level Seven International.

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

2___________________________________________________________________________
15
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4 IHE Transactions
605

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

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.

620

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

625

630

635

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.
Note: although IHE specifies real-time charge posted transactions, batch processing can beaccommodated as per the batch specifications defined in HL7 v2.3.1 Chapter 2, sec. 2.23.2 or
HL7 v2.5.1 Chapter 2, sec 2.10.2.
___________________________________________________________________________
16
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.35.2 Use Case Roles
DSS/Order
FillerChargeProcessor

ChargePosted640

Actor: Department System Scheduler/Order Filler
Role: Collects information relevant to the posting of charges and submits it to the Charge
Processor.
Actor: Charge Processor
645

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.
4.35.3 Referenced Standards
Health Level Seven, Version 2.3.1: Chapter 6 - Financial Management
Health Level Seven, Version 2.5.1: Chapter 6 – Financial Management

650

DICOM PS3.4 Modality Performed Procedure Step SOP Class
4.35.4 Messages
DSS/Order
FillerChargeProcessor
Charge Posted
DFT^P03

Figure 4.35.4-1: Interaction Diagram

4.35.4.1 Financial Transaction Message
655

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

660

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 –___________________________________________________________________________
17
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Technical and Professional. Each can be triggered at a separate time or both can be sent at thesame time - depending on the site configuration.
•

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.

665

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.

670

675
•

680

685

Technical Billing

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
690

695

Message Semantics

This transaction defines both HL7 v2.3.1 Message Semantics and HL7 v2.5.1 Message
Semantics. Except for the certain references and segment tables (which are labeled as "HL7v2.3.1" or "HL7 v2.5.1"), all requirements in this section apply to both HL7 v2.3.1 and HL7
v2.5.1. Profiles using this transaction will specify which message semantics its actors are
required to support.
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.
___________________________________________________________________________
18
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
700

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.

705

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

710

Note:

Detailed Financial
Transaction Message

Chapter in
HL7

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

PV1 is required if use of PV1-19 Visit Number is required per the applicable regional or national extensions 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 DFT
message to its sender. See RAD TF-2: 2.4.3 “Acknowledgement Modes” (HL7 v2.3.1) or RAD
TF-2: 2.4.4.1 “Acknowledgement Message” (HL7 v2.5.1) for definition and discussion of the
ACK message.
715

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 (HL7 v2.3.1) or
2.4.4.2 (HL7 v2.5.1) “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.

720

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 (HL7 v2.3.1) or RAD TF-2: 4.1.4.1.2.2.2 (HL7v2.5.1) for required and optional fields of the EVN segment.
4.35.4.1.2.3 PID Segment725

All of the fields in PID segment are optional, except those listed in Table 4.35-1 (HL7 v2.3.1) or
Table 4.35-1a (HL7 v2.5.1).

___________________________________________________________________________
19
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.35-1: IHE Profile - PID segment - HL7 v2.3.1
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

19

16

ST

O

00122

SSN Number - Patient

Adapted from the HL7 standard, version 2.3.1
Table 4.35-1a: IHE Profile - PID segment – HL7 v2.5.1
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

3

250

CX

R

00106

Patient Identifier List

5

250

XPN

R

00108

Patient Name

18

250

CX

C

00121

Patient Account Number

19

16

DT

O

01222

SSN Number - Patient

730

Adapted from the HL7 standard, version 2.5.1
At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued.
4.35.4.1.2.4 PV1 Segment735

All of the fields in PV1 segment are optional, except those listed in Table 4.35-2 (HL7 v2.3.1) or
Table 4.35-2a (HL7 v2.5.1).
Table 4.35-2: IHE Profile - PV1 Segment – HL7 v2.3.1
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
Table 4.35-2a: IHE Profile - PV1 Segment – HL7 v2.5.1
SEQ

LEN

DT

OPT

2

1

IS

R

19

250

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

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued.
___________________________________________________________________________
20
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.
4.35.4.1.2.5 FT1 Segment
745

The FT1 segment is used to post charges, credits, payments, and adjustments to patientaccounting records. The DSS/OF shall map values from ADT and ORM messages into the FT1segment as defined in Table 4.35-3) or Table 4.35-3a (HL7 v2.5.1).
Table 4.35-3: IHE Profile - FT1 Segment – HL7 v2.3.1
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

23

22

EI

R

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

Adapted from the HL7 standard, version 2.3.1
750

Table 4.35-3a: IHE Profile - FT1 Segment - HL7 v2.5.1
SEQ

LEN

DT

OPT

1

4

SI

O

TBL#

ITEM#
00355

ELEMENT NAME
Set ID - FT1___________________________________________________________________________
21
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

2

12

ST

O

00356

Transaction ID

3

10

ST

O

00357

Transaction Batch ID

4

53

DR

R

00358

Transaction Date

5

26

TS

R

00359

Transaction Posting Date

6

8

IS

R

0017

00360

Transaction Type

7

250

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

250

CE

O

0049

00367

Department Code

14

150

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

250

CE

O

0051

00371

Diagnosis Code - FT1

20

250

XCN

R

0084

00372

Performed By Code

21

250

XCN

R

00373

Order By Code

22

12

CP

O

00374

Unit Cost

23

427

EI

R

00217

Filler Order Number

24

120

XCN

O

00765

Entered By Code

25

250

CE

R

0088

00393

Procedure Code

26

250

CE

O

0340

01316

Procedure Code Modifier

27

250

CE

O

0339

01310

Advanced Beneficiary Notice Code

28

250

CWE

O

0476

01646

Medically Necessary Duplicate
Procedure Reason

29

250

CWE

O

0549

01845

NDC Code

30

250

CX

O

01846

Payment Reference ID

31

4

SI

O

01847

Transaction Reference Key

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

755

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. The
DSS/OF shall map values from ADT and ORM messages into the PR1 segment as defined inTable 4.35-4 or Table 4.35-4a (HL7 v2.5.1).
___________________________________________________________________________
22
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.35-4: PR1 Attributes – HL7 v2.3.1
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 (see note)

4

40

ST

O

00394

Procedure Description

5

26

TS

R

00395

Procedure Date/Time

6

2

IS

R

00396

Procedure Functional Type

7

4

NM

O

00397

Procedure Minutes

8

120

XCN

O

0010

00398

Anesthesiologist

9

2

IS

O

0019

00399

Anesthesia Code

10

4

NM

O

00400

Anesthesia Minutes

11

120

XCN

O

0010

00401

Surgeon

12

230

XCN

O

0010

00402

Procedure Practitioner

13

60

CE

O

0059

00403

Consent Code

14

2

NM

O

00404

Procedure Priority

15

80

CE

O

0051

00772

Associated Diagnosis Code

16

80

CE

O

0340

01316

Procedure Code Modifier (see
note)

0230

760

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

Table 4.35-4a: PR1 Attributes – HL7 v2.5.1
SEQ

LEN

DT

OPT

TBL#

1

4

SI

R

2

3

IS

R

3

250

CE

R

4

40

ST

O

5

26

TS

R

6

2

IS

R

7

4

NM

O

8

250

XCN

O

0010

9

2

IS

O

0019

10

4

NM

O

11

250

XCN

O

0010

12

250

XCN

O

13

250

CE

O

14

2

NM

O

15

250

CE

O

0051

16

250

CE

O

0340

ITEM#

ELEMENT NAME

00391

Set ID - PR1

0089

00392

Procedure Coding Method

0088

00393

Procedure Code (see note)

00394

Procedure Description

00395

Procedure Date/Time

00396

Procedure Functional Type

00397

Procedure Minutes

00398

Anesthesiologist

00399

Anesthesia Code00400

Anesthesia Minutes

00401

Surgeon

0010

00402

Procedure Practitioner

0059

00403

Consent Code

00404

Procedure Priority

00772

Associated Diagnosis Code

01316

Procedure Code Modifier (see
note)

0230

___________________________________________________________________________
23
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

LEN

17

20

18

250

19
20

DT

OPT

TBL#

ITEM#

IS

O

0416

01501

Procedure DRG Type

CE

O

0417

01502

Tissue Type Code

427

EI

C

01848

Procedure Identifier

1

ID

C

01849

Procedure Action Code0206

ELEMENT NAME

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

765

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

770

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

Modality Performed Procedure Step [RAD-7]
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.

775

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 Acquisition
Modality to ensure that the procedure information is sent to the Department System
Scheduler/Order Filler.

780

•
785

Order Management – HL7 order messages [RAD-3] and [RAD-3]

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.

___________________________________________________________________________
24
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.35-5: Mapping of the FT1 Segment
OPT

HL7 order
messages– [RAD-2]
and[RAD-3]Modality
Performed
Procedure
Step[RAD-7]Manual Input /Department
SystemScheduler/Order
FillerPerformed
Procedure Step
End Date(0040,0004) +Performed
Procedure Step
End Time(0040,0005)

Generated by
Department System
Scheduler/Order
Filler if there is noMPPS

FT1 Field

Field Definition

Transaction
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

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

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

___________________________________________________________________________
25
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

HL7 order
messages– [RAD-2]
and[RAD-3]Modality
Performed
Procedure
Step[RAD-7]Manual Input /Department
SystemScheduler/Order
FillerFT1 Field

Field Definition

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

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

PV1-3 –
AssignedPatient
Location(ADT)

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

___________________________________________________________________________
26
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

HL7 order
messages– [RAD-2]
and[RAD-3]This 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

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.

OFT1 Field

Field Definition

Filler Order
Number790

Modality
Performed
Procedure
Step[RAD-7]Manual Input /Department
SystemScheduler/Order
Filler

Procedure Code
Sequence (0008,
1032)
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.

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

Field Definition

OPT

Set 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

HL7 order
messages– [RAD-2]
and[RAD-3]Modality
Performed
Procedure
Step[RAD-7]Manual Input /Department
SystemScheduler/Order
Filler
Generated by
Department System
Scheduler/Order
FillerBilling
Procedure Step
Sequence(0040,0320)

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

___________________________________________________________________________
27
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

HL7 order
messages– [RAD-2]
and[RAD-3]Modality
Performed
Procedure
Step[RAD-7]Manual Input /Department
SystemScheduler/Order
FillerPerformed
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.

PR1 Field

Field Definition

Procedure
Date/Time

This field contains thedate/time that the procedure
was performed

R

Procedure
FunctionalType

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

R

Generated by
Department System
Scheduler/Order
Filler.

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.3 Expected Actions
The Charge Processor will receive and process the technical billing or professional billing details
in the DFT message according to the capabilities of its application. This processing is not definedor constrained by IHE.
795

4.36 Account Management [RAD-36]
This section corresponds to transaction [RAD-36] of the IHE Radiology Technical Framework.
Transaction [RAD-36] is used by the ADT Patient Registration and Charge Processor actors.
___________________________________________________________________________
28
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.36.1 Scope800

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.

805

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.
Actor: Charge Processor
810

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 Management
4.36.4 Messages
ChargeProcessor

ADT Patient
Registration

Account Management
BAR^P01, P05, P06

815

Figure 4.36.4-1: Interaction Diagram___________________________________________________________________________
29
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.36.4.1 Account Management - New Account820

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

825

830

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•

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

835

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.

840

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.

845

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)___________________________________________________________________________
30
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________BAR Segment

Billing Account

Chapter in HL7 2.3.1[{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 extensions to the
IHE Radiology Technical Framework (see RAD TF-4).

850

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

855

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

860

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

Adapted from the HL7 standard, version 2.3.1
865

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.
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___________________________________________________________________________
31
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
870

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

875

880

4.36.4.1.2.5 DG1 Segment
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.
Table 4.36-3: IHE Profile - DG1 Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

4

SI

R

00375

Set ID - DG1

2

2

ID

O

0053

00376

Diagnosis Coding Method

3

60

CE

O

0051

00377

Diagnosis Code - DG1

4

40

ST

O

00378

Diagnosis Description

5

26

TS

O

00379

Diagnosis Date/Time

6

2

IS

R

0052

00380

Diagnosis Type

7

60

CE

O

0118

00381

Major Diagnostic Category

8

60

CE

O

0055

00382

Diagnostic Related Group

9

2

ID

O

0136

00383

DRG Approval Indicator

10

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
885

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.
___________________________________________________________________________
32
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.36-4: IHE Profile - GT1 Segment
SEQ

LEN

DT

OPT

1
2

TBL#

4

SI

R

00405

Set ID - GT1

59

CX

O

00406

Guarantor Number

3

48

XPN

R

00407

Guarantor Name

4

48

XPN

O

00408

Guarantor Spouse Name

5

106

XAD

O

00409

Guarantor Address

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

13

8

DT

O

00417

Guarantor Date - Begin

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

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

24

26

TS

O

25

1

ID

O

26

80

CE

O

27

10

CP

28

3

29

20

30

80

CE

O

31

8

DT

32

8

DT

33

2

IS

O

34

2

IS

35

80

CE

36

60

37

2

0066

ITEM#

ELEMENT NAME

00774

Guarantor Credit Rating Code

00775

Guarantor Death Date And Time

0136

00776

Guarantor Death Flag

0218

00777

Guarantor Charge Adjustment
Code

O

00778

Guarantor Household Annual
Income

NM

O

00779

Guarantor Household Size

CX

O

00780

Guarantor Employer ID Number

00781

Guarantor Marital Status Code

O

00782

Guarantor Hire Effective Date

O

00783

Employment Stop Date

0223

00755

Living Dependency

O

0009

00145

Ambulatory Status

O

0171

00129

Citizenship

CE

O

0296

00118

Primary Language

IS

O

0220

00742

Living Arrangement0002___________________________________________________________________________
33
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

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

49

20

ST

O

50

20

JCC

O

51

130

XON

O

52

2

IS

O

53

2

IS

O

54

50

FC

55

80

CE

00784

Contact Relationship00785

Job Title

00786

Job Code/Class

01299

Guarantor Employer’s
Organization Name

0295

00753

Handicap

0311

00752

Job Status

O

0064

01231

Guarantor Financial Class

O

0005

01291

Guarantor Race

0327/
0328

4.36.4.1.2.7 IN1 Segment
890

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

1

4

SI

R

2

60

CE

R

3

59

CX

4

130

5

106

6

TBL#

ITEM
#

ELEMENT NAME

00426

Set ID - IN1

00368

Insurance Plan ID

R

00428

Insurance Company ID

XON

O

00429

Insurance Company Name

XAD

O

00430

Insurance Company Address

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

0072___________________________________________________________________________
34
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
TBL#

ITEM
#

SEQ

LEN

DT

OPT

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

27

2

IS

O

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

0086
0063

0136
0136
0093

0042

ELEMENT NAME___________________________________________________________________________
35
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.36.4.1.3
895

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

900

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

905

910

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

915

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

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

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

___________________________________________________________________________
36
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

925

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

930

4.36.4.2.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.36.4.2.2.3 PID Segment

935

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

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

945

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 extensions 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.
___________________________________________________________________________
37
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.36.4.2.2.5 DG1 Segment
See Section 4.36.4.1.2.5 for required and optional fields of the DG1 segment.
950

4.36.4.2.2.6 GT1 Segment
See Section 4.36.4.1.2.6 for required and optional fields of the GT1 segment.
4.36.4.2.2.7 IN1 Segment
See Section 4.36.4.1.2.7 for required and optional fields of the IN1 segment.
4.36.4.2.3

955

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.
4.36.4.3 Account Management – End Account
4.36.4.3.1

960

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

965

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.

The segments of the End Account message listed below are required, and the detailed
description of messages is provided in the following subsections.
970
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)

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

975

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.
___________________________________________________________________________
38
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.36.4.3.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 value of P06.
980

4.36.4.3.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.36.4.3.2.3 PID Segment985

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

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

995

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

1000

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.
___________________________________________________________________________
39
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

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

1010

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

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

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 PS3.4: General Purpose Worklist SOP Class___________________________________________________________________________
40
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.37.4 Messages
Post-Processing
Manager

Evidence Creator

Query GP Worklist
Receive GP Worklist

1025

Figure 4.37.4-1: Interaction Diagram

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
1030

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

1035

Trigger Events

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

1040

1045

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
one or more keys. The sequence attributes denoted in the italics are not matching keys on theirown but have to be included in a query to convey the value of the attributes contained withinthem. Thus, the SCU shall support any combination of Patient’s Name, Patient ID, Accession
Number, Requested Procedure ID, and Scheduled Workitem Code.

___________________________________________________________________________
41
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
1050

Table 4.37-1: GPWL Keys for Patient Oriented QueryMatching Key Attributes

1055

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

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)

1060

1065

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.

___________________________________________________________________________
42
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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
1070

1075

•

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.

1080

4.37.4.1.2.3 Matching Keys and Return KeysThe 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.

1085

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

Query Keys
Matching

Tag

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

___________________________________________________________________________
43
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

SCU
SOP Instance UID(0008,0018)

Query Keys Return

SCP

SCU

SCP

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

>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)___________________________________________________________________________
44
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

SCU

Query Keys Return

SCP

SCU

SCP

>>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)>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
Sequence(0040,4009)

O

O

O

R

>>Code Value(0008,0100)

O

O

O

R

___________________________________________________________________________
45
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

SCU>>Coding Scheme Designator(0008,0102)

O

Query Keys Return

SCP
O

SCU
O

SCP
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
Patient Identification
Patient's Name

(0010,0010)

R+

R

R+

R

Patient ID(0010,0020)

R+

R

R+

R

O

O

O

O

O

O

R+

R

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

(0010,0030)___________________________________________________________________________
46
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

SCU
Patient's Sex(0010,0040)

All other Attributes from thePatient Demographic Module

Query Keys Return

SCP

SCU

SCP

O

O

R+

R

O

O

O

O

O

O

O

O

Patient Medical
All Attributes from the Patient
Medical Module

4.37.4.1.3
1090

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.

1095

4.37.4.2.1

Trigger Events

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

1100

1105

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:
Table 4.37-5: Post-Processing Workitem Definition
Coding Scheme Designator(0008,0102)

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___________________________________________________________________________
47
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.37.4.2.3
1110

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 [RAD-38]
1115

This section corresponds to transaction [RAD-38] of the IHE Radiology Technical Framework.
Transaction [RAD-38] is used by Post-Processing Manager, Report Manager, Report Creator andEvidence Creator.
4.38.1 Scope

1120

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.

1125

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

ReportCreatorActor: Evidence Creator
1130

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.
Actor: Report Creator___________________________________________________________________________
48
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
1135

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.
4.38.3 Referenced Standards

1140

DICOM PS3.4: General Purpose Scheduled Procedure Step SOP Class.
4.38.4 Messages
Post-Processing
Manager

Evidence
CreatorGP-SPS N-ACTION

Report Manager

Report Creator
GP-SPS N-ACTION

Figure 4.38.4-1: Interaction Diagram

1145

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

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

1155

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,___________________________________________________________________________
49
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________and the associated status of SUSPENDED or SCHEDULED will be set (see the DICOM Part 4,
Section F.1.6 for additional information).
1160

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.
If a human is performing the Post-Processing scheduled procedure step, then the N-ACTION
request may include the Actual Human Performers Sequence.

1165

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

1170

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.

1175

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.

1180

4.39 Workitem Performed Procedure Step In Progress [RAD-39]
This section corresponds to transaction [RAD-39] of the IHE Radiology Technical Framework.
Transaction [RAD-39] is used by Post-Processing Manager and Evidence Creator as well as
Report Manager and Report Creator.
4.39.1 Scope

1185

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

___________________________________________________________________________
50
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
1190

4.39.2 Use Case Roles
Evidence
CreatorPost-Processing
Manager

Workitem PPS inprogress
ReportManager

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

Actor: Report Manager
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.

1200

Actor: Post-Processing Manager
Role: Accept post-processing PPS information from the Evidence Creator.
4.39.3 Referenced Standards
DICOM PS3.4: General Purpose Performed Procedure Step SOP Class
4.39.4 Messages

1205___________________________________________________________________________
51
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Evidence
CreatorPost-Processing
Manager

GP-PPS N-CREATE

Report Creator

Report Manager

GP-PPS N-CREATE

Figure 4.39.4-1: Interaction Diagram

4.39.4.1 General Purpose Performed Procedure Step In Progress Message
4.39.4.1.1
1210

Trigger Events

For a post-processing workitem, a user or an automated function on the Evidence Creator begins
a post-processing performed procedure step.
For a reporting workitem, a user begins to perform the scheduled procedure step at the ReportCreator.
4.39.4.1.2

1215

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

1220

Message Semantics

Expected Actions

The Post-Processing Manager or the Report Manager creates the PPS with status IN
PROGRESS.
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.

1225

The Post-Processing Manager may use the Performed Work Status Update transaction to notify
the interested recipients about the received GP-PPS.
The Report Manager may use the Performed Work Status Update transaction to notify theinterested recipients about the received GP-PPS using for this purpose.
___________________________________________________________________________
52
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.39.4.1.3.1 Relationship between Scheduled and Performed Procedure Steps
1230

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

1

SPS

1235

1

resultsin

PPS

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

1

Append Case
results in

1

1-n

1250

PPS

Unscheduled Case
0

SPS

1245

1

results
inThis 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.
4.39.4.1.3.1.2

1240

Simple CasePPS atEvidence Creator or
Report Creator
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.
___________________________________________________________________________
53
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________No PPS can be appended if the SPS status is COMPLETED or DISCONTINUED.
4.39.4.1.3.1.4

SPS

1255

1260

Abandoned Case1

1resultsin

PPS

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
attributes shall be copied from the Scheduled Procedure Step Object to the Performed Procedure
Step Relationship Module.

4.40 Workitem Performed Procedure Step Completed [RAD-40]
1265

This section corresponds to transaction [RAD-40] of the IHE Radiology 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

1270

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

1275

ReportManager

ReportCreator___________________________________________________________________________
54
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Actor: Evidence Creator
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
1280

Role: Accept post-processing PPS information from the Evidence Creator.
Actor: Report Creator
Role: Updates Report Manager with status of the Reporting Workitem PPS, when it finishes ordiscontinues work.
Actor: Report Manager

1285

Role: Accepts PPS information from Report Creator.
4.40.3 Referenced Standards
DICOM PS3.4: General Purpose Performed Procedure Step SOP Class
4.40.4 Messages
Evidence
CreatorPost-Processing
Manager

GP-PPS N-SET

Report Manager

Report Creator

GP-PPS N-SET

1290

Figure 4.40.4-1: Interaction Diagram

4.40.4.1 General Purpose Performed Procedure Step Completed Message
4.40.4.1.1

Trigger Events

For a post-processing workitem, automated Evidence Creator, or a user finishes the postprocessing scheduled procedure step.
1295

For a reporting Workitem, a user finishes the work on the scheduled procedure step.

___________________________________________________________________________
55
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.40.4.1.2

1300

1305

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

1310

1315

1320

Message Semantics

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

4.41 Workitem Completed [RAD-41]
1325

This section corresponds to transaction [RAD-41] of the IHE Radiology 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

1330

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.
___________________________________________________________________________
56
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1335

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
1340

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.
Actor: Report Creator

1345

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
DICOM PS3.4: General Purpose Scheduled Procedure Step SOP Class

1350

4.41.4 Messages___________________________________________________________________________
57
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Evidence
CreatorPost-Processing
Manager

GP-SPS N-ACTION

Report Manager

Report Creator

GP-SPS N-ACTION

Figure 4.41.4-1: Interaction Diagram

4.41.4.1 General Purpose SPS Completed Message
1355

4.41.4.1.1

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

1365

1370

4.41.4.1.2

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

1375

Message Semantics

Expected Actions

The Post-Processing Manager or the Report Manager updates the status of the SPS to
COMPLETED or DISCONTINUED.
___________________________________________________________________________
58
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________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 [RAD-42]
1380

This section corresponds to transaction [RAD-42] of the IHE Radiology Technical Framework.
Transaction [RAD-42] is used by the Department System Scheduler, Report Manager and ImageManager.
4.42.1 Scope

1385

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.
How or whether the non-managing system uses this information is at the discretion of
implementers and customers. Some examples are given below:•

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.

1390

1395

4.42.2 Use Case Roles
Department System
Scheduler/PostProcessing Manager

ReportManagerImage
Manager/PostProcessing Manager

Performed Work
Status Update

1400
Actor: Department System Scheduler
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 of___________________________________________________________________________
59
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1405

tasks managed by the Image Manager or Report Manager it must be ready to receive task status
notifications.
Actor: Image Manager

1410

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

1415

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.
4.42.3 Referenced Standards
DICOM PS3.4: General Purpose Performed Procedure Step SOP Class___________________________________________________________________________
60
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.42.4 Messages
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-SETImage Manager /Post-Processing Manager
Scenario B

Department
System Scheduler

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

1420

Figure 4.42.4-1: Interaction Diagram___________________________________________________________________________
61
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.42.4.1 Post-Processing Performed Procedure Step Created/Updated Message
4.42.4.1.1
1425

1430

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

1435

1440

1445

1450

1455

1460

Trigger Events

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.
___________________________________________________________________________
62
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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).
1465
Table 4.42-1: Context ID 9231 – General Purpose Workitem Definition
Coding Scheme Designator(0008,0102)

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

4.43 Evidence Document Stored [RAD-43]
This section corresponds to transaction [RAD-43] of the IHE Radiology Technical Framework.
Transaction [RAD-43] is used by the Acquisition Modality and Evidence Creator actors.
4.43.1 Scope1475

In the Evidence Documents Stored transaction, the Acquisition Modality or the Evidence Creatortransmits an Evidence Document, which is stored in the Image Archive.
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.

1480

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.

___________________________________________________________________________
63
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Evidence
Creator

Image
Archive

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

Role: Records non-imaging evidence information in the Evidence Documents and stores them tothe Image Archive.
Actor: Image Archive
Role: Accepts and Stores Evidence Document Instances received from the Acquisition Modality
or Evidence Creator.

1495

4.43.3 Referenced Standards
DICOM PS3.4: Storage Service Class; Basic Text SR SOP Class; Enhanced SR SOP Class;Comprehensive SR SOP Class; Chest CAD SR SOP Class; Mammography CAD SR SOP Class;
OB-GYN Ultrasound Procedure Reports; Catheterization Lab SR; Vascular Ultrasound SR.

1500

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.
4.43.4 Messages
Acquisition
Modality

Image
Archive

Evidence Document Stored

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

Figure 4.43.4-1: Interaction Diagram___________________________________________________________________________
64
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.43.4.1 Evidence Document Stored
1505

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

Trigger Events

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

4.43.4.1.2

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

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

1520

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

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.
___________________________________________________________________________
65
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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.
1530

1535

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 Documents [RAD-45]
transaction, Section 4.45.4.2.3.1.

4.44 Query Evidence Documents [RAD-44]
1540

This section corresponds to transaction [RAD-44] of the IHE Radiology 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.

1545

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
1550

Role: Respond to queries from the Image Display for Evidence Documents objects.
4.44.3 Referenced Standards
DICOM PS3.4: Query/Retrieve Service Class___________________________________________________________________________
66
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.44.4 Messages
Image Archive

Image Display

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

1555

Figure 4.44.4-1: Interaction Diagram

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

4.44.4.1.1

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

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

1570

In addition to the required and unique keys defined by the DICOM Standard, the IHE Radiology
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 are defined 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+

___________________________________________________________________________
67
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1575

Tag

Query Keys Matching

Query Keys Return

SCU

SCU

SCP

SCP

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+

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

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 [RAD-45]
1585

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

1590

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.

___________________________________________________________________________
68
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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.
1595

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: Imaging Document Consumer

1600

Role: Receives requested Evidence Documents from the Imaging Document Source
4.45.3 Referenced Standards
DICOM PS3.4: Query/Retrieve Service Class, Storage SOP Class
4.45.4 Messages
Image Archive

Image Display

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

1605

Figure 4.45.4-1: Interaction Diagram

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___________________________________________________________________________
69
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1610

1615

be used as Evidence Documents. The Imaging Document Source as an SCU shall support
DICOM Storage SOP Classes that may be used as Evidence Documents it published for sharing.
Refer to DICOM PS3.4 Annex C for detailed descriptive semantics (see Table 4.38-1).
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) needs to be exchanged between the Imaging
Document Source and the Imaging Document Consumer. Appendix G describes in detail 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.
1620

4.45.4.1.2

1625

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the
DICOM PS3.4: Query/Retrieve Service Class. It is the responsibility of the Image Manager or
Imaging Document Source to assure that the patient and procedure information is current in the
Evidence Document objects when they are retrieved from the Image Archive or Imaging
Document Source.
4.45.4.1.3

Message Semantics

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

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.

1635

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

1640

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

Invocation Semantics

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___________________________________________________________________________
70
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
1645

Document Consumer to present Evidence Documents for viewing by the user is outside thescope of the IHE Radiology Technical Framework. For example, in the case when an Image
Display or an Imaging Document Source is grouped with an Evidence Creator, the Evidence
Document may be rendered as input for further processing by the Evidence Creator.
4.45.4.2.3

1650

1655

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.

1660

1665

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

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
data that 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 [RAD-46]
1675

This section corresponds to transaction [RAD-46] of the IHE Radiology Technical Framework.
Transaction [RAD-46] is used by Report Manager and Report Creator.
4.46.1 Scope

1680

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.
___________________________________________________________________________
71
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1685

1690

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

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.

1700

4.46.3 Referenced Standards
DICOM PS3.4: General Purpose Worklist SOP Class
4.46.4 Messages
Report Manager

Report Creator

Query GP Worklist
Receive GP Worklist

Figure 4.46.4-1: Interaction Diagram

1705___________________________________________________________________________
72
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.46.4.1 Query General Purpose Worklist Message
This is the worklist query sent to the Report Manager.
4.46.4.1.1
1710

Trigger Events

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

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

4.46.4.1.2.1 Matching Keys and Return Keys
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.

1720

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:

1725

1. Patient Oriented Query: Query for a worklist for a specific patient/procedure. The
SCU shall support 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 notmatching keys on their own but have to be included in a query to convey the value of theattributes contained within them. Thus, the SCU shall support any combination ofPatient’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

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)

1730
2. User-oriented Query: Query for a broad worklist for particular user being logged inon a particular station. The SCU shall support all (63) combinations of the matching key___________________________________________________________________________
73
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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 aquery 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 theworkstation’s General Purpose Worklist SCU.

1735

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
1740

1745

•

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.

1750

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.
___________________________________________________________________________
74
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
1755

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.
Table 4.46-3: Matching and Return Keys for Report Worklist Queries
Attribute Name

Query Keys
Matching

Tag

Query Keys
Return

SCU

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

___________________________________________________________________________
75
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

Query Keys
Return

SCU

SCP

SCU

(0040,4005)

R+

R

R+

R

Expected Completion Date and Time(0040,4011)

O

R

O

R

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

Scheduled Procedure Step Start Date and Time

SCP>>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 Sequence(0040,4009)___________________________________________________________________________
76
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

Query Keys
Return

SCU

SCP

SCU

SCP

>>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 the General Purpose
Scheduled Procedure Step Information Module
General 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 Module
Patient Relationship
All Attributes from the Patient Relationship
ModulePatient 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 the Patient
Identification Module
Patient Demographic
Patient's Birth Date

(0010,0030)

O

O

R+

R

Patient's Sex(0010,0040)

O

O

R+

R

___________________________________________________________________________
77
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Query Keys
Matching

Tag

All other Attributes from the Patient
Demographic Module

Query Keys
Return

SCU

SCP

SCU

SCP

O

O

O

O

O

O

O

O

Patient Medical
All Attributes from the Patient Medical Module

1760

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
1765

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
1770

1775

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:
Table 4.46-4: Reporting Workitem Definition
Coding Scheme Designator(0008,0102)

Code Meaning (0008,0104)

DCM

110005Interpretation

DCM

110006

Transcription

DCM

110007

Report Verification

DCM

110009No subsequent Workitems

4.46.4.2.3
1780

Code Value (0008,0100)

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___________________________________________________________________________
78
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
will notify the Report Creator of the work progress as defined in the Workitem Claimed andWorkitem Completed transactions.

4.47 Distribute Imaging Information on Media [RAD-47]
1785

This section corresponds to transaction [RAD-47] of the IHE Radiology 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).
4.47.1 Scope1790

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

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

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.
Actor: Report Reader

1805

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___________________________________________________________________________
79
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
1810

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
DICOM PS3.10: Media Storage and File Format for Data Interchange

1815

DICOM PS3.11: Media Storage Application Profiles
DICOM PS3.12: Media Formats and Physical Media for Data Interchange
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.

1820

XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtmbasic.
4.47.4 Messages

Figure 4.47.4-1: Interaction Diagram

1825

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.

___________________________________________________________________________
80
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.47.4.1.1 Trigger Events
1830

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
The message semantics of this transaction are described in terms of content specifications forthe media.

1835

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.
4.47.4.1.2.1 Media Filesystem and File Naming Restrictions

1840

1845

1850

Since the DICOM content on the media is required to conform to the DICOM standard, someof the requirements specified in DICOM PS3.10, 3.11 and 3.12 are reiterated here for
emphasis:•

Strict ISO 9660 Level 1 compliance with respect to file naming•

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 for a reference to common implementation misinterpretations and/or
errors that are detrimental to interoperability.

1855

Non-DICOM data is restricted to ISO 9660 Level 1 compliance for media encoded with ISO
9660 rather than UDF or FAT filesystems, but without the restrictions on file extensions andcharacters 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):1860___________________________________________________________________________
81
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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:
4.47.4.1.2.2.1 DICOM Content
1865

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.

1870

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:

1875

•

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

1880

An informative header containing:•

Identification of the institution that created the interchange media•

Optionally, a link to an Internet-accessible site where, with the appropriate
authentication and access control, a user may view the most recent version(s) of___________________________________________________________________________
82
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
the report(s) about the media content, since any report content on the media may
have been amended

1885

•

a link to an entry point for accessing the web content of the IHE_PDI directory•a link to the README.TXT file•a link to additional non-constrained data (if it exists) - See Section 4.47.4.1.2.2.3•

a manifest which lists the data that can be imported by a Portable Media Importer.
(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

1890

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.

1895•

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.

1900

1905

1910

•

Name of the product application and software version•

Contact information of the vendor of the application that created the media•

General information about the overall organization of the interchange media. This is
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)•

Operating system(s) supported•

Name of the product application and software version•

Contact information of vendor that provided the application•

List of minimum requirements•

Additional information regarding the usage of the application

Note that generally the README.TXT file is independent of the clinical content of the media, i.e., the same
README.TXT may be included on all media created by that application at that institution.
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.

1915

•

IHE_PDI directory located in the root directory of the interchange media which shallcontain:___________________________________________________________________________
83
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1920

•

Web-viewable objects in XHTML, JPEG, PNG and/or GIF derived from the DICOM
encoded objects or used for web page navigation (see Section 4.47.4.1.2.3.2).

•

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.

•

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.

1925

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

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 not specified by other IHE profiles(such as XDM) cannot begin with “IHE”, and those folders shall not be used by PDI.
1935

Additional files (files other than mandatory files) in the root directory are not expressly
prohibited however their inclusion is discouraged. Any viewing application on the media shallhave a minimum number of files and launch file in the root directory. Any supporting files shallbe contained in a minimum number of sub-directories in the root directory.
Note that it cannot be assumed that any automatically launching application will run on thereceiving device.

1940

4.47.4.1.2.2.3.1 DICOM Media Viewer
If a DICOM media viewer is present on the media, it is recommended that:

1945

•

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

4.47.4.1.2.2.4 Media Identification
The Portable Media Creator 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.
1950

It is recommended that the following be marked on the medium:___________________________________________________________________________
84
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1955

•

Patient Name•

Patient ID•

birthdate•media creation date•the study dates for the studies on the medium and•the name of the originating institution

If the Media Creator prints a label on, or to be applied to, the physical media, then the label shall
include information about the type of content and which options are used by the Portable MediaCreator:1960•

The type of content (“DICOM” or “DICOM WEB”)•

If the DVD Option is used by the Portable Media Creator

1965
•

1970

1975

•

if the physical media is not a CD, then the label shall include an indication that a
DVD drive is required to read the media.

•

if compression is used, then the label shall include an indication of which compressed
Transfer Syntax (e.g., JPEG or JPEG 2000) was used.

For example, a typical label might include:•

St. Elsewhere’s Radiology•

John Smith #54672354 1973/04/02•

CT Brain 2009/05/13•

Recorded 2009/05/14 710•

IHE PDI DICOM WEB DVD J2K BIR•

For media that is physically small (e.g., a USB memory stick that is not packaged in alarger form, such as credit card size), it may be difficult to fit the required andrecommended information, in which case only the required information should be used.

•

The labelling requirements and recommendations apply to the physical media itself andany directly applied label; it is not sufficient merely to label the package in which themedia is transported, since the media may become separated from the package.

4.47.4.1.2.3 Content Organization Detail4.47.4.1.2.3.1 DICOM Content
1980

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.
___________________________________________________________________________
85
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

1985

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, unless the DVD or USB Options are specified (seeSection 4.47.4.1.4).
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.

1990

1995

2000

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, unless the DVD or USB Options are
specified (see Section 4.47.4.1.4). The DICOMDIR, whose content is entirely the responsibilityof the Portable Media Creator, shall be correctly encoded regardless of the correctness of any
referenced SOP Instances.
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 for the STD-GEN-CD Media Storage Application Profile are listed in Table 4.47.41.
Table 4.47.4-1: Optional or Empty DICOM SOP Instance Attributes required in DICOMDIR
Directory Record Type

(0010,0020)

STUDY

Study ID

(0020,0010)

Study Date

(0008,0020)

Study Time

(0008,0030)

Modality(0008,0060)

Series Number(0020,0011)

Instance Number(0020,0013)

IMAGE

2010

Tag

Patient ID

SERIES

2005

Attribute Name

PATIENTThe DVD and USB Options contain additional such Attributes that are optional in the SOPInstance but are required in the DICOMDIR (see Section 4.47.4.1.4).
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. Implementers___________________________________________________________________________
86
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2015

must 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 uniqueStudy UID values. The Portable Media Creator is not required to add these synthesized values tothe instances to be stored on media.

2020

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.

2025

2030

If the Portable Media Creator is grouped with an Acquisition Modality (or other) within the
Scheduled Workflow Integration Profile, then the attributes may effectively be constrained
beyond the normative requirements of the DICOM standard. For example, certain attributevalues 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:

2035

2040

2045

•

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 Class•Stored Print Storage SOP Class

The Media Creator shall not change the values of the stored pixels, though it may change theencoding. It is required that images on the PDI media be of diagnostic quality (RAD TF-1:15.4),
hence for Options that support the use of lossy (irreversible) image compression, the Portable
Media Creator shall not:apply lossy compression to images just for the purpose of exchange (e.g., to fit on the
media or to accelerate load time); images can be encoded in lossy compressed form if andonly if this is the form in which they had been made available to the Portable MediaCreator (see also Media Exchange Certification Project of the German RadiologicalSociety rule 3.1.3.8 http://www.dicom-cd.de/docs/DRG-RequirementsSpecification2006.pdf).
___________________________________________________________________________
•

2050

87
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________•
2055

alter the bit depth or rescaling or color space of an image in such a manner that
information is lost in order to allow compression (lossless or lossy) to be applied (e.g., tochange an image containing 16 bits of data to 12 bits to allow JPEG compression to be
applied).

4.47.4.1.2.3.1.2 DICOMDIR Directory Content
There are no additional DICOMDIR keys required beyond those required by the DICOM STDGEN-CD specification, or the appropriate profile used with the DVD or USB Options (seeSection 4.47.4.1.4).
2060

No private elements shall be included in the standard directory records and no private directory
records shall be present.
The following types of Directory shall not be used in the Basic Directory object (DICOMDIRFile):

2065

2070

•

VISIT

•

RESULTS•

INTERPRETATION•STUDY COMPONENT•STORED PRINT

•

TOPIC

•

PRIVATEThe PATIENT, STUDY, SERIES Directory Records shall follow the following rules:

2075

2080

•

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.
___________________________________________________________________________
88
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2085

There is no requirement to include Icon Image Sequences in DICOMDIR Directory Records.
However, their presence at the SERIES level, or the IMAGE level for multi-frame images, may
be helpful to improve performance in a viewer that provides visual information for the user tonavigate. Accordingly, it is strongly recommended that such Icon Image Sequences be present,
without causing excessive increase in size of the DICOMDIR file.

2090

Note:

The Transfer Syntax for the DICOMDIR is always Explicit VR Little Endian, and this precludes the use of any
form of compression for Icon Image Sequences in the DICOMDIR, since the Transfer Syntax that defines theencoding of the nested Pixel Data is the same for the top level data.

4.47.4.1.2.3.1.3 DICOM Report Content
It is possible to place diagnostic reports on the media.
2095

2100

2105

Note:

The report on or accompanying the media may be obsolete if a report is amended or corrected subsequently.
Other means that recording on media are widely used to distribute up to date reports (e.g., fax and email), and it
is potentially unsafe to rely on the report on media for clinical decision making.

The Portable Media Creator, if grouped with a Report Creator, shall support the ability to createa 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 be created and thiskind of diagnostic report can be imported by a Portable Media Importer.
Additional optional diagnostic reports in non-DICOM formats (such as HL7 CDA®3) are notdefined by this transaction and may be placed on the media without the need to create DICOM
SRs or DICOM Encapsulated PDF or DICOM Encapsulated CDA, but they will be nonimportable data. See also the Cross-Enterprise Document Sharing Media Interchange (XDM)
Profile in the IHE ITI Technical Framework.
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.

2110

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

2115

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

2120

3

contain the web representation of a subset that faithfully preserves the clinical intent of
the media’s DICOM information, using only XHTML files, JPEG referenced images, andPNG and/or GIF files used for navigation,

CDA is the registered trademark of Health Level Seven International.

___________________________________________________________________________
89
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2125

2130

2135

•

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), and•be 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. While it may be a subset, merely
listing the contents is insufficient to satisfy this requirement, and if DICOM images are present
on the media, for example, there shall be images in the Web Content. Though not required to beof diagnostic quality, Web Content images shall be a faithful representation and not excessively
compressed nor excessively small (e.g., a 32x32 image of a 512x512 original would not be afaithful representation). For multi-frame original images, a sufficient number of frames shall berendered to be a faithful representation.
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.

2140

2145

2150

2155

2160

To ensure interoperability, JPEG means a file with a JFIF header and encoded using the sequential
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, bywhich it is meant that the static content shall be understandable as a faithful representation of theclinical condition without JavaScript.
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 that works
with or adapts to all known portable browsers; further, the failure of CSS should not make theresulting web pages unusable, by which it is meant that the static content shall be understandable
as a faithful representation of the clinical condition without CSS.
Additional optional web-viewable content not derived from DICOM objects may be stored on the
media, but not in the IHE_PDI directory.
___________________________________________________________________________
90
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.47.4.1.2.3.3 Content when Grouping with XDM (IHE ITI Technical Framework)
A PDI Portable Media Creator that is grouped with a Portable Media Creator in the ITI CrossEnterprise Document Sharing on Media (XDM) Profile is able to create media with combined
DICOM and XDM content. The grouped actor will be referred to as the Portable Media Creator.
2165

2170

The Portable Media Creator shall assemble the necessary PDI content according to thespecification in ITI TF-2b: 3.32.4.1 with the following additional requirements:•

The content of the INDEX.HTM and README.TXT files of PDI and XDM shall bemerged to one INDEX.HTM and one README.TXT file. The resulting files shall meet
all requirements of both profiles (PDI and XDM).

•All DICOM instances shall be referenced by a Key Object Selection (KOS) instance witha document title of (113030, DCM, "Manifest"). This helps the Portable Media Importerto recognize such a KOS instance (see Section 4.47.4.1.3.4) during the import process
and distinguish it from any other KOS instances , e.g., Key Image Notes (KIN). If amanifest KOS instance is not available, it shall be created by the Portable Media Creator.
The XDM Manifest METADATA.XML then references the KOS instance which in turnreferences multiple DICOM instances . In cases where multiple patients/ studies are
stored on the media, there may be multiple Manifest KOS instances in order todistinguish the patients/ studies during import.

•

Each Manifest KOS instance shall be referenced in the METADATA.XML file asdefined in the XDM Profile.

•

The Manifest KOS instance(s) shall be stored in the DICOM sub-directory of the PDI
media structure and referenced in the DICOMDIR file as specified in Section
4.47.4.1.2.2.1.

2175

2180

2185

Note: Although it is not prohibited to reference in the METADATA.XML all of the DICOM
instances, this is not recommended since it is redundant with the content of the KOS instance, it
increases the bulk of the METADATA.XML, and it raises the risk of inconsistency between the
two lists.

2190

Figure 4.47.4.1.2.3.3-1 illustrates the processing chain for the Portable Media Creator.

___________________________________________________________________________
91
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Figure 4.47.4.1.2.3.3-1: Processing Chain - Portable Media Creator

4.47.4.1.3 Expected Actions
2195

2200

The receiving/reading actors (Portable Media Importer, Image Display, Report Reader, Print
composer and Display) 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.
To facilitate avoidance of malicious software, receiving actors are not required to launch
automatically running applications present on media.

2205

4.47.4.1.3.1 Expected Actions Common to All Actors
All receiving actors that support the DVD Media Option or the USB Media Option shall be able
to read all types of media and Transfer Syntaxes specified in the corresponding DICOM Media
Application Profiles defined for the option, which includes the ability to decompress all specifiedcompression schemes.

2210

4.47.4.1.3.2 Image Display
The Image Display reads the DICOM image data from the media and provides the user with theability 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 and the Key___________________________________________________________________________
92
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2215

Image Notes IHE Integration Profiles are supported. The Image Display may optionally begrouped with other actors that view other evidence objects.
4.47.4.1.3.3 Report Reader
The Report Reader reads the DICOM SR Reports from the media and may process them (basedon 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.

2220

2225

4.47.4.1.3.4 Portable Media Importer
The Portable Media Importer reads DICOM data from the media. Together with the actor withwhich it is grouped (see RAD TF-1: 2.5), it shall be able to perform key attribute reconciliation
on attributes in Table 4.47.4-2. The Portable Media Creator might not be required to perform
reconciliation in all deployments (e.g., within the same importing institution/enterprise, thevalues in the imported object may already match what is expected by the importing
institution/enterprise).
The Import Reconciliation Workflow Profile provides mechanisms to obtain the necessary
values to reconcile the key attributes below. (See IRWF.b Trial Implementation Supplement.)

2230

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

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). (See Note 3)
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)___________________________________________________________________________
93
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2235

Note 1:

The manner in which the Portable Media Importer receives the ADT value is beyond the scope of thistransaction.

Note 2:

Handling of Coded information is beyond the scope of this transaction.

Note 3:The Referenced Study Sequence and Requested Attributes Sequence (which contain Workflow Identifying
Attributes) are omitted in the unscheduled case of Scheduled Workflow, so removing them during import would
be consistent with that behavior.

4.47.4.1.3.4.1 Grouping with XDM (IHE ITI Technical Framework)
2240

2245

A PDI Portable Media Importer that is grouped with a Portable Media Importer in the ITI CrossEnterprise Document Sharing on Media (XDM) Profile is able to import media with combined
DICOM and XDM content. The grouped actor will be referred to as the Portable Media
Importer.
The Portable Media Importer shall process the PDI content according to the specification in ITI
TF-2b: 3.32.4.1.4 with the following additional requirements:•

2250

The Manifest KOS instances (as described in Section 4.47.4.1.2.3.3) shall not be
imported as they are only meant to provide an overview of the DICOM instancespresent on the media to the Portable Media Importer.

Figure 4.47.4.1.3.4.1-1 illustrates the processing chain for the Portable Media Importer.

Figure 4.47.4.1.3.4.1-1: Processing Chain - Portable Media Importer___________________________________________________________________________
94
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.47.4.1.3.5 Print Composer
2255

The Print Composer reads the DICOM image data from the media and provides a means to printit.
4.47.4.1.3.6 Display
The Display reads the web-viewable information from 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.

2260

4.47.4.1.4 Media Options
The baseline media type is CD using the DICOM STD-GEN-CD Media Storage Application
Profile.
Options are provided for DVD Media and USB Media.
4.47.4.1.4.1 DVD Media Option

2265

2270

A Portable Media Creator that supports the DVD Media Option shall create media that complies
with either the DICOM STD-GEN-DVD-JPEG or STD-GEN-DVD-J2K Media Application
Profiles, as defined in DICOM PS3.11 Annex H.
A Portable Media Importer that supports the DVD Media Option shall be capable of reading any
media written with the DICOM STD-GEN-DVD-JPEG and any media written with the STDGEN-DVD-J2K Media Application Profiles.
In summary, these DICOM Media Application Profiles specify:•

the use of any of the conventional (non-HD) 120 mm DVD-compatible media except
DVD-RAM, specifically CD, DVD-R authoring and general, DVD-RW, DVD+R and
DVD+RW (see DICOM PS3.12 Annex P), which means that the Portable Media Creatorcan create any of these choices, and the receiving actors shall be capable of reading all ofthem•

the use of UDF or ISO 9660 (or both) as a filesystem, which means the Portable MediaCreator can create either (or both), but the receiving actors shall be capable of reading
either•the use of uncompressed images, or compressed images using JPEG lossy (8 or 12 bits)
or lossless (up to 16 bit), or JPEG 2000 reversible or irreversible (up to 16 bit) schemes,
which means the Portable Media Creator can make a choice, but receiving actors shall becapable of decompressing all of them•

additional DICOMDIR keys that shall be included by the Portable Media Creator (which
are listed in DICOM PS3.11 Annex H Section H.3.3.1)

2275

2280

2285

Several other DICOM Media Application Profiles are effectively subsumed by the DICOM
STD-GEN-DVD-JPEG profile. In particular, a Portable Media Creator that creates media using
such a DICOM Media Application Profile will create media that is readable by a receiving actor___________________________________________________________________________
95
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2290

2295

2300

that supports the DVD Media Option and hence the DICOM STD-GEN-DVD-JPEG profile.
This is true as long as the received supports the encoded SOP Classes, which is true of any PDI
media, and any additional required DICOMDIR keys are present. This includes profiles thatcreate CD media that is readable in a DVD drive. Those DICOM Media Application Profiles,
with any exceptions related to specific Transfer Syntaxes noted, are:•

STD-CTMR-CD•

STD-US-ID-SF-CDR, STD-US-ID-MF-CDR, STD-US-SC-SF-CDR, STD-US-SC-MFCDR, STD-US-CC-SF-CDR, and STD-US-CC-MF-CDR, except that RLE LosslessImage Compression is unsupported•

STD-XABC-CD•

STD-XA1K-CD

4.47.4.1.4.2 USB Media Option
A Portable Media Creator that supports the USB Media Option shall create media that complies
with either the DICOM STD-GEN-USB-JPEG or STD-GEN-USB-J2K Media Application
Profiles, as defined in DICOM PS3.11 Annex J.

2305

A Portable Media Importer that supports the USB Media Option shall be capable of reading any
media written with the DICOM STD-GEN-USB-JPEG and any media written with the STDGEN-USB-J2K Media Application Profiles.
The USB media shall have a Type A physical connector (DICOM has no such restriction).
In summary, these DICOM Media Application Profiles specify:

2310

•

the use of any USB-Connected Removable Storage Devices (see DICOM PS3.12 Annex
R), which includes the typical “memory stick” or “thumb drive”•

the use of a FAT16 or FAT32 filesystem (see also DICOM CP 905)•

the use of uncompressed images, or compressed images using JPEG lossy (8 or 12 bits)
or lossless (up to 16 bit), or JPEG 2000 reversible or irreversible (up to 16 bit) schemes,
which means the Portable Media Creator can make a choice, but the receiving actors shallbe capable of decompressing all of them•

additional DICOMDIR keys that shall be included by the Portable Media Creator (which
are specified in DICOM PS3.11 Annex J Section J.3.3.1, and are the same as those for
DVD specified in DICOM PS3.11 Annex H Section H.3.3.1).

2315

4.48 Appointment Notification [RAD-48]
2320

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

___________________________________________________________________________
96
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.48.1 Scope2325

In the Appointment Notification Transaction, a Department System Scheduler/Order Filler sends
to an Order Placer new appointment bookings and appointment rescheduling which contains thedate(s) and time(s) of the Scheduled Procedures Steps. It may also notify an Order Placer of thecancellation of appointment bookings.
4.48.2 Use Case Roles
DSS/
Order Filler

Order Placer

Appointment
Notification

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

Actor: Order Placer
Role: Receives Appointment Notification messages and internally processes them.
4.48.3 Referenced Standard
HL7 V2.4, chapter 10.

___________________________________________________________________________
97
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.48.4 Messages

2340

Figure 4.48.4-1: Interaction Diagram

4.48.4.1 Appointment Notification -New Bookings
4.48.4.1.1 Trigger Events
SIU^S12 - Notification of New Appointment Booking
2345

2350

The DSS/Order Filler receives an order from an Order Placer. 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
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).

2355
SIU^S12

Schedule Information
Unsolicited

Chapter in HL7 V2.4

MSH

Message Header

2

SCH

Schedule Activity Information

10

{ RGS

Resource Group Segment

10___________________________________________________________________________
98
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Schedule Information
Unsolicited

SIU^S12{ AIS[{ NTE }]Chapter in HL7 V2.4

Appointment Information - Service

10

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

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

2365

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.

2370
RP/
#

TBL
#

SEQ

LEN

DT

OPT

ITEM#

ELEMENT NAME

1

75

EI

O

00860

Placer Appointment ID

2

75

EI

R

00861

Filler Appointment ID

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
Field SCH-1 Placer Appointment ID contains the placer application’s permanent identifier forthe appointment request. This field is not used.
2375

Field SCH-2 Filler Appointment ID contains the filler application’s permanent identifier for theappointment request. This field is required to be sent.
___________________________________________________________________________
99
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.

2380

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

2385

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.

2390

2395

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

2400

2405

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

Adapted from the HL7 Standard, version 2.4___________________________________________________________________________
100
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.48.4.1.2.4 AIS Segment
2410

The AIS segment contains the date and time of a Scheduled Procedure. There is only one AIS
segment per group of resources.
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

1

4

SI

R

2

3

ID

R

3

250

CE

4

26

TS

5

20

6
7

RP/
#

TBL
#

ITEM#

ELEMENT NAME

00890

Set ID – AIS

00763

Segment Action Code

R

00238

Universal Service Identifier

R

01202

Start Date/Time

NM

O

00891

Start Date/Time Offset

250

CE

O

00892

Start Date/Time Offset Units

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

0206

2415

Adapted from the HL7 Standard, version 2.4
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).

2425

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.

2430

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.

2420___________________________________________________________________________
101
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.48.4.1.2.5 NTE Segment
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.
2435
SEQ

RP/
#

TBL
#

LEN

DT

OPT

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
Field NTE-2 Source of Comment identifies the source of the comment. This field is required but
may be empty. Valid values are:
Value

2440

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

Description

PI

Patient InstructionAI

Ancillary Instruction

GI

General Instruction

RE

Remark

4.48.4.1.3 Expected Actions
2445

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
4.48.4.2.1 Trigger Events
SIU^S13 - Appointment Notification - Reschedule Bookings

2450

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___________________________________________________________________________
102
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
2455

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

}

2460

2465

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.2.2.1 MSH Segment
MSH segment shall be constructed as defined in RAD TF-2: 2.4.2.2 “Message Control”.

2470

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.
4.48.4.2.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” of the current proposition.
4.48.4.2.2.3 AIS Segment

2475

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
The Order Placer shall accept the appointment information for rescheduling and shall return an
HL7 ACK message.
___________________________________________________________________________
103
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2480

4.48.4.3 Appointment Notification - Cancel Bookings
4.48.4.3.1 Trigger Events
SIU^S15 - Appointment Notification - Cancel Booking
This event is triggered when existing appointment bookings have been cancelled by an Order
Filler.

2485

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

}

2490

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

2495

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

2500

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

• Field AIS-2 Segment Action Code is valued with: D (Delete).
___________________________________________________________________________
104
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.48.4.3.3 Expected Actions

2510

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 [RAD-49]
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.
2515

4.49.1 Scope2520

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

Post-Processing
Manager

ReportManager

Actor: Image Manager/Image Archive2525

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).
Actor: DSS/Order Filler
Role: Receive an Instance Availability Notification message and internally process it.
Actor: Post-Processing Manager
Role: Receive an Instance Availability Notification message and internally process it.

2530

Actor: Report Manager
Role: Receive an Instance Availability Notification message and internally process it.
4.49.3 Referenced Standard
DICOM PS3.4: Instance Availability Notification Service Class___________________________________________________________________________
105
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.49.4 Messages
Image
Manager

DSS/
Order Filler

PostProcessing
Manager

ReportManager

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

2535

Figure 4.49.4-1: Interaction Diagram

4.49.4.1 Instance Availability Notification

2540

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

2545

2550

2555

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.
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 and Group
Case, Abandoned Case) and in transaction [RAD-7] (RAD TF-2: 4.7 MPPS DISCONTINUED,
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 Section 4.59.4.1.2. (Unscheduled Import and Unscheduled Import
Cases) and Section 4.60.4.1.2.2 (Import PPS Discontinued).

___________________________________________________________________________
106
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.49.4.1.2 Message Semantics
2560

2565

2570

2575

2580

2585

2590

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] transaction to confirm the status as asupplementary method. Additionally, the Image Manager/Image Archive is assumed to be able tohandle exceptions in instance storage or provision internally, based on local policy.
4.49.4.1.3 Expected Actions

2595

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:___________________________________________________________________________
107
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2600

•

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 Instances [RAD-50]
2605

This section corresponds to transaction [RAD-50] of the IHE Radiology Technical Framework.
The Export Selector and Export Manager actors use transaction [RAD-50].
4.50.1 Scope
In the Store Instances transaction, the Export Selector sends the selected composite instances tothe Export Manager.

2610

4.50.2 Use Case Roles

ExportSelector

ExportManagerStore
Instances

Actor: Export Selector
Role: Transmit instances to Export Manager.
Actor: Export Manager
2615

Role: Accept instances from Export Selector and queue them for de-identification,
pseudonymization and export
4.50.3 Referenced Standard
DICOM PS3.4: Storage Service Class.

___________________________________________________________________________
108
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.50.4 Messages

ExportSelector

ExportManager

C-STORE (Store Instances)

2620

Figure 4.50.4-1: Interaction Diagram

4.50.4.1 Store Instances
4.50.4.1.1 Trigger Events
2625

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.
4.50.4.1.3 Expected Actions

2630

The Export Manager will queue the received DICOM objects, until ready to process them.
The DICOM Standard defines a number of composite storage SOP classes. The Export Manager
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 andRadiotherapy objects.

2635

4.51 Store Export Selection [RAD-51]
This section corresponds to transaction [RAD-51] of the IHE Radiology Technical Framework.
The Export Selector and Export Manager actors use transaction [RAD-51].
4.51.1 Scope2640

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.
___________________________________________________________________________
109
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.51.2 Use Case Roles
ExportSelector

ExportManagerStore
Export Selection

Actor: Export Selector
2645

Role: Transmit manifest to Export Manager.
Actor: Export Manager
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

2650

DICOM PS3.4: Storage Service Class.
DICOM PS3.15: Basic Application Level Confidentiality Profile.
DICOM PS3.3: Information Object Definitions
DICOM PS3.16: Content Mapping Resource
4.51.4 Messages

2655

ExportSelector

ExportManager

C-STORE (Store Export Selection)

Figure 4.51.4-1: Interaction Diagram___________________________________________________________________________
110
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.51.4.1 Store Export Selection
4.51.4.1.1 Trigger EventsThe Export Selector can transfer a manifest to the Export Manager with a DICOM association.
2660

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

2665

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 PS3.16, and is itself non-extensible.
Table 4.51.4-1: Export Selection (“Manifest”) Template – Specializes DICOM TID 2010
NL

Rel with
parent1

Value 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

Root node

DCID Table
4.51.4-2 Delay
Reasons

Cond

2

>

HAS
CONCEPT
MOD

CODE

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

1

U

3

>

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

Disposition___________________________________________________________________________
111
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2670
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”).
2675

2680

2685

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

2690

CodingSchemeDesignator

Code
Value

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

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

Code Meaning

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

2695

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___________________________________________________________________________
112
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
2700

2705

Only instances of a single patient may be referenced by the manifest, but there may be instancesof multiple studies.
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 PS3.3 C.17.6.2.1). IHE
therefore requires that there be multiple copies of the same manifest sent in this transaction, one
for each study.
4.51.4.1.3 Expected Actions

2710

The Export Manager will queue the manifest until it has received all DICOM instancesreferenced therein, and is ready to process them.
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.

2715

2720

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 ineach manifest to detect the multiple study case and to prevent the same export from being
repeated.
No export shall be performed if instances are received but no referencing manifest is received
within a configurable time.

2725

2730

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

2735

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 Export
Instances [RAD-53] transactions.
___________________________________________________________________________
113
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.51.4.1.4 De-identification and Pseudonymization
4.51.4.1.4.1 Baseline De-identification and Pseudonymization Requirements

2740

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.
Accordingly, this transaction does not require the removal of all text attribute values, nor theremoval of all private attribute values.

2745

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 the use of the Basic Application Level
Confidentiality Profile in DICOM PS3.15. Further, it shall be configurable to perform no deidentification 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.

2750

2755

2760

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
within the exported set of instances be maintained; the implementation shall be configurable tosupport both. This entails adherence to the following rules:•

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.

2765

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.

2770

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

Mandatory and conditional attributes may not be removed, but rather must be replaced.

___________________________________________________________________________
114
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

2775

•

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

2780

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.

2785

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.

2790

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.
4.51.4.1.4.3 Remap Identifiers Option

2795

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.

2800

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:

2805

•

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

115
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________•

L – Leave means do not change the existing value of the attribute

2810

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)

Patient Name
Other Patient IDs

M

C

Note 2(0010,0010)

C

Note 2(0010,1000)

D

Patient’s Birth Date

(0010,0030)

L or C or D

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

Note 4

Clinical Trial Study Level
Study Date

(0008,0020)

L or C

Notes 3, 4

Study Time

(0008,0030)

M

L or C

Notes 3, 4

Study Description(0008,1030)

L or C

Note 4

Clinical Trial Timepoint ID(0012,0050)

C

Accession Number(0008,0050)

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.

2815

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.

2820

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
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___________________________________________________________________________
116
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2825

2830

2835

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.

2840

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

2845

2850

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

2855

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 [RAD-52]
This section corresponds to transaction [RAD-52] of the IHE Radiology Technical Framework.
The Export Selector and Export Manager actors use transaction [RAD-52].
4.52.1 Scope
2860

In the Store Additional Teaching File Information transaction, the Export Selector sends an SR
document containing additional teaching file information to the Export Manager.
___________________________________________________________________________
117
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.52.2 Use Case Roles

ExportSelector

ExportManagerStore
Additional
Teaching File
Information

Actor: Export Selector
2865

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

2870

DICOM PS3.4: Storage Service Class.
4.52.4 Messages

ExportSelector

ExportManager

C-STORE (Store Additional Teaching File Information)

Figure 4.52.4-1: Interaction Diagram___________________________________________________________________________
118
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.52.4.1 Store Additional Teaching File Information
2875

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

2880

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.

2885

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.

2890

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.

2895

4.53 Export Instances [RAD-53]
This section corresponds to transaction [RAD-53] of the IHE Radiology Technical Framework.
The Export Manager and Receiver actors use transaction [RAD-53].
4.53.1 Scope2900

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.

___________________________________________________________________________
119
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.53.2 Use Case Roles

ExportManager

Receiver

ExportInstances2905

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

2910

DICOM PS3.4: Storage Service Class.
4.53.4 Messages

ExportManager

ReceiverC-STORE (Export Instances)

Figure 4.53.4-1: Interaction Diagram___________________________________________________________________________
120
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.53.4.1 Export Instances
2915

4.53.4.1.1 Trigger EventsThe 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

2920

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.

2925

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

2930

A receiver shall support the Key Object Selection SOP Class as an SCP.
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.

2935

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:

2940

2945

•

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.

___________________________________________________________________________
121
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________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.
2950

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

4.55 WADO Retrieve [RAD-55]
2955

This section corresponds to transaction [RAD-55] of the IHE Radiology Technical Framework.
Transaction [RAD-55] is used by the Imaging Document Consumer and the Image Manager/
Image Archive actors.
4.55.1 Scope

2960

The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM
SOP Instances with a web-based service through HTTP/HTTPS protocol.
4.55.2 Use Case Roles

Imaging Document
SourceImagingDocument
Consumer

WADO Retrieve

Actor: Imaging Document Consumer
2965

Role: Issues an HTTP Get Request to access a DICOM instance.
Actor: Imaging Document Source
Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP
response with the appropriate content.
4.55.3 Referenced Standard

2970

DICOM PS3.18: Web Access to DICOM Persistent Objects (WADO)___________________________________________________________________________
122
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.55.4 Messages
ImagingDocument Source

Imaging Document
Consumer

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

Figure 4.55.4-1: Interaction Diagram

4.55.4.1 WADO Retrieve
2975

The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instancefrom the Imaging Document Source. The Imaging Document Source receives the request,
generates the response with the appropriate content and sends an HTTP Response to the Imaging
Document Consumer.
4.55.4.1.1 Trigger Events

2980

The Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within
a DICOM Manifest.
4.55.4.1.2 Message Semantics
The message semantics are defined by in DICOM PS3.18 Web Access to DICOM Persistent
Objects (WADO).

2985

2990

The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a
HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document
Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM
instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance
UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the hostinformation (e.g., web server location, and script language) of the web server to perform thistransaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOPInstance to the web server host information based on its local configuration (see Appendix G).
In addition, the Imaging Document Consumer shall support the following fields in the HTTP
request:___________________________________________________________________________
123
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
2995

Table 4.55-1: WADO HTTP Request Fields
HTTP Field

REQ

Description

Values

AcceptR

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

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

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

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

windowCenter

Window center of the image

O

O

IHE-3

windowWidth

Window width of the image

O

O

IHE-3

frameNumber

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

O

O

IHE-3

imageQuality

Image quality factor

O

O

IHE-3

presentationUID

Unique identifier of the presentation
object

O

O

IHE-3

IHE-1
IHE-2

___________________________________________________________________________
124
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3005

Parameter Description

Requirement
ImagingDocument
SourceImagingDocument
Consumer

Note

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.

3010

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.

3015

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

3020

This parameter is optional in DICOM PS3.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

3025

3030

The following is an example of HTTP Request-URI for retrieving a persistent DICOM object
using WADO:
http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.
40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&
objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&contentType=application%2Fdicom
This example uses response MIME type application/dicom to request the DICOM SOP Instance
returned in the native DICOM Part 10 file format.
___________________________________________________________________________
125
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.55.4.1.3 Expected Actions
3035

3040

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.

3045

3050

3055

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.
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). The IHE Radiology Audit Trial Option further defines a subset of these events,
which are particularly applicable to the radiology transactions.
See RAD TF-3: Table 5.1-2 for audit events required for the [RAD-55] transaction.

3060

4.56 Temporarily, intentionally, left blankReserved for Spatial Registrations Stored [RAD-56].

4.57 Temporarily, intentionally, left blankReserved for Blending Presentation States Stored [RAD-57].

4.58 Temporarily, intentionally left blank3065

Reserved for Retrieve Spatial Registrations [RAD-58].

___________________________________________________________________________
126
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4.59 Import Procedure Step In Progress [RAD-59]
This section corresponds to transaction [RAD-59] of the IHE Radiology Technical Framework.
Transaction [RAD-59] is used by the Department System Scheduler/Order Filler, ImageManager, Performed Procedure Step Manager, Report Manager, and Importer actors.
3070

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.

3075

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:

3080

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.

3085

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;

3090

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

Performed
Procedure Step
Manager

Image Manager
Report Manager

ImporterModality Procedure
Step In Progress

Department System
Scheduler/Order Filler

3095___________________________________________________________________________
127
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Actor: Department System Scheduler/Order Filler.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Image Manager.
Role: Receives the PPS information forwarded by the PPS Manager.
3100

Actor: Report Manager.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Importer.
Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure
Step has started.

3105

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
DICOM PS3.4: Modality Performed Procedure Step SOP Class.

3110

4.59.4 Messages
Importer

Performed Procedure Step
Manager/
Image Manager

MPPS N-CREATE

Department System
Scheduler/Order
FillerReport Manager

MPPS N-CREATEMPPS N-CREATE___________________________________________________________________________
128
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Importer

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

Image Manager

Report Manager

MPPS N-CREATEMPPS N-CREATE

Figure 4.59.4-1: Interaction Diagram

3115

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
3120

3125

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

3130

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

3135

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.

___________________________________________________________________________
129
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.59.4.1.2.3 Relationship between Scheduled and Performed Procedure Stepsand the Imported DICOM Composite Object
3140

3145

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

3150

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

3155

4.59.4.1.2.3.1

Scheduled Import
1

SPS

3160

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.

3165

4.59.4.1.2.3.2

Unscheduled Import

SPS

0results
in

1

PPS___________________________________________________________________________
130
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3170

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

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

3180

The Performed Protocol Code Sequence shall always contain one item with the value of(IRWF001, IHETFRAD, “Import”).
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: Table 4.5-4).
4.59.4.1.3

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

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 [RAD-60]
3190

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

3195

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.

___________________________________________________________________________
131
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.60.2 Use Case Roles
Performed
Procedure Step
Manager

Image Manager
Report Manager

ImporterModality Procedure
Step Completed

Department System
Scheduler/Order Filler

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

Actor: Report Manager.
Role: Receives the PPS information forwarded by the PPS Manager.
Actor: Importer.
Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure
Step and Importation is completed.

3210

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.
4.60.3 Referenced Standards

3215

DICOM PS3.4: Modality Performed Procedure Step SOP Class.
DICOM PS3.16: DCMR Context Groups (Normative)
4.60.4 Messages___________________________________________________________________________
132
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Importer

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

MPPS N-SET

Report Manager

MPPS N-SETMPPS N-SET

Importer

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

Image Manager

Report Manager

MPPS N-SETMPPS N-SET

3220

3225

Figure 4.60.4-1: Interaction Diagram
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.
4.60.4.1.2
3230

3235

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.
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.
___________________________________________________________________________
133
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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.
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.

3240

4.60.4.1.2.1 Retrieve AE Title
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:

3245

•

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.

3250

4.60.4.1.2.2 Import PPS Exception Management
3255

3260

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 PS3.16 Annex B Context ID 9300 or Table 4.60-1 (additional codes that are in theprocess of being added by DICOM).
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.

3265

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___________________________________________________________________________
134
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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).

3270

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).
Note: 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 Radiology Technical Framework does not specify whether or not the Importer needs
to perform a Storage Commitment for these instances.

3275

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

3280

3285

3290

3295

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.
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.
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)___________________________________________________________________________
135
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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

3300

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

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.

___________________________________________________________________________
136
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.60.4.1.3.1 Import PPS Exception Management
3310

3315

3320

3325

3330

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

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 [RAD-49] transaction.
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

3335

3340

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 [RAD-61]
This section corresponds to transaction [RAD-61] of the IHE Radiology Technical Framework.
Transaction [RAD-61] is used by the Image Archive and the Importer actors.

___________________________________________________________________________
137
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.61.1Scope
3345

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
TF-2: 4.5) or the Patient Demographics Query transaction (see ITI TF-2a: 3.21) shall be includedin the headers of the generated images.
4.61.2 Use Case Roles

ImporterImage
Archive

Modality
Images Stored

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

4.61.3 Referenced Standards
DICOM PS3.4: Storage Service Class, Section B.4.1 Conformance as an SCPDICOM PS3.3 SOP Information Objects, Common Module Attribute
4.61.4Messages
Image
Archive

Importer

C-STORE (Evidence Objects Stored)

3360

Figure 4.61.4-1: Interaction Diagram___________________________________________________________________________
138
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
3365

3370

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

3375

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

3380

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

3385

4.61.4.1.2.1 Original Attributes Sequence
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.

3390

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.

___________________________________________________________________________
139
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
3395

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

3405

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.

___________________________________________________________________________
140
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.61.4.1.2-2: Contributing Equipment Sequence
Attribute Name

Tag

Type

Attribute Description

Contributing Equipment Sequence(0018,A001)

R+

See Notes 1,2>Purpose of Reference Code Sequence(0040,A170)

R

See Table 4.61.4.1.2-3
Defined Context ID 7005>>Include ‘Code Sequence Macro’ Table 8.8-1

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

3415

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:
DefinedCoding Scheme Designator(0008,0102)

Code Value(0008,0100)

Code Meaning (0008,0104)

DCM

MEDIM

Portable Media Importer Equipment

DCM

FILMD

Film Digitizer Equipment

DCM

DOCD

Document Digitizer Equipment

DCM

VIDD

Video Tape Digitizer Equipment3420
4.61.4.1.3

Expected Actions

The Image Archive will store the received DICOM objects.

3425

The DICOM Images, Evidence Documents and Diagnostic Reports shall be stored such that they
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 PS3.4 B.4.1).

___________________________________________________________________________
141
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.61.4.1.3.1 DICOM Storage SOP Classes

3430

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.

3435

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.

4.62 Store Dose Information [RAD-62]
This section corresponds to transaction [RAD-62] of the IHE Radiology Technical Framework.
Transaction [RAD-62] is used by the Acquisition Modality, Image Manager/Archive, Dose
Information Reporter and Dose Information Consumer actors.
3440

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

3445

4.62.2 Use Case Roles
Image Manager/
Archive
Acquisition
Modality

Store Dose
Information

Dose Information
Consumer
Dose Information
Reporter

Actor: Acquisition Modality
Role: Generate Dose objects describing irradiation events performed by the Acquisition
Modality and store them to one or more receiving actors.
3450

Actor: Image Manager/Archive
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___________________________________________________________________________
142
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
3455

Role: Accept and process Dose objects received from the Acquisition Modality.
4.62.3 Referenced Standard
DICOM PS3.3: A.35.8 X-Ray Radiation Dose SR IOD
DICOM PS3.4: Storage Service ClassDICOM PS3.4: Structured Reporting Storage SOP Classes

3460

DICOM PS3.16: X-Ray Radiation Dose SR IOD Templates
DICOM PS3.16: CT Radiation Dose SR IOD Templates
DICOM PS3.17: Annex AA: Radiation Dose Reporting Use Cases
4.62.4 Messages
Acquisition
Modality

Image Manager/
Archive

C-STORE (Radiation Dose SR)

3465

Figure 4.62.4-1: Interaction Diagram
Note:

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
3470

The Acquisition Modality shall implement the X-ray Radiation Dose SR Storage SOP Class in
the role of SCU. The Image Manager/Archive, Dose Information Reporter and Dose Information
Consumer shall implement the Dose Storage SOP Class in the role of 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___________________________________________________________________________
143
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.62.4.1.1 Trigger Events
3475

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 PS3.16.
An Acquisition Modality shall record the relevant details for each irradiation event. These details
will be included in Dose objects as described below.

3480

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:

3485

3490

3495

3500

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

3505

3510

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.

___________________________________________________________________________
144
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.62.4.1.2 Message Semantics
The Acquisition Modality 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.
3515

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
destinations when they need to receive timely Dose objects without having to repeatedly poll the
Image Manager/Archive.

3520

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

3525

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:

3530

DICOM has extended these templates (and the templates they contain) several times since they were originallyintroduced and further enhancements are possible. Implementers are reminded that they are responsible formonitoring 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.

3535

3540

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 theequivalent 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 Dose object. Since
DICOM only permits a single value in this sequence, in the case where a
Dose object summarizes several PPS (e.g., of a whole multi-step study),
this attribute shall be left empty.

___________________________________________________________________________
145
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3545

3550

3555

Attribute Name

Tag

Requirement

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

Reason for the Requested
Procedure(0040,1002)

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 beapproximate. 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) andmay be approximate. This may facilitate future dose estimation andanalysis.

Patient’s Sex(0010,0040)

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry), if present, else obtained by operator entry.

Shall be copied from the relevant acquisition SPS (Modality Worklist
entry). This can facilitate checking compliance to indication-based dose
policies.

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 PS3.3: C.7.5.3).
The Acquisition Modality shall be capable of creating Dose objects for patient scans and forphantom/calibration scans.

___________________________________________________________________________
146
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
3560

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.

3565

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.

3570

3575

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.
Dose Information Reporter actors shall be capable of processing both TID 10001 and TID
10011.
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.

3580

4.63 Submit Dose Information [RAD-63]
This section corresponds to transaction [RAD-63] of the IHE Radiology Technical Framework.
Transaction [RAD-63] is used by the Dose Information Reporter and Dose Registry actors.
4.63.1 Scope

3585

This section describes DICOM STOW-RS transfers of DICOM Structured Report objects thatdetail irradiation 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.

___________________________________________________________________________
147
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.63.2 Use Case Roles
Dose
Information
Reporter

Dose Register

Submit Dose
Information

3590

Actor: Dose Information Reporter
Role: Submit (de-identified) Dose objects describing irradiation events performed byAcquisition Modalities in its facility.
3595

Actor: Dose Registry
Role: Accept and store Dose objects received from Dose Information Reporters.
4.63.3 Referenced Standard
DICOM PS3.3: A.35.8 X-Ray Radiation Dose SR IOD
DICOM PS3.10: Media Storage and File Format

3600

DICOM PS3.16: X-Ray Radiation Dose SR IOD Templates
DICOM PS3.16: CT Radiation Dose SR IOD Templates
DICOM PS3.18 Section 6.6: STOW-RS Request/Response
4.63.4 Messages
Dose
Information
Reporter

Dose Register

Submit Dose Information

3605

Figure 4.63.4-1: Interaction Diagram___________________________________________________________________________
148
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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.
3610

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

3615

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

3620

3625

3630

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.
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 DICOM STOW-RS request. The Dose
Information Reporter is the User-Agent. The Dose Register is the Origin-Server. The Dose
Information Reporter shall use the Store Instances action type. The Dose Information Reporter
shall encode the instances using the binary DICOM method.
The Dose Registry shall be capable of accepting a DICOM STOW-RS request.
The Dose Registry can identify the Dose Information Reporter (for audit purposes) using the IP
address of the User-Agent, or use different URL end points for each Dose Information Reporter.

3635

The Dose Information Reporter shall use STOW-RS 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 Information Reporter shall be capable of sending the Dose objects to multiple
configured destinations.

3640

The Dose Information Reporter is responsible for delivery of Dose objects in spite of intermittent
connections (network trouble, or the destination system being down).
___________________________________________________________________________
149
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.63.4.1.2.1 De-identification
The Dose Information Reporter shall be capable of de-identifying Dose objects before submitting
them.
3645

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 PS3.15 Annex E.
Accordingly, this transaction does not require the removal of all text attribute values, nor theremoval of all private attribute values.

3650

3655

3660

3665

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 PS3.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 Code Sequence (0012,0064).
The Dose Information Reporter shall be configurable to perform no de-identification at all.

3670

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.

3675

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:___________________________________________________________________________
150
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3680

3685

3690

3695

•

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

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.

3700

The Dose Information Reporter is not required to be able to pseudonymize Dose objects. For a
description of pseudonymization, see Section 4.51.4.1.4.
4.63.4.1.3 Expected Actions
3705

3710

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

___________________________________________________________________________
151
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
3715

4.64 Query Dose Information [RAD-64]
This section corresponds to transaction [RAD-64] of the IHE Radiology Technical Framework.
Transaction [RAD-64] is used by the Dose Information Reporter, Dose Information Consumer
and Image Manager/Archive actors.
4.64.1 Scope

3720

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

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

Actor: Image Manager/Archive
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 PS3.4: Query/Retrieve Service Class

3735

DICOM PS3.4: Structured Reporting Storage SOP Classes
DICOM PS3.3: A.35.8 X-Ray Radiation Dose SR IOD___________________________________________________________________________
152
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.64.4 Messages
Dose
Information
ReporterImage
Manager/Archive
Query Dose Reports (C-FIND)

Query Responses (C-FIND)

Figure 4.64.4-1: Interaction Diagram

3740

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
The Query (Study Root – FIND and optionally Patient Root – FIND) SOP Classes shall besupported. Refer to DICOM PS3.4: Query/Retrieve Service Class for detailed descriptive
semantics.
3745

4.64.4.1.1 Trigger Events
The Dose Information Reporter needs to obtain information about Dose objects.

3750

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.

3755

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

3760

The message semantics are defined by the DICOM Query/Retrieve SOP Classes.
The Dose Information Reporter and Dose Information Consumer actors shall implement theQuery/Retrieve SOP Classes in the role of SCU. The Image Manager/Archive shall implement
the Query/Retrieve SOP Classes in the role of SCP.
___________________________________________________________________________
153
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3765

3770

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

3775

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.
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.
___________________________________________________________________________
154
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.64.4.1.2.1 Filtering Strategies
3780

3785

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

3790

To filter for Dose objects:•

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

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

3805

Matching key - Modalities in Study (0008,0061) allows selection of a desired modality(e.g., CT, XA, DR, DX, CR, MX)

Note:

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

Object Attribute - Performed Procedure Code Sequence (0040,A372) is Type 2, but iffilled 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.

3810

3815

Note:

Series Description (0008,103E) is a Type 3 attribute which, if present, in a Dose object will have a value of“Radiation Dose Information”.

___________________________________________________________________________
155
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
To filter for specific body regions:•3820

Object Content Tree – Target Region allows identification of body regions.

Note:

•

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

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

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
3835

3840

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.

4.65 Retrieve Dose Information [RAD-65]
This section corresponds to transaction [RAD-65] of the IHE Radiology Technical Framework.
Transaction [RAD-65] is used by the Dose Information Reporter, Dose Information Consumer
and Image Manager/Archive actors.
3845

4.65.1 Scope
A Dose Information Reporter or Dose Information Consumer requests and receives from theImage Manager/Archive specified instances of Dose objects.

___________________________________________________________________________
156
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.65.2 Use Case Roles
Dose
Information
ReporterImage Manager/
Archive

Retrieve Dose
Information
Dose
Information
Consumer

3850

Actor: Dose Information Reporter
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

3855

Role: Provide specified Dose objects requested by Dose Information Reporters and Dose
Information Consumers.
4.65.3 Referenced Standard
DICOM PS3.4: Query/Retrieve Service ClassDICOM PS3.4: Structured Reporting Storage SOP Classes

3860

DICOM PS3.3: A.35.8 X-Ray Radiation Dose SR IOD
4.65.4 Messages
Dose
Information
ReporterImage
Manager/Archive

Request Dose Reports (C-MOVE)Store Dose Reports (C-STORE)

Figure 4.65.4-1: Interaction Diagram

3865

Note:

In the above diagram, the Dose Information Consumer may also submit a C-MOVE request and receive a CSTORE message.

___________________________________________________________________________
157
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.65.4.1 Retrieve Dose Information
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 PS3.4 Annex C for detailed descriptive semantics.
3870

The Image Manager/Archive, Dose Information Reporter and Dose Information Consumer actors
shall support the SOP Classes shown in Table 4.65-1 below.
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
3875

The Dose Information Reporter or Dose Information Consumer decides it needs a specific Doseobject.
4.65.4.1.2 Message Semantics

3880

3885

The message semantics are defined in the DICOM Query/Retrieve Service Class Section of the
DICOM PS3.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.
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.

3890

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

3895

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.
___________________________________________________________________________
158
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3900

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.

3905

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 IHE. Such details should be worked out as part of the product design.

3910

4.66 Rejection Note Stored [RAD-66]
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

3915

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

3920

•
•

3925

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, orassociated certain images to the correct modality worklist entry so that the original
images are to be rejected for incorrect modality worklist selection reason

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.
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___________________________________________________________________________
159
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Actor: Acquisition Modality
3930

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.

3935

Actor: Image Manager/ Image Archive
Role: Image Archive receives, processes and stores the Rejection Notes received from theAcquisition Modality, Evidence Creator or Change Requester. Image Manager/ Image Archive
applies defined logic to the images that are referenced in the Rejection Note.
Actor: Change Requester

3940

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 PS3.4: Key Object Selection Document Storage SOP Class

3945

DICOM PS3.4: Storage SOP ClassDICOM PS3.4: Query/Retrieve SOP ClassDICOM PS3.16: TID 2010, CID 7011
4.66.4 Messages
Image Manager/
Image Archive

Acquisition
Modality

3950

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)

Figure 4.66.4-2: Interaction Diagram: Rejection Note Stored in IOCM___________________________________________________________________________
160
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3955

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:Table 4.66.4-1: Profile Supported Key Object Selection Document Title
KOS Document Title

3960

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

3965

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

3970

3975

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 PS3.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 instances are specified as Content Items with value type of
COMPOSITE, IMAGE or WAVEFORM in the Content Sequence (0040,A730).

4.66.4.1.3 Expected Actions
3980

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.
___________________________________________________________________________
161
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

3985

•

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 request includes optional Additional Query/Retrieve Attributes defined in Table
4.66.4.1.3-1, then the returned value(s) of the requested attributes shall reflect theabsence of hidden rejected instances.

3990

Table 4.66.4.1.3-1: Additional Query/Retrieve Attributes
Attribute Name

Tag

Number of Patient Related Studies(0020,1200)

Number of Patient Related Series(0020,1202)

Number of Patient Related Instances(0020,1204)

Number of Study Related Series(0020,1206)

Number of Series Related Instances(0020,1209)

Number of Study Related Instances(0020,1208)

Modalities in Study(0008,0061)

SOP Classes in Study(0008,0062)

Alternate Representation Sequence(0008,3001)

For example, the following study has two original series and a Rejection Note for Quality
Reason that references all instances in Series 2
3995

4000

•

Series 1: Modality = MR, 200 objects•

Series 2: Modality = US, 80 objects•

Series 3: Modality = KO (Rejection Note), 1 object (references all 80 objects in Series 2)

When the Image Manager receives a C-FIND request for this study and the request specifies the
additional Number of Study Related Series (0020,1206), Number of Study Related Instances(0020,1208) and Modalities in Study (0008,0061) attributes, then using the Regular Use
behavior, the Image Manager will return the following result with respect to the additional
Query/Retrieve attributes:
Table 4.66.4.1.3-2: Regular Use Behavior - Example Attribute Values
Attribute Name

Value

Number of Study Related Series

3

Number of Study Related Instances

281

Modalities in StudyMR \ US \ KO___________________________________________________________________________
162
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4005

When using the Hide Rejected Instances behavior, the Image Manager will return the following
result with respect to the additional Query/Retrieve attributes:
Table 4.66.4.1.3-3: Hide Rejected Instances Behavior - Example Attribute Values
Attribute Name

4010

Value

Number of Study Related Series

3 if empty series is returned, or
2 if empty series is not returned

Number of Study Related Instances

201

Modalities in StudyMR \ KOIf 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.

4015

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

4020

4.66.4.2 Rejection Note Stored (for Patient Safety Reasons)4.66.4.2.1 Trigger Events

4025

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

4030

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.
•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 or at the Evidence Creator as
defined in RAD TF-2: 4.18.4.1.2.

___________________________________________________________________________
163
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4035

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 PS3.3 and 3.4, and shall:
•

4040

4045

Have the Key Object Selection Document Title value (113037, DCM, "Rejected forPatient Safety Reasons")•

References to all incorrect instances and derived instances (e.g., FOR
PRESENTATION and FOR PROCESSING) are specified as Content Items withvalue type of COMPOSITE, IMAGE or WAVEFORM in the Content Sequence(0040,A730).

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
The Image Manager / Archive receives the Key Object Selection (KOS) instance with theDocument Title value (113037, DCM, "Rejected for Patient Safety Reasons") and shall store it.

4050

The Image Manager / Archive shall hide the referenced incorrect instances and specifically shallnot provide the incorrect instances in responses to an image query/ retrieve transaction [RAD-14,
RAD-16] or presentation state query/retrieve transaction [RAD-15], [RAD-17].
If the complete series is rejected, then the Image Manager / Archive may or may not return theempty series in the C-FIND response when it receives a SERIES level C-FIND request.
4.66.4.2.3.1 Additional Requirements for Image Manager / Archive in IOCM

4055

The Image Manager / Archive shall 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

4060

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

4065

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___________________________________________________________________________
164
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4070

Document Attribute Mapping (RAD TF-2: A.2). The instance shall be constructed as defined in
DICOM PS3.3 and 3.4, and shall have the following values in the DICOM template TID 2010:•

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 are
specified as Content Items with value type of COMPOSITE, IMAGE or WAVEFORM in
the Content Sequence (0040,A730).

4075

4.66.4.3.3 Expected Actions
The Image Manager / Archive receives the Key Object Selection (KOS) instance with theDocument Title values (113038, DCM, “Incorrect Modality Worklist Entry”) and shall store it.
4080

The Image Manager / Archive shall hide the incorrect instances and specifically 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/retrieve transaction [RAD-15], [RAD-17].
The Image Manager / Archive shall not accept subsequent occurrence of instances that have been
hidden.

4085

If the complete series is rejected, then the Image Manager / Archive may or may not return theempty 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

4090

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

4095

4100

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 PS3.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 are specified as Content Items with value type of COMPOSITE, IMAGE or
WAVEFORM in the Content Sequence (0040,A730).

___________________________________________________________________________
165
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.66.4.4.3 Expected Actions
4105

The Image Manager / Archive receives the Key Object Selection (KOS) instance with theDocument Title values (113039, DCM, “Data Retention Policy Expired”) and shall store it.
The Image Manager/Archive will decide, depending on its local data retention policies, whether
to act on the information in the KOS and how to act. If it chooses to act on the KOS, it may
delete the expired instances referenced in the KOS.

4110

4115

4120

If the complete content of a series is deleted, the Image Manager / Archive may or may not alsodelete the series itself.
If the Image Manager / Archive later receives instances that have been previously deleted due tothe expiry of data retention period and not deleted due to other reasons, then the ImageManager/Archive may choose to decide that the Data Retention Policy Expired rejection is nolonger in force. If it so decides, it shall:•

store 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]•

return the referenced instances in subsequent query or retrieve requests•

not return the Rejection Note corresponding to the Data Retention Policy Expired
rejection that is no longer in force

4.67 Temporarily, intentionally, left blankReserved for Media Information Stored [RAD-67].

4.68 Provide and Register Imaging Document Set – MTOM/XOP[RAD-68]
4125

4130

This section corresponds to transaction [RAD-68] of the IHE Radiology Technical Framework.
“Provide and Register Imaging Document Set – MTOM/XOP” is used by the XDS-I Imaging
Document Source to provide a set of imaging documents to the XDS Document Repository, andto request that the XDS Document Repository store these documents and then register them with
the XDS Document Registry. This transaction is derived from the Provide and Register
Document Set-b [ITI-41] transaction of the IHE IT Infrastructure Technical Framework. It adds
new document content types as well as additional semantics and constraints on the metadatadefined in [ITI-41].
4.68.1 Scope

4135

The Provide and Register Imaging Document Set – MTOM/XOP transaction passes a Repository
Submission Request from an XDS-I Imaging Document Source to an XDS Document
Repository.
A Provide and Register Imaging Document Set – MTOM/XOP transaction carries:___________________________________________________________________________
166
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________•

Metadata describing zero or more new documents (Metadata describing zero documents
may be used to describe folders containing references to documents that were previously
submitted)•

Within metadata, one DocumentEntry object per document•

One Submission Set definition along with the linkage to new documents and references
to existing documents•

Zero or more Folder definitions along with linkage to new or existing documents.

•

Zero or more documents

4140

4145

4.68.2 Use Case Roles
Document
Repository

ImagingDocument
SourceProvide and Register
Imaging Document
Set – MTOM/XOP

Actor: Imaging Document Source
4150

Role: Submits document(s) with associated metadata to an XDS Document Repository.
Actor: Document Repository
Role: Receives documents and associated metadata and:

4155

•

Stores the documents•

Augments submitted metadata with repository information to enable later retrieval of
documents•

Forwards the enhanced metadata to the XDS Document Registry.

4.68.3 Referenced Standards
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.
4160

In addition, the following standards are used to define the radiology-specific content:
DICOM PS3.3: Key Object Selection Document (KOS)___________________________________________________________________________
167
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________DICOM PS3.16: Content Mapping Resource
DICOM PS3.18: Web Access to DICOM Persistent Objects (WADO)
4165

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)
HL7 Implementation Guide for CDA® Release 2: Imaging Integration; Basic Imaging Reports in
CDA and DICOM; Diagnostic Imaging Reports (DIR) – Universal Realm, Release 1, March
2009.

4170

4.68.4 Messages

Document
Repository

Imaging Document
SourceProvide and Register Imaging
Document Set – MTOM/XOP Request

Provide and Register Imaging
Document Set – MTOM/XOP Response

Figure 4.68.4-1: Interaction Diagram

4175

4.68.4.1 Provide and Register Imaging Document Set – MTOM/XOP Request
message
An Imaging Document Source sends documents and associated metadata to a Document
Repository. This message is an extension of the Provide and Register Document Set-b
transaction as defined in ITI TF-2b: 3.41.
4.68.4.1.1 Trigger Events

4180

The triggers for this transaction are:•

The Imaging Document Source is instructed to submit a set of one or more new imaging
documents for sharing, or•A previously submitted document or the contents of a previously submitted manifestchanges, requiring the Imaging Document Source to submit an update.

___________________________________________________________________________
168
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4185

4.68.4.1.2 Message Semantics
This transaction extends the message semantics of the Provide and Register Document Set-b[ITI-41] transaction by specifying additional document content types, to allow the sharing of thefollowing types of documents:
1. Sets of DICOM SOP instances

4190

2. Imaging diagnostic reports
To support these content types and their usage, additional requirements and constraints on theDocument Sharing Metadata are specified.
The Provide and Register Imaging Document Set – MTOM/XOP Request message semantics are
specified in the following subsections:4195

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
3. XDS-I.b Document Sharing Metadata bindings

4200

4. Use of the Document Sharing Submission Set concept in sharing of radiology imaging
information.

4205

The wsdl definition for this Provide-and-Register transaction sent by the XDS-I Imaging
Document Source is no different than the Provide-and-Register transaction sent by the XDS.b
Document Source in [ITI-41]. An informative wsdl definition for the Provide-and-Registertransaction 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

4210

The XDS-I 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 XDS Document Repository
and registered at the XDS Document Registry.

4215

As specified in IHE ITI XDS.b Integration Profile, the structure of the message between the
XDS Document Source and the XDS Document Repository is an MTOM/ XOP formatted
message. In this transaction, the source actor is the XDS-I Imaging Document Source, but theabove requirement still applies. The KOS Document Instance is encoded in the message as a
DICOM Part 10 File format having a MIME type of “application/dicom”.
The Imaging Document Source shall ensure that the DICOM SOP Instances referenced fromwithin the manifest are available to be retrieved.

4220

If the XDS-I Imaging Document Source makes one or more SOP Instances unavailable that arereferenced in a published manifest, then it shall submit a new manifest as a replacement for the
published manifest already in the XDS Document Repository and XDS Document Registry (seeIHE ITI TF-3: 4.2.2.2 “Document Relationships”). The new manifest shall have the updated list___________________________________________________________________________
169
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4225

of DICOM SOP Instances with the unavailable instances removed. If the XDS-I Imaging
Document Source makes all referenced DICOM SOP Instances unavailable in a publishedmanifest, then it may consider implementing the Remove Imaging Document Option (see RAD
TF-1: 18.2.5).
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.

4230

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

4235

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.

4240

4.68.4.1.2.2 Sharing of Report
Since text reports address many of the weaknesses of PDF reports and vice versa, it is requiredthat the Imaging Document Source shall support shared reports in at least one of the following
three formats:

4245

•

CDA Imaging Report with Structured Headings•

CDA Wrapped Text Report•

PDF Report___________________________________________________________________________
170
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
To maximize interoperability of the chosen formats:•For a PDF Report:
•

4250
•

For a CDA Imaging Report with Structured Headings:
•

4255

•
4260

A specific PDF version is not specified, but use of PDF/A (ISO 19005-1) isrecommended.
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:•

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

4270

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

4275

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.

4280

4.68.4.1.2.3 Document Sharing Metadata
The Provide and Register Imaging Document Set – MTOM/XOP Request message shall include
the metadata attributes that will be forwarded by the Document Repository to the XDS
Document Registry using the Register Document Set-b [ITI-43] transaction.
___________________________________________________________________________
171
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________The Imaging Document Source supplies all necessary metadata attributes of a DocumentEntry.
4285

4290

4295

4300

4305

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 XDS Document Repository, so its author andcreation information is populated into the Document metadata.
In XDS-I.b, the Manifest document submitted to the XDS 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, author (and subattributes 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 XDS Document Registry for finding this data. For example, aManifest referencing a current report and 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).
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 XDS Document Repository, themetadata of such newly generated shared information shall be populated from the original source
data (e.g., DICOM data).
In summary, XDS-I.b Document Sharing Metadata always reflects the main clinical content of ashared 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.

4310

4.68.4.1.2.3.2 DocumentEntry Metadata

4315

Table 4.68.4.1.2.3-1 lists Document Sharing DocumentEntry metadata attributes that are either
further constrained by XDS-I.b, or have XDS-I.b specific instructions for how the XDS-I
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 required for the XDS
Document Source.
For a full description of all the metadata attributes associated with a Document Sharing
document, see Table 4.2.3.2-1 “DocumentEntry Metadata Attribute Definition” in ITI TF-3:
4.2.3.2.

___________________________________________________________________________
172
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.68.4.1.2.3-1: XDS-I.b-specific Metadata Requirements
DocumentEntry
Metadata Attribute

XDS-I.b-specific Requirements

creationTime

This attribute value shall be populated by the XDS-I Imaging Document Source 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) andInstance Creation Time (0008,0013) of the DICOM object.

eventCodeList

This attribute is required to be included in the metadata if known by the XDS-I 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 (DICOM 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 theeventCodeList. Each modality code’s displayName shall be populated with thecorresponding Code Meaning text from Context Group CID 29.
Notes:The XDS-I Imaging Document Source 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 andthese values shall not be represented in the eventCodeList.
•
Anatomic Region: the eventCodeList shall contain code(s) from the DICOM Content
Mapping Resource (DICOM PS3.16) Context Group CID 4. Each anatomic region code’s
displayName shall be populated with the corresponding Code Meaning text from Context
Group CID 4.
For example, for a lung CT study which contains 3 CT acquisition series, one SR series, and one
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)”.

formatCode

This attribute shall be populated by the XDS-I Imaging Document Source as follows:•
Shall use “1.2.840.10008.5.1.4.1.1.88.59” (DICOM KOS SOP Class UID) as the Format
Code Value and “1.2.840.10008.2.6.1” (DICOM UID Registry UID) as the Format 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 a Content Profile(such as IHE Cardiology CIRC or CRC).

mimeTypeThis attribute shall be populated by the XDS-I 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 XDS-I Imaging Document Source describe the high-level
imaging specialty such as (R-3027B, SRT, “Radiology”), (R-3026B, SRT, “Pathology”), or (R-___________________________________________________________________________
173
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
DocumentEntry
Metadata Attribute

XDS-I.b-specific Requirements
30248, SRT, “Cardiology”). The list of acceptable values is constrained by the organization
managing the XDS Document Registry (i.e., the XDS Affinity Domain).
It is strongly recommended to use the values from the DICOM Content Mapping Resource(DICOM PS3.16) Context Group CID 7030.

referenceIdList

The list items can describe both the Accession Number and Study Instance UID.
The Data Type for referenceIdList is CXi, as specified in ITI TF-3: Table 4.2.3.1.7-2.
Accession Number:
The Accession Number identifies the Imaging Service Request. The Accession Number value
may be found in the Originating HL7 Imaging Order Message (OMI) Imaging Procedure Control(IPC) Segment, Sequence 1 for Accession Identifier, or in the DICOM attribute Accession
Number (0008,0050).
The referendIdList may be populated with the Accession Number and assigning authority.
Only the CXi.1, CXi.4 and CXi.5 components shall be valued. For DICOM mapping, see Section
4.68.4.1.2.3.3.5.
The referencedIdList may contain multiple entries for Accession Number, e.g., for images from agrouped acquisition or when images are acquired and read in different facilities.
Study Instance UID:The Study Instance UID uniquely identifes an imaging study.
Only the CXi.1 and CXi.5 components shall be valued:•
CXi.1 - shall be the Study Instance UID•
CXi.5 – shall be urn:ihe:iti:xds:2016:studyInstanceUID.
An example encoding two Accession Numbers and a Study Instance UID in the referenceIdList
is as follows:<rim:Slot name="urn:ihe:iti:xds:2013:referenceIdList "><rim:ValueList><rim:Value>642356235^^^&amp;1.2.3.4.5.6&amp;ISO^urn:ihe:iti:xds:2013:accession</rim:Value><rim:Value>STN-238432^^^&amp;1.2.3.4&amp;ISO^urn:ihe:iti:xds:2013:accession</rim:Value><rim:Value>
2.16.5.4.3.2.1.0^^^^urn:ihe:iti:xds:2016:studyInstanceUID</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 ITI TF-3:
4, Metadata used in Document Sharing Profiles, and specifically Table 4.2.3.2-1 in ITI TF-3:
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).

___________________________________________________________________________
174
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
DocumentEntry
Metadata Attribute

XDS-I.b-specific Requirements

typeCodeThis attribute shall be populated by the XDS-I Imaging Document Source from a code in theProcedure Code Sequence (0008,1032) of the performed procedure with which the document isassociated. In certain special cases previously defined in other IHE Profiles some sort of userintervention will be necessary 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 select a single, pre-coordinated procedure code that represents the multiple Requested
Procedures that were acquired as a single study.
The coding system of the Radiology Imaging performed Procedure Code will be designated by
the XDS Affinity Domain and shared by all XDS-I Imaging Document Sources in the XDS
Affinity Domain.
Note: As specified in RAD TF-2: Appendix A, Table A.1-1, if the procedure is changed from theRequested Procedure Code Sequence (0032,1064), the Procedure Code Sequence (0008,1032) inthe image is recommended to be absent or empty. Therefore, if the Procedure Code Sequence isabsent, it is recommended that the Requested Procedure Code Sequence never be used because
the procedure may have been altered.

uniqueId

This attribute shall contain the Document unique ID generated by the XDS-I Imaging Document
Source. It shall be an ISO OID.
For a DICOM Manifest document, this attribute value shall be the same as the SOP Instance UIDof the corresponding DICOM KOS object. In the event that any information in the manifestchanges and it needs to be resubmitted from the XDS-I Imaging Document Source to the XDS
Document Repository, the XDS-I Imaging Document Source shall generate a new SOP Instance
UID for the DICOM KOS object to ensure that its submission to the XDS Document Repository
will succeed.
For a CDA Imaging Report with Structured Headings or a CDA Wrapped Text Report, this value
shall be formulated from the HL7 CDA R2 header as follows:
ClinicalDocument/id@root.ClinicalDocument/id@extension

4320
4.68.4.1.2.3.3 Transformation of DICOM VR to Document Sharing Metadata Data
Types

4325

A number of Document Sharing 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 Document Sharing metadata are described.
Note that term HL7 Data Type in the following transformations refers to their specified usage inDocument Sharing metadata as defined in IHE ITI TF-3: 4.2.3.1.7 “Metadata Attribute Data
types”.

4330

4.68.4.1.2.3.3.1 CX – Extended Composite ID
Table 4.68.4.1.2.3-2 describes the transformation of data element of DICOM VR to CX data typeas specified in ITI TF-3: 4.2.3.1.7 “Metadata Attribute Data Types”.

___________________________________________________________________________
175
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Table 4.68.4.1.2.3-2: CX Data type mapping
CX DataComponent

4335

Component
Name

DICOM 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 is data element (0010,0020) whenused with sourcePatientId.

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) when used with sourcePatientId.
If this attribute is not present or the Assigning
Authority – Universal ID Type is not ISO, then the
XDS-I Imaging Document Source shall use its local
configuration to populate this subcomponent, toindicate the Patient ID Domain, from which thePatient 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 theformat of the Universal Entity ID. In DICOM it is data
element of the Issuer 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 Type is not ISO, then the
XDS-I Imaging Document Source shall use its local
configuration to populate this subcomponent, toindicate the Patient ID Domain, from which thePatient ID value in component 1 has been issued.
This component shall be “ISO”

HL7 CX data components not listed in the table are not used in Document Sharing metadata andshall be left empty.
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]]]]]

4340

This can be transformed from DICOM elements of VR DA (format: YYYYMMDD) and TM(format: HHMMSS.fraction).
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 for Document Sharing metadata:___________________________________________________________________________
176
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4345

Table 4.68.4.1.2.3-3: XCN Data type mapping
XCN Data
Component

Component NameDICOM Data
Element

1

ID Number

2

Family Name

1st Component of
PN

3

Given Name

2nd Component of
PN

4Second or Further Given
Names or Initials thereof

3rd Component ofPN

5Suffix5th Component of
PN

6Prefix4th Component ofPN

7

DegreeComment
The XDS-I 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 Document Sharing metadataand shall be left empty.
4.68.4.1.2.3.3.4 XON – Extended Composite Name and Identification Number for
Organization
4350

Table 4.68.4.1.2.3-4 describes the transformation of DICOM Data Elements to XON data type as
specified for Document Sharing metadata:
Table 4.68.4.1.2.3-4: XON Data type mapping
XON Data
Component
1

Component
Name
Organization
Name

DICOM VR
LO

Comment
Institution Name (0008,0080) or Institution Code Sequence(0008,0082) >Code Meaning (0008,0104)
If not populated, the XDS-I 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 has a value

SH

Institution Code Sequence (0008,0082) >Code Value(0008,0104)
The XDS-I Imaging Document Source may use its local
configuration to populate this component.

___________________________________________________________________________
177
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

HL7 XON data components not listed in the table are not used in Document Sharing metadataand shall be left empty.
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 ITI TF-3: Table 4.2.3.1.7-2 “Data Types”.

4360

Table 4.68.4.1.2.3-5: CXi Data type mapping
CXi Data
Component

Component
Name

DICOM
VR

Comment

1

ID NumberLO

Accession Number (0008,0050).
For a grouped acquisition study, this field will be empty inthe top level DataSet, but may be obtained from within
Request Attributes Sequence (0040,0275)

4.2

Assigning
Authority –Universal ID

UT

Issuer of Accession Number Sequence (0008,0051)>Universal Entity ID (0040,0032).
If this attribute is not present or the Assigning Authority –Universal ID Type is not ISO, then the XDS-I Imaging
Document Source shall use its local configuration to
populate this subcomponent, to indicate the Assigning
Authority, from which the Accession Number value incomponent 1 has been issued.
This component shall be an ISO OID.

4.3

Assigning
Authority –Universal ID Type

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 Type is not ISO, then the XDS-I Imaging
Document Source must use its local configuration to
populate this subcomponent, to indicate the Assigning
Authority, from which the Accession Number value incomponent 1 has been issued
This component shall be “ISO”

5

Identifier Type
Code

CS

Shall be “urn:ihe:iti:xds:2013:accession”

4.68.4.1.2.3.4 Document Sharing Metadata Values represented as HL7 v2.5 Data
Types
4365

Document Sharing metadata that is represented as an HL7 v2.5 data type will requiretransformation from its corresponding HL7 CDA R2 header component. 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.
___________________________________________________________________________
178
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4370

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

Subcompone
nt index

HL7 CDA Header

Subcomponent
name

CX(see Note 1)

HL7 CDA R2 Sub-element or
attributeII1

Id number

II@extension

4.2

AssigningAuthority.
uid

II

@root

CXi
(see Note 1)DTM

HL7 CDAR2 Dataelement

II1

Id number

II@extension

4.2

AssigningAuthority.
uid

II

@root

1 (only)

Date/TimeTS or
IVL_TS@value(NOTE: format is compatible with DTM)

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

XCN

II and PN

XON

II and ON
1

Organization Name

6.1

AssigningAuthority.
namespaceII@assigningAuthorityName

6.2 (see Note 2)

AssigningAuthority.
uid

II

@root

6.3 (see Note 3)

Assigning Authority
Universal Id TypeII

10

Organization
IdentifierII@extension

Note 1: See ITI TF-3: Table 4.2.3.1.7-2 for restrictions on the formatting of the CX and CXi datatype.
Note 2: This field is required if XON.10 is valued and not an OID.
Note 3: This field is required if XON.10 is valued and not an OID and shall have the value "ISO".

___________________________________________________________________________
179
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4375

4.68.4.1.2.3.5 CDA Wrapper – CDA Wrapped Text Report Option

4380

This section outlines the content of the HL7 CDA R2 wrapper for the text content. We note herethat requirements specified below are to ensure the presence of a minimum amount of wrapper
data in order to enhance description and facilitate sharing of the document. It should be notedthat the "nullFlavor" value expresses missing values in the CDA, e.g., it may be appropriate if
such information cannot be derived from DICOM objects.
Implementers of the “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.

4385

4390

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 R24395

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
4400

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

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:

4405

•
4410

•

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.

___________________________________________________________________________
180
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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
4415

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)

4420

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)

4425

4430

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

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.

___________________________________________________________________________
181
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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>

4.68.4.1.2.3.5.1.5 ClinicalDocument/custodian
4435

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

4440

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

4445

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

___________________________________________________________________________
182
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.68.4.1.2.3.5.1.8 ClinicalDocument/component/nonXMLBody
4450

4455

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

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.

4460

4465

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>

4.68.4.1.2.4 Use of Document Sharing 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:
4470•

Submission Set 1 includes a report and a manifest that are stored in the XDS Document
Repository. The manifest references DICOM instances that are archived in the ImageManager/Image Archive. The DocumentEntry.referenceIdList metadata attributes for the
manifest and the report includes the same fully qualified Accession Number associatedwith the originating Requested Procedure for the prior.

4475

•

Submission Set 2 includes one single manifest. The referenceIdList metadata attribute forthe manifest includes the fully qualified Accession Number associated with theoriginating Requested Procedure for the current study.

___________________________________________________________________________
183
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________•
4480

Submission Set 3 includes a single report. The referenceIdList metadata attribute for thereport includes the fully qualified Accession Number associated with the originating
Requested Procedure for the current study, since it was generated by interpreting theimages referenced by the manifest in Submission Set 2. Submission Set 3 references the
manifest from Submission Set 2, and the report and manifest from Submission Set 1 since
the earlier report, the images referenced by the earlier manifest, and images referenced by
the current manifest were used 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

4485

4490

Images and Evidence
Documents Referenced in
Manifest

Figure 4.68.4.1.2.4-1: Imaging Information Sharing Submission Set

If the submitted reports and image manifests are for the same Requested Procedure, then themetadata for the report and for the image manifest may include the same fully qualified
Accession Number in the referenceIdList. This will enable the unambiguous association ofreports to the set of DICOM instances related to the Requested Procedure.
4.68.4.1.2.4.2 Linking Report to prior report

4495

A Submission Set containing a report can reference the manifest DocumentEntry for a set ofimages published in a prior submission if the prior images were used in creating theinterpretation. Likewise the new Submission Set can reference a report DocumentEntry from aprevious submission. The Accession Number(s) of the prior images and reports will be different
from the Accession Number(s) for the current images and reports.
4.68.4.1.3 Expected Actions
The Document Repository will receive this message and will process it according to therequirements specified in ITI TF-2b: 3.41.4.1.3.
___________________________________________________________________________
184
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4500

4505

4.68.4.2 Provide and Register Imaging Document Set – MTOM/XOP Response
message
The XDS Document Repository sends a Provide and Register Imaging Document Set –MTOM/XOP Response message when the processing of a Provide and Register Imaging
Document Set – MTOM/XOP Request message is complete. The specification of the trigger
events, message semantics and expected actions are the same as those specified in ITI TF-2b:
3.41.4.2.
The conditions of failure and possible error messages are given in the ebRS standard. The XDS-I
Imaging Document Source shall handle all error messages detailed for the Provide and Register
Document Set-b [ITI-41] transaction in ITI TF-3: Table 4.2.4.1-2 “Error Codes”.

4510

4.69 Retrieve Imaging Document Set [RAD-69]
This section corresponds to transaction [RAD-69] of the IHE Radiology Technical Framework.
“Retrieve Imaging Document Set” is used by:

4515

•

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, theRetrieve Document Set [ITI-43] transaction of the IHE IT Infrastructure Technical Framework.
It adds minor additional semantics and constraints on the requirements defined in [ITI-43].
4520

4.69.1 Scope
This transaction is used by the XDS-I Imaging Document Consumer to retrieve a set of DICOM
objects from the XDS-I Imaging Document Source or an XCA-I Initiating Imaging Gateway.
This transaction is also used by a XCA-I Responding Imaging Gateway to retrieve a set of
DICOM objects from an XDS-I Imaging Document Source in its own community.

4525

The XDS-I Imaging Document Consumer gains access to the manifest object (KOS) previously
retrieved from the XDS Document Repository by the grouped XDS Document Consumer via the
Retrieve Document Set [ITI-43] transaction. The XDS-I Imaging Document Consumer uses theinformation in the KOS to retrieve instances of interest.

___________________________________________________________________________
185
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.69.2 Use Case Roles

ImagingDocument
SourceInitiating
Imaging
Gateway

Imaging Document
Consumer

Responding
Imaging
Gateway

Retrieve Imaging
Document Set

4530
Actor: Imaging Document Consumer
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 Gateway4535

Role: Issues a web service request to retrieve a set of DICOM instances from an Imaging
Document Source.
Actor: Imaging Document Source

4540

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

4545

For a list of the standards inherited from the underlying Retrieve Document Set [ITI-43]
transaction, see ITI TF-2b: 3.43.3.

___________________________________________________________________________
186
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.69.4 Messages
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

4550

Figure 4.69.4-1: Interaction Diagram

4.69.4.1 Retrieve Imaging Document Set Request message
This message is an extension of the Retrieve Document Set transaction as defined in ITI TF-2b:
3.43.
4555

4560

•

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.

___________________________________________________________________________
187
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.69.4.1.1 Trigger Events

4565

4570

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

4575

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.
4.69.4.1.2 Message Semantics
The Retrieve Imaging Document Set Request shall carry the following information:

4580

•

A required repositoryUniqueId that identifies the XDS-I Imaging Document Source fromwhich 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 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:

4585

4590

4595

___________________________________________________________________________
188
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4600

•

the Retrieve Imaging Document Set request is to an XCA-I Initiating Imaging
Gateway, or•

the Retrieve Imaging Document Set request is from a XCA-I Responding Imaging
Gateway to an XDS-I Imaging Document Source.

The message shall be structured as described in Section 4.69.5 Protocol Requirements.
4.69.4.1.3 Expected Actions
4605

When receiving a Retrieve Imaging Document Set Request, an Imaging Document Source orInitiating Imaging Gateway shall generate a Retrieve Imaging Document Set Response.
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.

4610

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

4615

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

4620

4625

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

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 the4630___________________________________________________________________________
189
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
transfer syntax changed to the requested transfer syntax. In addition, the pixel data
Attribute (7Fe0,0010) tag will have been removed and replaced with a Pixel Data
Provider URL (0028,7FE0) tag. The URL represents the JPIP request and will include thespecific target information.

4635•

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:

4640

4645

•

Pixel Data Provider URL (0028,7FE0) =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2,•

URL Generated by the application =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200

The conditions of failure and possible error messages are given in the ebRS standard and detailedin ITI TF-3: Table 4.2.4.2-4 “[ITI-43] Retrieve Document Set and [ITI-39] Cross Gateway
Retrieve Responses”.
4650

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.

4655

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.

4660

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.

4665

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.

4670

The Initiating Imaging Gateway, Responding Imaging Gateway, the Image Document Source
and the Image Document Consumer shall support the Asynchronous Web Services Methods in___________________________________________________________________________
190
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
the ITI TF-2x: Appendix V.5: Web Services for IHE Transactions, which also includes
additional considerations for implementers.
4.69.5 Protocol Requirements
4675

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:

4680

•

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.

•

Accept the Retrieve Imaging Document Set Response message in MTOM/XOP format.
WSDL Namespace Definitions

4685

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

4690

4695

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 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”___________________________________________________________________________
191
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4700

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.

4705

For informative WSDL for the Imaging Document Source and Responding Imaging Gateway 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:

4710

•

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

4715

4720

4725

4730

•

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

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

The <ihe:RetrieveDocumentResponse/> element for use with the Retrieve Imaging Document
Set Response Message is defined as:___________________________________________________________________________
192
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________•A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element•

A conditionally required sequence, if a matching document exists with
<ihe:DocumentResponse/> elements containing

4740

•

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.

•

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

4745

4750

4755

4760

4765

The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall
status of the request: It shall contain one of the following values:
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

4770

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.
For each document requested in a
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:
If a warning is reported when retrieving the document, then a/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:___________________________________________________________________________
•

4775

193
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4780

4795

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

4785

4790

•

•

@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error•@errorCode is specified•@codeContext contains the error message•@location contains the DocumentUniqueId of the document requested•

No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned•If the document is successfully retrieved (without warning) then no/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be present and a/RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned
containing the document as an XOP Infoset.

The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not
used in this transaction.
4800

The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in thistransaction.
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

4805

4810

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.
___________________________________________________________________________
194
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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
4815
4820
4825
4830
4835
4840
4845
4850

4.69.5.1.1.1 Synchronous Web Services Exchange<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe: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><iherad:RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><iherad:StudyRequest studyInstanceUID="1.3.6.1.4...101"><iherad: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></iherad:SeriesRequest></iherad:StudyRequest><iherad:TransferSyntaxUIDList><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.1</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.57</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.70</iherad:TransferSyntaxUID></iherad:TransferSyntaxUIDList></iherad:RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.69.5.1.1.2 Asynchronous Web Services Exchange
4855
4860
4865
4870

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe: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:Address></a:ReplyTo><a:To >http://localhost:2647/XdsService/IHEXDSIDocSource.svc</a:To></s:Header><s:Body><iherad:RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><iherad:StudyRequest studyInstanceUID="1.3.6.1.4...101"><iherad:SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest>___________________________________________________________________________
195
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4875
4880
4885

<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></iherad:SeriesRequest></iherad:StudyRequest><iherad:TransferSyntaxUIDList><iherad:TransferSyntaxUID>1.2.840.10008.1.2.1</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID>1.2.840.10008.1.2.4.57</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID>1.2.840.10008.1.2.4.70</iherad:TransferSyntaxUID></iherad:TransferSyntaxUIDList></iherad:RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.69.5.1.2 Sample Retrieve Document Set SOAP Response
4890

4895
4900
4905
4910
4915

4920
4925
4930

4.69.5.1.2.1 Synchronous Web Services Exchange<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><ihe:RetrieveDocumentSetResponse xmlns:ihe="urn:ihe:iti:xds-b:2007"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><ihe:DocumentResponse><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</ihe:Document></ihe:DocumentResponse><ihe:DocumentResponse><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</ihe:Document></ihe:DocumentResponse></ihe:RetrieveDocumentSetResponse></s:Body></s:Envelope>

4.69.5.1.2.2 Asynchronous Web Services Exchange<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo><a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentConsumerReceiver.svc</a:To></s:Header><s:Body><ihe:RetrieveDocumentSetResponse xmlns:ihe="urn:ihe:iti:xds-b:2007"___________________________________________________________________________
196
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

4935
4940
4945

4950

xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><ihe:DocumentResponse><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</ihe:Document></ihe:DocumentResponse><ihe:DocumentResponse><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</ihe:Document></ihe:DocumentResponse></ihe:RetrieveDocumentSetResponse></s:Body></s:Envelope>4.70 Temporarily, intentionally, left blankReserved for Image Manager Instances Stored [RAD-70]

4.71 Temporarily, intentionally, left blankReserved for Image Manager Storage Commitement [RAD-71].

4.72 Temporarily, intentionally, left blank4955

Reserved for Image Manager Instances Query [RAD-72].

4.73 Temporarily, intentionally, left blankReserved for Image Manager Instances Retrieval [RAD-73].

4.74 Replacement Instances Stored [RAD-74]
4960

This section corresponds to transaction [RAD-74] of the IHE Radiology Technical Framework.
Transaction [RAD-74] is used by the Change Requester and Image Manager / Archive actors.
4.74.1 Scope

4965

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.

___________________________________________________________________________
197
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.74.2 Use Case Roles
ChangeRequester

Image Manager /Image Archive

Replacement
Instances Stored

4970
Actor: Change Requester

Role: Transmit updated instances to Image Manager / Archive.
Actor: Image Manager / Archive
Role: Accept updated instances from Change Requester.
4975

4.74.3 Referenced Standard
DICOM PS3.4: Storage Service Class.
4.74.4 Messages
ChangeRequester

Image Manager/ Image Archive

Instances Stored (C-STORE)

Figure 4.74.4-1: Interaction Diagram

4980

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

4985

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

Have the same SOP Class as the replaced instance___________________________________________________________________________
198
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4990•

Belong to a new series•

Set the header information according to the correct modality worklist entry if correctionis the result of new modality worklist selection (see Section 4.74.4.1.2.1)•

Update the Critical Attributes as described in Table 4.74.4.1.2-1
Table 4.74.4.1.2-1: Critical Attributes for Replacement Instances

DICOM Attribute

4995

5000

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 isbeing referenced. Use an appropriate code from Table
4.74.4.1.2-2> 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.

5005

Table 4.74.4.1.2-2: Codes for Contributing Equipment
Code Value
DCM

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

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].
___________________________________________________________________________
199
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.74.4.1.2.1 Correction of Scheduled Procedure Information
5015

5020

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 [RAD-4] transaction. 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.

5025

5030

5035

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(return attributevalues)Filling values for: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.

___________________________________________________________________________
200
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________DICOM attribute

Modality Worklist(return attributevalues)Filling values for: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 Referential Integrity
5040

5045

Since SOP Instance UIDs are sometimes used as references in other related instances (e.g.,
Referenced Images Sequence in GSPS objects), the Change Requester shall ensure theconsistency of SOP Instance references for all instances that it is aware of (e.g., possesses) andfor SOP Classes for which it claims support in this respect in its DICOM Conformance
Statement, irrespective of the source of the instances, and irrespective of whether or not the
Change Requester is grouped with an Acquisition Modality, Evidence Creator or ImageManager/Archive. 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.

5050

A Change Requester may not have sufficient understanding of the structure of the underlying
references in the IOD to maintain referential integrity. At minimum, a Change Requester shall becapable of correcting SOP Instance UID references within Images, Presentation States, Key
Image Notes and Structured Reports. The Change Requester is not required to maintain thereferential integrity of references within Private Attributes.

5055

A Change Requester shall not replace SOP Instance UID references in the Rejection Note itself
and shall not replace the SOP Instance UIDs of the instances that are being rejected.

5060

As an example, if the Change Requester maintains a map of rejected SOP Instance UIDs toreplacement UIDs, if any, the Change Requester may replace all references in all instances torejected UIDs with replacement UIDs to maintain referential integrity without needing toinherently understand the entire structure of the IOD for a SOP Class and irrespective of whether
the instance is known at the time of the change request being received or subsequently.
The receiving Image Manager / Archive is not required to correct the content of other instances it
has stored in order to maintain the referential integrity within a study based on receipt of a
Rejection Note or replacement instances, though it is not prohibited from attempting to do so. If___________________________________________________________________________
201
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5065

5070

the Image Manager / Archive receives instances for the same study from sources other than thosegrouped with the Change Requester, then it is possible that the references to some instances may
be incorrect (e.g., When GSPS instances are not rejected in the Rejection Note but received froman Evidence Creator not grouped with the Change Requester, such GSPS instances may
reference rejected image instances and the Image Manager Archive has no means of determining
what the UIDs of the replacement instances are, if any).

5075

Note: A receiving Image Manager/Archive should be wary of removing an instance thatreferences rejected instances, since the other content of the referring instance may still be useful.
E.g., the referring instance might be a report with measurements that need to be retained, eventhough it contains references to rejected images. It may be appropriate to raise an exception andrequire human intervention in such cases.
4.74.4.1.3 Expected Actions
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 PS3.4 B.4.1).

5080

4.75 Cross Gateway Retrieve Imaging Document Set [RAD-75]
This section corresponds to transaction [RAD-75] of the IHE Radiology Technical Framework.
Transaction [RAD-75] is used by the Initiating Imaging Gateway and Responding Imaging
Gateway actors.
4.75.1 Scope

5085

5090

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.

___________________________________________________________________________
202
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5095

4.75.2 Use Case Roles
Responding
Imaging
Gateway

Initiating
Imaging
Gateway

Cross Gateway
Retrieve Imaging
Document Set
Figure 4.75.2: Use Case Roles

Actor: Initiating Imaging Gateway
5100

Role: To formulate a Cross Gateway Retrieve Imaging Document Set request
Actor: Responding Imaging Gateway
Role: To return the Imaging Document Set(s) requested.
4.75.3 Referenced Standard

5105

For a list of the standards inherited from the underlying Retrieve Document Set [ITI-43]
transaction; see ITI TF-2b: 3.43.3.
4.75.4 Messages

Initiating
Imaging
Gateway

Responding
Imaging
Gateway

Cross Gateway Retrieve
Imaging Document Set(Request)
Cross Gateway Retrieve
Imaging Document Set(Response)

Figure 4.75.4-1: Interaction Diagram___________________________________________________________________________
203
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5110

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

5115

5120

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

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

5125

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
Actors supporting this transaction shall support the Expected Actions described in [RAD-69].
See Section 4.69

5130

5135

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.
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
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.
Every RegistryError element returned in the response shall have the location attribute set to thehomeCommunityId of the Responding Imaging Gateway.

5140

5145

The Initiating Imaging Gateway 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 original[RAD-69] request from the Imaging Document Consumer with both DocumentResponse andRegistryErrorList elements in one response and specify PartialSuccess status.
___________________________________________________________________________
204
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Note: The Responding Imaging Gateway may have suppressed failures resulting in the Initiating Imaging Gatewayreporting a success.

4.75.4.2 Asynchronous Web Service Method
5150

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.
The Initiating Imaging Gateway supporting this method shall use the non-anonymous response
EPR in the WS-Addressing replyTo header.

5155

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.
4.75.5 Protocol Requirements

5160

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

5165

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

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

5170
The /definitions/message/part/@element attribute of the Cross Gateway Retrieve Imaging
Document Set Request message shall be defined as“iherad:RetrieveImagingDocumentSetRequest”___________________________________________________________________________
205
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

5175

5180

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

5185

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

5190

The <iherad:RetrieveImagingDocumentSetRequest/> element is defined in Section 4.69.5. Whenused 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).
4.75.5.1 Sample SOAP Messages

5195

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.

5200

Samples presented in this section are also available online on the IHE FTP site, see
ftp://ftp.ihe.net/TF_Implementation_Material/Rad/.

___________________________________________________________________________
206
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
4.75.5.1.1 Sample Cross Gateway Retrieve Imaging Document Set SOAP Request
4.75.5.1.1.1 Synchronous Web Services Exchange
5205
5210
5215
5220
5225
5230
5235
5240

<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe: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><iherad:RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><iherad:StudyRequest studyInstanceUID="1.3.6.1.4...101"><iherad:SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe: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><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></iherad:SeriesRequest></iherad:StudyRequest><iherad:TransferSyntaxUIDList><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.1</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.57</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.70</iherad:TransferSyntaxUID></iherad:TransferSyntaxUIDList></iherad:RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.75.5.1.1.2 Asynchronous Web Services Exchange
5245
5250
5255
5260

<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSet</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><iherad:RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsi-b:2009"
xmlns:ihe="urn:ihe:iti:xds-b:2007"><iherad:StudyRequest studyInstanceUID="1.3.6.1.4...101"><iherad:SeriesRequest seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId>___________________________________________________________________________
207
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5265
5270
5275
5280

5285

<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:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></iherad:SeriesRequest></iherad:StudyRequest><iherad:TransferSyntaxUIDList><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.1</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.57</iherad:TransferSyntaxUID><iherad:TransferSyntaxUID> 1.2.840.10008.1.2.4.70</iherad:TransferSyntaxUID></iherad:TransferSyntaxUIDList></iherad:RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>

4.75.5.1.2 Sample Cross Gateway Retrieve Imaging Document Set SOAP
Response
4.75.5.1.2.1 Synchronous Web Services Exchange

5290
5295
5300
5305
5310
5315

<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action
s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse</a:Action><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo></s:Header><s:Body><ihe:RetrieveDocumentSetResponse xmlns:ihe="urn:ihe:iti:xds-b:2007"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><ihe:DocumentResponse><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</ihe:Document></ihe:DocumentResponse><ihe:DocumentResponse><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</ihe:Document></ihe:DocumentResponse></ihe:RetrieveDocumentSetResponse></s:Body></s:Envelope>

4.75.5.1.2.2 Asynchronous Web Services Exchange
5320<?xml version="1.0" encoding="UTF-8"?><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header>___________________________________________________________________________
208
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5325
5330
5335
5340
5345
5350

<a:Action
s:mustUnderstand="1">urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse</a:Action><a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID><a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a110-2201afedaa02</a:RelatesTo><a:To s:mustUnderstand="1">
http://192.168.2.4:9080/XcaiService/InitiatingImagingGatewayReceiver.svc </a:To></s:Header><s:Body><ihe:RetrieveDocumentSetResponse xmlns:ihe="urn:ihe:iti:xds-b:2007"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"><rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><ihe:DocumentResponse><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</ihe:Document></ihe:DocumentResponse><ihe:DocumentResponse><ihe:HomeCommunityId>urn:oid:1.2.3.4</ihe:HomeCommunityId><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId><ihe:mimeType>application/dicom</ihe:mimeType><ihe:Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</ihe:Document></ihe:DocumentResponse></ihe:RetrieveDocumentSetResponse></s:Body></s:Envelope>___________________________________________________________________________
209
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

5 Transaction Options on Other Domain Profiles
5355This 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:5360

IT Infrastructure Technical Framework Volume 2a Section 3.20 (ITI TF-2a: 3.20)

5.1 Record Audit Event [ITI-20]

5365

5370

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. See ITI TF-2a: 3.20 for the full definition ofthis 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.
5.1.1 Trigger Events and Message semantics

5375

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

5380

Table 5.1-1 lists all the trigger events for the generation of Audit Records. This is the table oftrigger events specified in ITI TF-2a: 3.20.4.1.1.1, 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.

5385

•

Health-service-event•

Medication•

Patient-care-assignment•

Patient-care-episode• Patient-care-protocol___________________________________________________________________________
210
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
5390

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

Security Alert(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

Trigger Event___________________________________________________________________________
211
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
Trigger Event

5395

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 TF-2a: Table 3.20.4.1.1.1-1 –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.

5400

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.

5405

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.

___________________________________________________________________________
212
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
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 torecord audit event

Patient Registration [RAD-1]

Patient-record-event

ADT
Order Placer, DSS/OF - when PHI ispresented

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

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 [RAD-8]

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive

Modality Presentation State Stored [RAD-9]
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 ispresented

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 Source

Study-used

Image Display, Imaging Document
Consumer

Retrieve Presentation States [RAD-17]
Creator Images Stored[RAD-18]

Creator Presentation State Stored [RAD-19]

Instances-Stored

Image Manager/Image Archive

Study-used

Image Display

Begin-storing-instances

Evidence Creator

Instances-Stored

Image Manager/Image Archive

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

Instances-Stored

Report Repository

Report Issuing [RAD-25]___________________________________________________________________________
213
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________IHE Radiology Transaction

ATNA Trigger Event(s)Actor(s) that shall be able torecord audit event

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

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 Information

Image Manager/Image Archive

Query Key Image Notes [RAD-30]
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

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

None

Account Management[RAD-36][RAD-41]

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
ComposerAppointment 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]
Store Additional Teaching File Information[RAD-52]

Begin-storing-instances

Export Selector

Instances-Stored

Export Manager

Begin-storing-instances

Export Selector

Instances-Stored

Export Manager___________________________________________________________________________
214
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________IHE Radiology Transaction
Export Instances [RAD-53]
WADO Retrieve [RAD-55]

ATNA Trigger Event(s)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 [RAD-61]

Actor(s) that shall be able torecord audit event

Begin-storing-instances

Sender Importer shall audit

Instances-Stored

Receiver (IM/IA) shall audit

Begin-storing-instances

Acquisition Modality

Instances-Stored

Image Manager/Image Archive, Dose
Information Reporter, Dose Information
Consumer

Begin-storing-instances

Dose Information Reporter – when PHI isexported

Instances-Stored

Dose Registry – when PHI is exported

Query Dose Information [RAD-64]

Query Information

Image Manager/Image Archive

Retrieve Dose Information [RAD-65]

Instances-Stored

Image Manager/Image Archive

Study-used

Dose Information Reporter, Dose
Information Consumer

Instances-deleted

Sender: Acquisition Modality, Evidence
Creator, Change Requester.
Note: The actor rejecting/ correcting
images must assume that the Image
Archive may hide the images (similar tological deletion).

Instances-deleted

Receiver: Image Archive.
Note: Although an Archive may be
configured to provide rejected images, thismay be changed any time by users. Thus,
it is valuable to log this.

Patient Demographics Query [ITI-21]

Query Information

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

Begin-storing-instances
Instances-stored

Sender: Change Requester

Instances-stored

Receiver: Image Manager / Archive.

Instances-Stored

Responding Imaging Gateway

Study-used

Initiating Imaging Gateway

Store Dose Information [RAD-62]

Submit Dose Information [RAD-63]

Rejection Note Stored [RAD-66]

Replacement Instances Stored [RAD-74]

Cross Gateway Retrieve Imaging Document Set[RAD-75]5410___________________________________________________________________________
215
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix A:

Deprecated___________________________________________________________________________
216
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix B:

Deprecated5415___________________________________________________________________________
217
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix C:

Attribute Consistency between General Purpose
Worklist, SPS, PPS and Resulting Composite IODs in
Post-Processing Workflow

5420

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 post-processing operations, and also
the N-ACTION command that is used to claim and complete workitems.

5425

C.1 Integration-critical Attributes
The table below shall be interpreted as follows:

5430

5435

•

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

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]

--

KIN

___________________________________________________________________________
218
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
GeneralPurposeWorklist

GeneralPurpose SPS
N-ACTION

GeneralPurpose PPS

Images and
GSPS IOD

SR Based
Evidence
Documents

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

Referenced Study
Component
Sequence [3]Referenced Study
Component
Sequence [2]Referenced Study
Component
Sequence [2]KIN

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 ID[1C]___________________________________________________________________________
219
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
GeneralPurposeWorklist

GeneralPurpose SPS
N-ACTION

GeneralPurpose PPS

Images and
GSPS IOD

SR Based
Evidence
Documents

KIN>Requested
Procedure Code
Sequence [2]>Requested
Procedure Code
Sequence [2]>Requested
Procedure Code
Sequence [1C]

>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
Number [2]>Accession
Number [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]>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]___________________________________________________________________________
220
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

5440

5445

Appendix D:

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:

5450

5455

•

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]___________________________________________________________________________
221
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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]___________________________________________________________________________
222
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________
General Purpose
Worklist

General Purpose
SPS N-ACTION

General Purpose
PPS

SR Based Report
Documents

Performed Procedure
Step Description [1]5460___________________________________________________________________________
223
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix E:

5465

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 (DICOM PS3.10, PS3.11 and PS3.12). This appendix is
simply intended to be a reminder for the most common DICOM issues that have resulted in thepast in incompatibilities 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 the IHE PDI Profile shall be familiar with.

5470

5475

1. If CD Media is used, 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 PDI Profile. A UDF file system is not allowed for CD Media, unless an
ISO 9660 Level 1 Filesystem is also 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 toapplication software as lowercase or mixed case depending on the operating system’s
mount behavior; accordingly, all Portable Media Displays and Portable Media Importers
shall be case insensitive in this respect, whether the media is CD, DVD or USB.
2. The DICOMDIR file shall be at the root directory of the Interchange Media

5480

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.

5485

5. Non-DICOM files may have extensions with more than 3 characters.
6. DICOM files shall have no extension.

5490

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. Some authoring software fails to include the required “.” prior to
the “;1”, or omits the required “.;1” entirely, violating the ISO 9660 Level 1 standard; thiscommon error has no interoperability impact, and may safely be ignored by a reader.
8. The version number of the file name shall not be included in the reference data element in
the DICOMDIR.

5495

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), or theappropriate compressed Transfer Syntax for the DVD and USB Options.
11. DICOM File Meta-Information shall be in Explicit VR Little Endian (not Implicit)___________________________________________________________________________
224
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

5500

12. File Meta Information Version (0002,0001) shall contain a two byte OB value consistingof a 0x00 byte, followed by 0x01 byte, and not the value 0x0001 encoded as a little
endian 16 bit short value, which would be the other way around.
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.

5505

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.

5510

16. The file meta information header shall contain an attribute (0002,0000) Group Lengthwith a correct value as specified in DICOM PS3.10.
17. The physical format of the DICOM DVD discs or USB media is specified in DICOM
PS3.12. The physical format of the DICOM CD-R discs shall comply with theapplication definitions within ISO/IEC 10149 Part II as specified in PS3.12. This allows
discs to be written with:

5515

•

Mode 1 sectors or•Mode 2, Form 1 sectors with CD-ROM-XA File Number = 0, Channel Number = 0
and Coding Information Byte = 0.

___________________________________________________________________________
225
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix F:
5520

Example Created Media Instance Content

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 Section 4.47.4.1.2.2:
patient namecreation datename of the institution that created the media/README.TXT

File with content per Section 4.47.4.1.2.2/INDEX.HTM

File with content per Section 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

Directory with content per Section 4.47.4.1.2.2:
Image object 1
Image object 2/DICOM /NNNNN/DICOM /98732/DICOM /12312

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

5525
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.
___________________________________________________________________________
226
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Content element(s)Identification Marking

Description
Marker with content per Section 4.47.4.1.2.2:
patient namecreation datename of the institution that created the media
media type: “DICOM ONLY”
File with content per Section 4.47.4.1.2.2/README.TXT/DICOMDIRDICOM Directory file referencing all DICOM instances:
all DICOM images
the SR object/DICOM//DICOM/78567856/DICOM/78567857.
.
.
/DICOM/NNNNNNN/DICOM/12343412

Directory with content per Section 4.47.4.1.2.2:
Image object 1
Image object 2.
.
.
Image object N
Basic Text DICOM Structured Report object

5530___________________________________________________________________________
227
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix G:
G.1:
5535

5540

5545

5550

5555

5565

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

5560

Configuration for Accessing DICOM, WADO and Web
Services Retrieve Services

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 Retrieve [RAD-55]transaction, 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.
___________________________________________________________________________
228
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

5570

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

5580

5585

Mapping DICOM AE Title to Web Services Address

To use the Retrieve Imaging Document Set [RAD-69] transaction 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.

___________________________________________________________________________
229
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Appendix H:

Example Template for Teaching File Structured Report
Manifests

Included here is a DICOM PS3.16 style template containing:
5590

5595

•

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

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.

___________________________________________________________________________
230
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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,“Diagnosis”)

1-nU___________________________________________________________________________
231
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Rel with
parentConcept Name

VM

Req
Type

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

Value Type

Cond

Value Set Constraint___________________________________________________________________________
232
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

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

Table H-2: Categories of Teaching Files (American Board of Radiology categories)
Coding Scheme
Designator

Code ValueIHERADTF

TCE301

Musculoskeletal

IHERADTF

TCE302

Pulmonary

IHERADTF

TCE303

Cardiovascular

IHERADTF

TCE304

Gastrointestinal

IHERADTF

TCE305

Genitourinary

IHERADTF

TCE306

Neuro

IHERADTF

TCE307

Vascular andInterventional

IHERADTF

TCE308

Nuclear

IHERADTF

TCE309Ultrasound

IHERADTF

TCE310Pediatric

IHERADTF

TCE311

BreastCode Meaning

Table H-3: Levels of Teaching Files
Coding Scheme
Designator

Code ValueIHERADTF

TCE201Primary

IHERADTF

TCE202

Intermediate

IHERADTF

TCE203

Advanced

Code Meaning___________________________________________________________________________
233
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-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 suchmechanisms may be effective for de-identification for distribution outside an institution, they
may not be not sufficient within an institution.
___________________________________________________________________________
234
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________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 PS3.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 DICOM PS3.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.

___________________________________________________________________________
235
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3 (RAD TF-3): Transactions (continued)______________________________________________________________________________GLOSSARY
Please see RAD TF-1: Appendix E - Glossary___________________________________________________________________________
236
Rev. 18.0 Final Text – 2019-08-09

Copyright © 2019: IHE International, Inc.