Integrating the Healthcare Enterprise

5

10

IHE Radiology (RAD)Technical Framework
Volume 1
IHE RAD TF-1
Integration Profiles

15

20

Revision 13.0 – Final Text
July 30, 201425

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________CONTENTS
30

35

40

45

50

55

60

65

70

1 Introduction .............................................................................................................................. 10
1.1 Overview of Technical Framework .................................................................................. 10
1.2 Overview of Volume 1...................................................................................................... 11
1.3 Audience ........................................................................................................................... 11
1.4 Relationship to Standards ................................................................................................. 11
1.5 Relationship to Real-world Architectures ......................................................................... 12
1.6 Conventions ...................................................................................................................... 12
1.6.1 Actor and Transaction Diagrams and Tables............................................................. 13
1.6.2 Process Flow Diagrams ............................................................................................. 13
1.6.3 Normative versus informative contents of the Technical Framework ....................... 13
1.6.4 Technical Framework Referencing............................................................................ 14
1.7 Scope Additions for 2013 – 2014 (Year 14) ..................................................................... 14
1.8 Comments ......................................................................................................................... 14
1.9 Copyright Permission........................................................................................................ 15
1.10 IHE Radiology Technical Framework Development and Maintenance Process .............. 15
2 Integration Profiles ................................................................................................................... 19
2.1 Integration Profiles Overview ........................................................................................... 24
2.1.1 Scheduled Workflow (SWF) ..................................................................................... 25
2.1.2 Patient Information Reconciliation (PIR) .................................................................. 25
2.1.3 Consistent Presentation of Images (CPI) ................................................................... 25
2.1.4 Presentation of Grouped Procedures (PGP) .............................................................. 26
2.1.5 Access to Radiology Information (ARI).................................................................... 26
2.1.6 Key Image Note (KIN) .............................................................................................. 26
2.1.7 Simple Image and Numeric Report (SINR)............................................................... 26
2.1.8 Basic Security (SEC) - DEPRECATED .................................................................... 26
2.1.9 Charge Posting (CHG) ............................................................................................... 26
Post-Processing Workflow (PWF) ..................................................................... 27
2.1.102.1.11
Reporting Workflow (RWF) .............................................................................. 27
2.1.12
Evidence Documents (ED) ................................................................................. 27
2.1.13
Portable Data for Imaging (PDI) ........................................................................ 27
2.1.14NM Image (NM)................................................................................................. 28
2.1.15Teaching File and Clinical Trial Export (TCE) .................................................. 28
2.1.16
Cross-Enterprise Document Sharing for Imaging (XDS-I.b) ............................. 28
2.1.17
Mammography Image (MAMMO) .................................................................... 28
2.1.18
Image Fusion (FUS) ........................................................................................... 29
2.1.19
Import Reconciliation Workflow (IRWF) .......................................................... 29
2.1.20
Radiation Exposure Monitoring (REM) ............................................................. 29
2.1.21
Mammography Acquisition Workflow (MAWF) .............................................. 29
2.1.22
MR Diffusion Imaging (DIFF) ........................................................................... 29
2.1.23
CT/MR Perfusion Imaging with Contrast (PERF) ............................................. 29
2.1.24
Basic Image Review (BIR) ................................................................................. 29______________________________________________________________________________
2
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

75

80

85

90

95

100

105

110

2.1.25
Chest X-Ray CAD Display (CXCAD) ............................................................... 29
2.1.26
Imaging Object Change Management (IOCM) .................................................. 30
2.1.27
Cross-Community Access for Imaging (XCA-I) ............................................... 30
2.1.28
Imaging Object Change Management Integration Profile. Error! Bookmark notdefined.
2.2 Options to other Domains’ Profiles .................................................................................. 30
2.2.1 ITI-Audit Trail and Node Authentication .................................................................. 30
2.3 Actor Descriptions ............................................................................................................ 30
2.4 Transaction Descriptions .................................................................................................. 34
2.5 Product Implementations .................................................................................................. 38
3 Scheduled Workflow (SWF) .................................................................................................... 42
3.1 Actors/Transactions .......................................................................................................... 43
3.2 Scheduled Workflow Integration Profile Options ............................................................ 45
3.2.1 HL7 v2.5.1 Option ..................................................................................................... 47
3.3 Scheduled Workflow Process Flow .................................................................................. 47
3.3.1 Administrative and Procedure Performance Process Flow ....................................... 47
3.3.2 Patient Update Flow .................................................................................................. 50
3.3.3 Order Change Flow.................................................................................................... 53
3.3.4 Exception Management Workflow ............................................................................ 57
3.3.5 Implicit Post-Processing ............................................................................................ 62
3.3.6 Departmental Appointment Booking ......................................................................... 66
3.4 Data Model for Scheduled Workflow ............................................................................... 67
3.4.1 Model of the Real World ........................................................................................... 67
3.4.2 Scheduled Workflow Concepts in Practice ............................................................... 69
3.4.3 Scheduled Workflow Information Model .................................................................. 74
4 Patient Information Reconciliation (PIR) ................................................................................ 77
4.1 Actors/Transactions .......................................................................................................... 78
4.2 Patient Information Reconciliation Integration Profile Options ....................................... 80
4.2.1 HL7 v2.5.1 Option ..................................................................................................... 81
4.3 Unidentified Patient Image Acquisition and Reconciliation ............................................ 81
4.3.1 Patient Information Reconciliation during Image Acquisition .................................. 82
4.4 Use Cases .......................................................................................................................... 83
4.4.1 Case 1: Unidentified Patient Registered at ADT and Ordered at the Order Placer ... 83
4.4.2 Case 2: Unidentified Patient Registered at ADT and Ordered at Department System
Scheduler/Order Filler ............................................................................................... 85
4.4.3 Case 3: Unidentified Patient Registered at ADT but Completed at Modality Prior toOrder .......................................................................................................................... 86
4.4.4 Case 4: Unidentified Patient Assigned Temporary Departmental ID and Scheduled at
DSS/Order Filler ........................................................................................................ 88
4.4.5 Case 5: Image Acquisition Completed Without Scheduling at Department System
Scheduler/Order Filler ............................................................................................... 89
4.4.6 Case 6: Patient Information Reconciliation During Image Acquisition .................... 92
5 Consistent Presentation of Images (CPI) ................................................................................. 94
5.1 Actors/Transactions .......................................................................................................... 94______________________________________________________________________________
3
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
115

120

125

130

135

140

145

150

155

5.2 Consistent Presentation of Images Integration Profile Options ........................................ 96
5.3 Consistent Presentation of Images Process Flow.............................................................. 97
6 Presentation of Grouped Procedures (PGP) ........................................................................... 100
6.1 Actors/Transactions ........................................................................................................ 100
6.2 Presentation of Grouped Procedures Integration Profile Options................................... 101
6.3 Presentation of Group Procedures Process Flow ............................................................ 102
7 Access to Radiology Information (ARI) ................................................................................ 105
7.1 Actors/Transactions ........................................................................................................ 105
7.2 Access to Radiology Information Integration Profile Options ....................................... 106
7.3 Multiple Sources Option ................................................................................................. 107
7.3.1 Requirements for the Multiple Sources Option ....................................................... 107
8 Key Image Note (KIN)........................................................................................................... 109
8.1 Actors/Transactions ........................................................................................................ 109
8.2 Key Image Notes Integration Profile Options ................................................................ 110
8.3 Key Image Note Pattern .................................................................................................. 110
9 Simple Image and Numeric Report (SINR) ........................................................................... 112
9.1 Actors/Transactions ........................................................................................................ 112
9.2 Simple Image and Numeric Report Integration Profile Options .................................... 113
9.3 Diagnostic Report Process Flow ..................................................................................... 114
9.4 Diagnostic Reporting Use Cases ..................................................................................... 116
9.4.1 Simple Image Report ............................................................................................... 116
9.4.2 Simple Image and Numeric Report ......................................................................... 117
9.4.3 Observation Context ................................................................................................ 118
10 Basic Security (SEC) - DEPRECATED ................................................................................ 119
11 Charge Posting (CHG) ........................................................................................................... 120
11.1 Actors/Transactions ........................................................................................................ 121
11.2 Charge Posting Integration Profile Options .................................................................... 122
11.3 Charge Posting Process Flow.......................................................................................... 124
11.3.1
Use Cases.......................................................................................................... 125
11.3.2
Technical Billing .............................................................................................. 125
11.3.3
Professional Billing .......................................................................................... 125
11.4 Data Model for Charge Posting ...................................................................................... 126
11.4.1Model of the Real World .................................................................................. 126
12 Post-Processing Workflow (PWF) ......................................................................................... 128
12.1 Actors/Transactions ........................................................................................................ 128
12.2 Post-Processing Workflow Integration Profile Options ................................................. 130
12.3 Implementation Issues .................................................................................................... 131
12.3.1
Actor Grouping Clarification ........................................................................... 131
12.3.2
Input Availability.............................................................................................. 132
12.3.3Evidence Creators in Scheduled Workflow vs. Post-Processing Workflow .... 133
12.4 Post-Processing Process Flow ........................................................................................ 133
12.4.1
Computer Aided Detection Use Case ............................................................... 133
12.4.2
3D Reconstruction Use Case ............................................................................ 134
12.4.3Post-Processing Process Flow Diagrams.......................................................... 134______________________________________________________________________________
4
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

160

165

170

175

180

185

190

195

200

13 Reporting Workflow (RWF) .................................................................................................. 138
13.1 Actors/Transactions ........................................................................................................ 138
13.1.1
Actor Grouping Clarification ........................................................................... 140
13.1.2
Input Availability.............................................................................................. 141
13.2 Reporting Workflow Integration Profile Options ........................................................... 142
13.2.1
HL7 v2.5.1 Option ............................................................................................ 142
13.3 Reporting Tasks .............................................................................................................. 142
13.4 Diagnostic Reporting Use Cases ..................................................................................... 147
13.4.1
Use case 1: Predefined Report .......................................................................... 147
13.4.2Use case 2: Workitem Deferred ....................................................................... 148
13.4.3Use case 3: Direct Report Creation .................................................................. 149
13.4.4Use case 4: Interpretation and Dictation .......................................................... 150
13.4.5Use case 5: Transcription ................................................................................. 152
13.4.6
Use case 6: Partial completion ......................................................................... 153
13.4.7Use case 7: Verification.................................................................................... 154
13.4.8Use case 8: Double reading .............................................................................. 155
13.4.9Use case 9: Comparison ................................................................................... 156
13.4.10 Use case 10: Review ......................................................................................... 157
13.4.11 Use case 11: Over Read .................................................................................... 157
14 Evidence Documents (ED)..................................................................................................... 158
14.1 Actors/Transactions ........................................................................................................ 158
14.2 Evidence Documents Integration Profile Options .......................................................... 159
14.3 Evidence Document Process Flow.................................................................................. 160
15 Portable Data for Imaging Integration Profile ....................................................................... 163
15.1 Actors/ Transactions ....................................................................................................... 163
15.2 Portable Data for Imaging Integration Profile Options................................................... 165
15.3 Portable Data for Imaging Process Flow ........................................................................ 165
15.3.1
Use Cases.......................................................................................................... 166
15.3.2
Process Flow Description ................................................................................. 166
15.4 Media Content ................................................................................................................. 170
15.4.1
DICOM Content ............................................................................................... 170
15.4.2Web Content Option ......................................................................................... 170
15.4.3
Other Content ................................................................................................... 170
15.5 Security and Privacy Aspects.......................................................................................... 171
16 NM Image Integration Profile ................................................................................................ 172
16.1 Actors/ Transactions ....................................................................................................... 172
16.2 NM Image Integration Profile Options ........................................................................... 174
16.3 NM Image Process Flow ................................................................................................. 175
17 Teaching File and Clinical Trial Export (TCE) ..................................................................... 176
17.1 Actors/Transactions ........................................................................................................ 176
17.2 Teaching File and Clinical Trial Export Integration Profile Options ............................. 177
17.2.1
De-identify Pixel Data Option .......................................................................... 178
17.2.2Remap Identifiers Option ................................................................................. 178
17.2.3
Additional Teaching File Information Option .................................................. 179______________________________________________________________________________
5
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

205

210

215

220

225

230

235

240

245

17.2.4
Delay for Reason Option .................................................................................. 179
17.3 Implementation Issues .................................................................................................... 179
17.4 Teaching File and Clinical Trial Export Integration Profile Process Flow .................... 180
17.4.1
Teaching File Use Cases .................................................................................. 181
17.4.2Clinical Trial Use Cases ................................................................................... 186
17.4.3
Research Collection Use Cases ........................................................................ 187
17.4.4
Publication Authoring Use Cases ..................................................................... 187
18 Cross-Enterprise Document Sharing for Imaging (XDS-I.b) Integration Profile .................. 188
18.1 Actors/ Transactions ....................................................................................................... 189
18.2 Integration Profile Options ............................................................................................. 191
18.2.1
Set of DICOM Instances Option ...................................................................... 192
18.2.2
PDF Report Option ........................................................................................... 192
18.2.3
CDA Wrapped Text Report Option .................................................................. 192
18.2.4
CDA Imaging Report with Structured Headings Option ................................. 192
18.3 Image Information Sharing Process Flow....................................................................... 192
18.3.1
Overview of Imaging Information Sharing Use Cases..................................... 193
18.3.2
Assumptions ..................................................................................................... 193
18.3.3Use cases .......................................................................................................... 194
18.3.4
Queries .............................................................................................................. 203
18.4 Consumer Processing ...................................................................................................... 204
18.4.1
Consumer Processing – Set of DICOM Instances ............................................ 204
18.5 Patient Information Reconciliation ................................................................................. 204
18.6 Security considerations ................................................................................................... 204
19 Mammography Image Integration Profile.............................................................................. 205
19.1 Actors/ Transactions ....................................................................................................... 205
19.2 Mammography Image Integration Profile Options ......................................................... 207
19.3 Mammography Image Profile Process Flow................................................................... 208
20 Image Fusion (FUS) ............................................................................................................... 209
21 Import Reconciliation Workflow (IRWF) ............................................................................. 210
21.1 Actors/Transactions ........................................................................................................ 210
21.2 Import Reconciliation Workflow Integration Profile Options ........................................ 212
21.2.1
Scheduled Import Option ................................................................................. 213
21.2.2
Unscheduled Import Option ............................................................................. 213
21.3 Integration Workflow Process Flow ............................................................................... 213
21.3.1
Import Process Flow ......................................................................................... 214
21.3.2
Import Exception Management Workflow ....................................................... 219
22 Radiation Exposure Monitoring (REM) Integration Profile .................................................. 220
22.1 Actors/ Transactions....................................................................................................... 221
22.2 Radiation Exposure Monitoring Integration Profile Options ......................................... 223
22.3 Radiation Exposure Monitoring Process Flow .............................................................. 224
22.3.1 General Case .......................................................................................................... 224
22.3.2
Real-World Use Cases ...................................................................................... 225
22.3.3
Example REM Profile Deployments ................................................................ 228
22.4 Radiation Exposure Monitoring Profile Security Considerations .................................. 229______________________________________________________________________________
6
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

250

255

260

265

270

275

280

285

290

22.5 Relation to Other Profiles............................................................................................... 230
22.5.1
Radiology Profiles ............................................................................................ 230
22.5.2
ITI Profiles........................................................................................................ 230
23 Mammography Acquisition Workflow (MAWF) .................................................................. 231
24 MR Diffusion Imaging (DIFF) .............................................................................................. 232
25 CT/MR Perfusion Imaging with Contrast (PERF) ................................................................. 233
26 Basic Image Review (BIR) .................................................................................................... 234
27 Chest X-Ray CAD Display (CXCAD) .................................................................................. 235
28 Imaging Object Change Management (IOCM)...................................................................... 236
28.1 Actors/ Transactions ....................................................................................................... 236
28.2 Imaging Object Change Management Integration Profile Options ................................ 238
28.3 Imaging Object Change Management Integration Profile Actor Groupings and Profile
Interactions ...................................................................................................................... 238
28.4 Imaging Object Change Management Process Flow ...................................................... 239
Use Case: Data Retention Expiration ............................................................... 240
28.4.128.4.2
Use Case: Image Rejection for Quality Reasons .............................................. 241
28.4.3
Use Case: Image Correction for Patient Safety Reasons.................................. 242
28.4.4
Use Case: Object Correction due to Modality Worklist Selection Error ......... 244
28.5 Imaging Object Change Management Security Considerations ..................................... 249
29 Cross-Community Access for Imaging (XCA-I) ................................................................... 251
29.1 Actors/ Transactions ....................................................................................................... 251
29.1.1
Actor Requirements .......................................................................................... 253
29.2 XCA-I Profile Options .................................................................................................... 253
29.3 XCA-I Process Flow ....................................................................................................... 253
29.3.1
Use Case – Image set sharing between communities ....................................... 253
29.3.2
Detailed Interactions ......................................................................................... 254
29.3.3
Actor Grouping Considerations ........................................................................ 257
29.4 XCA-I Security Considerations ...................................................................................... 258
29.4.1
XCA Risk Assessment ..................................................................................... 258
29.4.2Requirements/Recommendations ..................................................................... 258
29.4.3
Policy Choices .................................................................................................. 259
Appendix A: Clarification of Accession Number and Requested Procedure ID ................... 260
A.1 Structure of an Order for Imaging Service ..................................................................... 260
Appendix B: Topics for Standards Corrections or Supplements ........................................... 262
B.1 HL7 Topics ..................................................................................................................... 262
B.1.1 Version 2.5 ............................................................................................................... 262
B.1.2 HL7 Conformance ................................................................................................... 262
B.2 DICOM Topics ............................................................................................................... 262
Appendix C: Overview of the Information Exchange between Department System
Scheduler/Order Filler and Image Manager ........................................................................... 263
C.1 Exchange of Patient Information .................................................................................... 263
C.2 Exchange of Visit and Order Information ...................................................................... 263
C.3 Exchange of Procedure Information ............................................................................... 264
Appendix D: IHE Integration Statements .............................................................................. 265______________________________________________________________________________
7
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

295

300

305

310

315

320

325

330

D.1 Structure and Content of an IHE Integration Statement ................................................. 265
D.2 Format of an IHE Integration Statement ......................................................................... 266
Appendix E:
Nuclear Medicine ............................................................................................. 268
E.1 Introduction ..................................................................................................................... 268
E.2 NM Workflow Overview ................................................................................................ 268
E.2.1 Injection Steps ......................................................................................................... 269
E.2.2 Time Separated Acquisitions ................................................................................... 269
E.2.3 Reconstruction as a Separate Operation .................................................................. 269
E.2.4 Acquisition Post-Processing .................................................................................... 270
E.2.5 Clinical Post Processing .......................................................................................... 270
E.2.6 Display and Reviewing ............................................................................................ 271
E.2.7 Workflow Chaining ................................................................................................. 271
E.3 NM Worklists.................................................................................................................. 271
E.3.1 NM Worklist Guidelines.......................................................................................... 271
E.3.2 NM Worklist Examples ........................................................................................... 274
E.4 NM Data.......................................................................................................................... 277
E.4.1 Study UIDs and Series UIDs ................................................................................... 278
E.4.2 NM Image IOD: Multi-Frames and Vectors ........................................................... 279
E.4.3 Typical NM Data Dimensions ................................................................................. 279
E.5 NM Display..................................................................................................................... 280
E.5.1 NM Intensity and Color Mapping............................................................................ 281
E.5.2 NM Image Resizing ................................................................................................. 282
E.5.3 NM Display Examples ............................................................................................. 284
Appendix F:
Security Environment Considerations .............................................................. 289
Appendix G: Patient Information Reconciliation for XDS-I.b (INFORMATIVE) ............... 291
G.1 Context and Assumptions ............................................................................................... 291
G.1.1 XDS Affinity Domain Assumptions........................................................................ 291
G.1.2 Metadata in the Registry .......................................................................................... 292
G.1.3 Patient Identity Management in the XDS Registry ................................................. 292
G.1.4 Expected Implementation Models for Patient Identity Management ...................... 292
G.2 Patient Information Reconciliation (PIR) in an Affinity Domain .................................. 293
G.2.1 Patient Merge within XAD Patient Identity Domain .............................................. 293
G.2.2 Local Domain Patient Update - XAD Domain Patient ID does not change ............ 294
G.2.3 Local Domain Patient Update - XAD Domain Patient Merge ................................ 295
G.2.4 Local Domain Patient Merge – XAD Domain Patient ID does not change ............ 296
G.2.5 Local Domain Patient Merge – XAD Domain Patient Merge ................................. 297
Appendix H: Security considerations for XDS-I.b (informative) .......................................... 300
Appendix I:
Appendix I – Deployment of Dose Registries .................................................. 306
I.1 Dose Registry Deployment Issues .................................................................................. 306
I.1.1 Code Set Management ............................................................................................. 306
I.1.2 Configuration of Secure FTP (Submit Dose Information Transaction – RAD-63). 306
I.1.3 Alternative Transport Mechanisms.......................................................................... 306
I.1.4 Encapsulated Dose Registry Submission................................................................. 307
I.2 Real-World Projects ........................................................................................................ 308______________________________________________________________________________
8
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
335

I.3 Dose Monitoring Regulations ......................................................................................... 309
GLOSSARY ............................................................................................................................... 311______________________________________________________________________________
9
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1 Introduction
340

345

350

355

360

Integrating the Healthcare Enterprise (IHE) is an initiative promoting 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 on this document 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.

365

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

370

375

This document, the IHE Technical Framework, defines specific implementations of establishedstandards to achieve integration goals that promote appropriate sharing of medical information to
support optimal patient care. It is expanded annually, after a period of public review, andmaintained regularly through the identification and correction of errata. The current version, rev.
11.0, specifies the IHE transactions defined and implemented as of October 2012. The latest
version of the document is always available via the Internet at
http://www.ihe.net/Technical_Frameworks.
The IHE Technical Framework identifies a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,______________________________________________________________________________
10
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

380

standards-based transactions. It describes this body of transactions in progressively greater depth.
The present volume provides a high-level view of IHE functionality, showing the transactionsorganized into functional units called Integration Profiles that highlight their capacity to address
specific clinical needs. The subsequent volumes, II and III, provide detailed technicaldescriptions of each IHE transaction.
The other domains within the IHE initiative also produce Technical Frameworks within theirrespective areas that together form the IHE Technical Framework. All published IHE Technical
Frameworks are available at http://www.ihe.net/Technical_Frameworks.

385

Where applicable, references are made to other technical frameworks. For the conventions onreferencing other frameworks, see Section 1.6.4 within this volume.

1.2 Overview of Volume 1

390

The remainder of section 1 further describes the general nature, purpose and function of theTechnical Framework. Section 2 introduces the concept of IHE Integration Profiles that make up
the Technical Framework.
Section 3 and the subsequent sections of this volume provide detailed documentation on each
integration profile, including the clinical problem it is intended to address and the IHE actors andtransactions it comprises.

395

The appendices following the main body of the document provide detailed discussion of specificissues related to the integration profiles and a glossary of terms and acronyms used.

1.3 Audience
The intended audience of this document is:

400•

Technical staff of vendors participating in the IHE initiative•

IT departments of healthcare institutions•

Experts involved in standards development•

Anyone interested in the technical aspects of integrating healthcare information systems

1.4 Relationship to Standards

405

410

The IHE Technical Framework identifies functional components of a distributed healthcare
environment (referred to as IHE Actors), solely from the point of view of their interactions in thehealthcare enterprise. At its current level of development, it defines a coordinated set oftransactions based on the HL7 and DICOM standards. As the scope of the IHE initiative
expands, transactions based on other standards will be included as required.
In some cases, IHE recommends selection of specific options supported by these standards;
however, IHE does not introduce technical choices that contradict conformance to thesestandards. If errors in or extensions to existing standards are identified, IHE’s policy is to report______________________________________________________________________________
11
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
them to the appropriate standards bodies for resolution within their conformance and standards
evolution strategy.

415

420

425

IHE is therefore an implementation framework, not a standard. Referencing IHE as a standard isinappropriate. Conformance claims by product must still be made in direct reference to specificstandards. In addition, vendors who have implemented IHE integration capabilities shall use an
IHE Integration Statement to describe the conformance of their product to the specifications in
the IHE Technical Framework. The purpose of an IHE Integration Statement is to communicate
to the users of the corresponding product the IHE capabilities it has been designed to support.
Vendors publishing IHE Integration Statements accept full responsibility for their content. By
comparing the IHE Integration Statements from different implementations, a user familiar with
the IHE concepts of actors and integration profiles should be able to determine whether and towhat extent communications might be supported between products. See Appendix D for theformat of such IHE Integration Statements. IHE encourages implementers to ensure that products
implemented in accordance with the IHE Technical Framework also meet the full requirementsof the standards underlying IHE, allowing the products to interact, although possibly at a lower
level of integration, with products that have been implemented in conformance with thosestandards, but not in full accordance with the IHE Technical Framework.

1.5 Relationship to Real-world Architectures
430

435

440

445

The IHE Actors and transactions described in the IHE Technical Framework are abstractions of
the real-world healthcare information system environment. While some of the transactions are
traditionally performed by specific product categories (e.g., HIS, Electronic Patient Record, RIS,
PACS, Clinical Information Systems or imaging modalities), the IHE Technical Framework
intentionally avoids associating functions or actors with such product categories. For each actor,
the IHE Technical Framework defines only those functions associated with integrating
information systems. The IHE definition of an actor should therefore not be taken as thecomplete definition of any product that might implement it, nor should the framework itself betaken to comprehensively describe the architecture of a healthcare information system.
The reason for defining actors and transactions is to provide a basis for defining the interactions
among functional components of the healthcare information system environment. In situations
where a single physical product implements multiple functions, only the interfaces between the
product and external functions in the environment are considered to be significant by the IHE
initiative. Therefore, the IHE initiative takes no position as to the relative merits of an integrated
environment based on a single, all-encompassing information system versus one based on
multiple systems that together achieve the same end. To illustrate most dramatically thepossibilities of the IHE Technical Framework, however, the IHE demonstrations emphasize theintegration of multiple vendors’ systems based on the IHE Technical Framework.

1.6 Conventions

450

This document has adopted the following conventions for representing the framework concepts
and specifying how the standards upon which the IHE Technical Framework is based should beapplied.
______________________________________________________________________________
12
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1.6.1 Actor and Transaction Diagrams and Tables

455

Each integration profile is a representation of a real-world capability that is supported by a set ofactors that interact through transactions. Actors are information systems or components of
information systems that produce, manage, or act on categories of information required byoperational activities in the enterprise. Transactions are interactions between actors that transfer
the required information through standards-based messages.

460

The tables of actors and transactions given in sections 3 - 20 indicate which transactions eachactor in a given profile must support. The convention used in these diagrams is that the arrow
indicating the direction for the transaction points from the initiator of the transaction to thedestination.

465

In some cases, a profile is dependent on a pre-requisite profile in order to function properly andbe useful. For example, Presentation of Grouped Procedures depends on both Scheduled
Workflow and Consistent Presentation of Images being implemented as pre-requisites. These
dependencies can be found by locating the desired profile in Table 2-1 and seeing which profiles
are listed as required pre-requisites.
An actor must implement all required transactions in the pre-requisite profiles in addition to
those in the desired profile. In some cases, the pre-requisite is that the actor selects any one of agiven set of profiles to satisfy the pre-requisite. For example, Post-processing depends on any
one of the content profiles being supported.

470

1.6.2 Process Flow Diagrams
The descriptions of integration profiles that follow include Process Flow Diagrams that illustrate
how the profile functions as a sequence of transactions between relevant actors.

475

These diagrams are intended to provide a “big picture” so the transactions can be seen in thecontext of the overall workflow. Certain transactions and activities not defined in detail by IHE
are shown in these diagrams in italics to provide additional context on where the relevant IHE
transactions fit into the broader scheme of healthcare information systems.
These diagrams are not intended to present the only possible scenario. Often other actor
groupings are possible, and complementary transactions from other profiles may be interspersed.

480

In some cases the sequence of transactions may be flexible. Where this is the case there will
generally be a note pointing out the possibility of variations.
The convention used in these diagrams is that the arrow on the line for the transaction points
from the initiator of the transaction to the destination.
1.6.3 Normative versus informative contents of the Technical Framework

485

Most parts of the Technical Framework describe required or optional characteristics ofintegration profiles, Actors and Transactions: these are normative. For a better understanding of
the text, there also exist illustrating parts in the Technical Framework that are informative andnon-normative.
______________________________________________________________________________
13
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

490

According to IETF RFC 2119, certain words indicate whether a specific content of the Technical
Framework is normative: either required (e.g., “must”, “required”, “shall”) or optional (e.g.,“may”, “recommended”). Informative content does not contain these key words.
1.6.4 Technical Framework Referencing
When references are made to a section within the same Technical Framework volume, a section
number is used by itself. When references are made to other volumes or to a Technical
Framework in another domain, the following format is used:495<domain designator> TF-<volume number>: <section number>, where<domain designator> is a short designator for the IHE domain (ITI = IT Infrastructure, RAD =Radiology)<volume number> is the applicable volume within the given Technical Framework (e.g., 1, 2, 3),
and

500

<section number> is the applicable section number.
For example: ITI TF-1: 3.1 refers to section 3.1 in volume 1 of the IHE IT Infrastructure
Technical Framework, RAD TF-3: 4.33 refers to section 4.33 in volume 3 of the IHE Radiology
Technical Framework.

505

When references are made to specific transactions (transaction numbers) the following format isused:<domain designator>-<transaction number>
For example RAD-4 refers to transaction number 4 (Procedure Scheduled) in the Radiology
Technical Framework.

1.7 Scope Additions for 2013 – 2014 (Year 14)
510

This document refers to Year 13 of the IHE initiative in the Radiology Domain. It will be thebasis for the testing and exhibition process associated with the RSNA 2014 and HIMSS 2015
annual meetings.
•

515

Added the Imaging Object Change Management Profile which defines synchronization
mechanisms for imaging objects between a Change Requester and an ImageManager/Image Archive and the subsequent access behavior of the rejected instances.

1.8 Comments
HIMSS and RSNA welcome comments on this document and the IHE initiative. They should besubmitted at http://www.ihe.net/Radiology_Public_Comments or to:520

Chris Carr/Joan McMillen
IHE Radiology Secretary
820 Jorie Boulevard
Oak Brook, IL 60523______________________________________________________________________________
14
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Email: radiology@ihe.net

1.9 Copyright Permission
525

Health Level Seven, Inc. has granted permission to the IHE to reproduce tables from the HL7
standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All rights
reserved.
The National Electrical Manufacturers Association (NEMA) has granted permission to the IHE
to incorporate portions of the DICOM standard.

530

Material drawn from these documents is credited where used.

1.10 IHE Radiology Technical Framework Development andMaintenance Process

535

The Technical Framework is being continuously extended and maintained by the IHE TechnicalCommittee. The Development and Maintenance Process of the Framework follows a number ofprinciples to ensure stability of the specification both vendors and users may rely upon in
specifying, developing and acquiring IHE compatible products.
The process is intended to address the need for extensions, clarifications and corrections while
maintaining backward compatibility of framework definitions as to support implementations
claiming conformance to any previously defined integration profile and its actors.

540

To maintain stability of the IHE Technical Framework, modifications occur in a regular annual
cycle (Figure 1.10-1) according to one of two controlled paths:
1. New Development – Extending the Existing Technical Framework

545

550

Each year, new functionality to be developed is identified by the IHE Planning
Committee. The Technical Committee performs the necessary analysis and design workand generates new text for the Technical Framework.
Generally, new functionality is published in the form of a supplement. The scope of a
supplement is to make one of the following additions to the Technical Framework:•

A new Integration Profile, usually including the introduction of new actors andtransactions.

•

New actors in an existing Integration Profile: These may be either actors previously
defined elsewhere in the Technical Framework, or new ones not yet defined.
Transactions identifying the new actors responsibilities in this profile are identified ordefined and may be designated as required or optional. To avoid causing
compatibility problems for systems that have already implemented that profile, no
new required transactions are added for existing actors in the profile.

•

New options in an existing Integration Profile: These usually add optionaltransactions for existing actors in the profiles, or add optional features within existingtransactions.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
•
560

565

570

575

Major conceptual changes: They do not change the behavior of existing Integration
Profiles but may imply changes or additions to actors or transactions in the future.

The publication process consists of certain phases and is clearly indicated on eachdocument.
First, the text is published for Public Comment (with a “PC” designation). During the
Public Comment period (typically 30 days), the text and a comment submission facility
are available on the IHE Website. Following this period, the Technical Committee will
review the comments.
Updated text of supplements is then published for Trial Implementation (with a “TI”
designation), based on the modifications resulting from the comments received.
After trial implementations have been judged to have sufficiently exercised the newfunctionality (e.g., due to experience from the Connectathon), and the text is consideredsufficiently stable, the new text will be published as Final Text (with a “FT” designation).
Final Text Supplements will be merged at the end of the annual development cycle withthe current version of the Technical Framework resulting in a new version of theTechnical Framework with an increased version number.
2. Maintenance of existing Technical Framework content
Despite the best efforts of the Technical Committee, a published current version of theTechnical Framework or Trial Implementation documents may contain text that isincorrect, incomplete or unclear. Such issues are handled as Change Proposals and cover:•Corrections: technical issues causing non-interoperability of implementations are
fixed without introducing changes in functionality of a stable Integration Profile.

•

Clarifications: text that can be misunderstood or is ambiguous is made easier tounderstand or disambiguated, without introducing any technical changes.

580

585

590

The publication process is the same for both Corrections and Clarifications, andaddresses both changes to Trial Implementations and changes to a current version of theTechnical Framework.
A Submitted Change Proposal results from issues raised by users, vendors or TechnicalCommittee members, e.g., from experiences with Trial Implementation or Final Text
Integration Profiles or at a Connectathon. The resulting Change Proposal document
should explicitly state:
1. the parts of the Technical Framework requested to be changed,
2. a problem description,
3. a rationale why the change is considered necessary,
4. and a solution or approach to the problem.

595

The Technical Committee regularly considers Change Proposals which are then either
accepted or rejected.
A Rejected Change Proposal is published with a rationale from the TechnicalCommittee explaining why the change is not appropriate.
______________________________________________________________________________
16
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________An Accepted Change Proposal is assigned to a member of the Technical Committee asa work item for further investigation with the goal to produce adequate clarifications orcorrections. The resulting text will again be reviewed by the Technical Committee before
being approved.
Once approved, a Final Text Change Proposal is published by the TechnicalCommittee, and then is to be considered as effective. It will be merged into the next
version of the Technical Framework at the end of the annual development cycle.
Submitting a Change Proposal to a Final Text Change Proposal or a Final Text
Supplement is not possible.

600

605

610

The current version of the Technical Framework is considered the primary reference document.
Final Text Supplements and Final Text Change Proposals from the current annual cycle
complement this document. Past Final Text documents are retained to provide convenientsummaries of differences to prior versions of the Technical Framework or Trial Implementation
versions of Supplements.
During the annual development and maintenance cycle, it is recommended to use Technical
Framework documents for implementations as follows:•

Product Implementations
Products implemented based on Trial Implementation text are expected to review thesubsequent Final Text and update their products as necessary. Further, it is expected thatvendors will monitor Final Text Change Proposals and make any corrections relevant totheir product in a timely fashion.

•

Connectathon Implementations
Testing at the Connectathon will be based on the current version of the Technical
Framework for the appropriate IHE Domain, plus any relevant Supplements for Trial
Implementation and Final Text Change Proposals.

615

620

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

625
Figure 1.10-1: The figure shows the process of developing and maintaining the Technical
Framework during an annual cycle. Dashed arrows indicate the assembly (merging) oftext.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2 Integration Profiles
630

IHE Integration Profiles, depicted in Figure 2-1, offer a common language that healthcare
professionals and vendors may use in communicating requirements for the integration of
products. Integration Profiles describe real-world scenarios or specific sets of capabilities ofintegrated systems. An Integration Profile applies to a specified set of actors and for each actor
specifies the transactions necessary to support those capabilities.

635

Integration Profiles provide a convenient way for both users and vendors to reference a subset ofthe functionality detailed in the IHE Technical Framework. They enable users and vendors to be
more specific than simply requesting or promising overall IHE support, without laborious
restatement of the details regarding IHE actors and transactions defined by the IHE Technical
Framework.

640

The Profiles can be considered in three classes: Content Profiles which address the managementof a particular type of content object; Workflow Profiles which address the management of theworkflow process by which content is created; and Infrastructure Profiles which address
departmental issues. Figure 2-1 shows the current set of IHE Integration Profiles organizedaround these classes.

645

The Content Profiles describe the creation, storage, management, retrieval and general use of aparticular type of content object. Current Content Profiles include: Consistent Presentation of
Images, Key Image Notes, NM Image, Mammography Image, Evidence Documents, and Simple
Image and Numeric Reports. Additionally, the handling of image content is described inside theScheduled Workflow Profile. Content Profiles are “workflow neutral”. The profile addresses
how the object is created, stored, queried and retrieved, but does not address the workflow
management process.

650

655

660

The Workflow Profiles address managing workflow process, which typically involves providing
worklists, and reporting/monitoring the progress and completion of workitems. Within thiscontext, one or more content objects are generally created according to their content profile.
Current Workflow Profiles include: Scheduled Workflow (for acquisition), Post-Processing
Workflow, Reporting Workflow, Cross-enterprise Document Sharing for Imaging and Import
Reconciliation Workflow. Presentation of Grouped Procedures is an extension of Scheduled
Workflow. Charge Posting is an extension of all the Workflow Profiles.
The Infrastructure Profiles address general departmental issues like Radiology Audit Trail
Option and Access to Radiology Information.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Scheduled Workflow

Charge Posting

Admit, order, schedule,

manageworklists,track status,
perform &notifyacquisition
related steps,

create,store,
manage,retrieve &useimagesCollect and post timely
billable procedure details

Patient
Information
Reconciliation

ImportReconciliation
Workflow

Presentation ofGroupedProcedures

PostProcessing
Workflow

ReportingWorkflow

Reconcileworklists, status,and data objects forunknown patientsand demographics
changes

Reconcile imported
data objects

Manage individual
procedure image
subsets from amulti-procedureacquisition forviewing & reporting

Manageworklists, track
status, perform& notify image
processing &CAD steps

Manageworklists, track
status, perform& notify
diagnostic
reporting steps

Evidence
Documents

Key Image
Notes

Create, store,
manage,retrieve & use
objects torecord study
evidence

Simple Image
and Numeric
Reports

Create, store,
manage, retrieve& use objects toflag significant
imagesCreate, store,
manage, retrieve& use simple
diagnostic
reports with
optional image

Mammo
Image

NM Image

Create, store,
manage,retrieve & use
Mammo image
objects

Create, store,
manage,retrieve & use
NM imageobjects

Teaching File
& Clinical
Trial Export

Radiation
Exposure
Monitoring

Identify,
anonymize &store objects
for teachingfiles or clinical
trialsCreate, store,
manage, retrieve& use radiationdose SR object

Consistent
Presentationof Images
Create, store,
manage, retrieve &use objects forhardcopy andsoftcopy grayscale
presentation states

Access to Radiology Information
Consistent access to images and reports

Portable Data for Imaging
Consistent access to images and reports on CD Media

Cross-Enterprise Document Sharing for Imaging

Cross-Community Access for Imaging

Consistent sharing of images and radiology reports acrossenterprise boundaries

Consistent query and retrieve mechanism for
imaging information across communities

Other Radiology Relevant Profiles:
ITI ATNA – Radiology Audit Trail Opton, ITI RID, ITI PIX

Figure 2-1: IHE Integration Profiles______________________________________________________________________________
20
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
665

Dependencies among Integration Profiles
In general, IHE Integration Profiles do not operate independently. Objects that serve as useful
input to one profile may have been produced as a result of implementing another profile.
Figure 2-1 (above) provides a graphical view of the dependencies between integration profiles.
Table 2-1 defines the required dependencies between the integration profiles in a tabular form.

670

675

680

In some cases a profile is strictly dependent on one or more profiles in order to function. For
example, Presentation of Grouped Procedures depends directly on the features of Scheduled
Workflow and Consistent Presentation of Images in order to function.
In other cases a profile is dependent on one of a class of profiles in order to be useful. For
example, Charge Posting depends on at least one of the workflow profiles (Scheduled Workflow,
Post-Processing Workflow and/or Reporting Workflow) being present in order for it to havesomething useful to post. Similarly, each workflow profile is of little value unless at least one
relevant content profile is also implemented. Of course the more content profiles are supported,the more forms of input and output can be managed by the workflow.
There are of course other useful synergies that occur when different combinations of profiles are
implemented, but those are not described in the table below.
Table 2-1: Integration Profiles Dependencies
Integration Profile

Depends on

Dependency TypeConsistent Presentation of
Images

None

None

-

Key Image Notes

None

None

-

NM Image

None

None

Mammography Image

None

None

Evidence Documents

None

None

-

Simple Image andNumeric Report

None

None

-

Access to Radiology
Information

One or more of :{Scheduled Workflow
Consistent Presentation of Images,
Evidence Documents,
Key Image Notes,
Simple Image and Numeric Reports}
Patient Information Reconciliation

Required for Content
outputComments

Supporting the image
related transactions of
Scheduled Workflow
counts as a content
profileConditionally Required
for the Multi Source
OptionScheduled Workflow

None

None

-

Presentation of Grouped
Procedures

Scheduled Workflow

Required for workflow-

Consistent Presentation of Images

Required for Content
output-Post-Processing Workflow

Scheduled Workflow

Required for workflow
management-______________________________________________________________________________
21
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Integration Profile

Depends on

Comments

Required for Content
input

Supporting the image
related transactions of
Scheduled Workflow
counts as a content
profileOne or more of :{Scheduled Workflow
Consistent Presentation of Images,
Evidence Documents,
Key Image Notes}

Required if any output isproduced

Supporting the image
related transactions of
Scheduled Workflow
counts as a content
profileScheduled Workflow

Required for workflow
management-

One or more of :{Scheduled Workflow,
Evidence Documents, NM Image}

Required for Content
input

Supporting the image
related transactions of
Scheduled Workflow
counts as a content
profile.

Simple Image and Numeric Reports

Required for Content
input/output-

One or More of :{Scheduled Workflow,
Post-Processing Workflow,
Reporting Workflow, Import
Reconciliation Workflow}

Required for charge
trigger input-

Scheduled Workflow

Required forworkflow/content tomanagePatient Information
Reconciliation is anextension to thisprofile requiring thatthe workitems and/or
content be updated.

Reporting Workflow

Charge Posting

Dependency TypeOne or more of :{Scheduled Workflow,
Evidence Documents, NM Image}

Patient Information
Reconciliation

Portable Data for Imaging

None

None

XDS for Imaging (XDSI.b)

XDS.b (ITI)

Document Consumer,
Document Registry, andDocument Repository
actors from ITI XDS.b
are needed to support thetransactions andworkflows defined by
XDS-I.b.

Document content
types and metadata
are specialized.

ATNA, incl. Radiology Audit Trail
OptionEach XDS-I.b Actor shallbe grouped with the
Secure Node or Secure
Application Actor.

Required to manage
audit trail of exported
PHI, node
authentication andtransport encryption.

Scheduled Workflow

Required for Workflow(including Scheduled
Import Option)

Support the workflow
related transactions of
Scheduled Workflow.

Import Reconciliation
Workflow-______________________________________________________________________________
22
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Integration Profile

Depends on

Dependency Type

Comments

Patient Demographics Query [ITI]

Required for
Unscheduled Import
OptionPatient Demographic
information is
obtained using
Patient Demographic
Query.

Teaching File and Clinical
Trial Export

None

None

-

Radiation Exposure
Monitoring

None

None

-

XDS.b (ITI)

Required for access of
documents

XCA (ITI)

Required for crosscommunity access of
documents

Audit Trail and Node Authentication,incl. Radiology Audit Trail Option

Each XCA-I Actor shallbe grouped with Secure
Node Actor or Secure
Application

Required to manage
audit trail of exported
PHI, node
authentication andtransport encryption.

Consistent Time (ITI)

Each XCA-I Actor shallbe grouped with the Time
Client Actor.

To ensureconsistency among
document andsubmission set dates.

Scheduled Workflow

Required for workflow
management

Defines how ImageManager/Image
Archive can obtainscheduled worklist inorder to correct themodality worklist
selection of theacquired instances.
Supportcommunication ofprocedure steps andstorage commitment
when Change
Requester is groupedwith Acquisition
Modality, ImageManager/Image
Archive or Evidence
Creator.
Support ImageManager to ImageManager change
management if
Multiple Patient
Identity Resolution
Option is supported.

Cross-Community Accessfor Imaging (XCA-I)

Imaging Object ChangeManagement______________________________________________________________________________
23
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Integration Profile

685

690

Depends on

Dependency Type

Comments

Patient Information Reconciliation

Required forreconciliation workflow

Support the patient
information
reconciliation
mechanisms for theactor that is groupedwith the Change
Requester.

Vendor products support an Integration Profile by implementing the appropriate actortransactions as outlined in the Integration Profile in sections 3-20. A product may implement
more than one actor and more than one Integration Profile.
An actor must implement all required transactions in the pre-requisite profiles in addition to
those in the desired profile. In some cases, the pre-requisite is that the actor selects any one of agiven set of profiles to satisfy the pre-requisite. For example, Post-processing depends on any
one of the content profiles being supported.
Actors (see section 2.3) are information systems or components of information systems that
produce, manage, or act on information associated with operational activities in the enterprise.
Transactions (see section 2.4) are interactions between actors that transfer the required
information through standards-based messages.

695

2.1 Integration Profiles Overview
In this document, each IHE Integration Profile is defined by:

700

705

710

•

The IHE Actors involved•

The specific set of IHE Transactions required for each IHE Actor.

These requirements are presented in the form of a table of transactions required for each actor
supporting the Integration Profile. Actors supporting multiple Integration Profiles are required tosupport all the required transactions of each Integration Profile supported. When an Integration
Profile depends upon another Integration Profile, all transactions required for the dependent
Integration Profile have been included in the table.
As mentioned earlier, there is a class of Profiles that deal primarily with data content. Most typesof content belong to the family of Evidence Objects. Currently this means Images, Presentation
States, Key Image Notes and Evidence Documents. Evidence Objects are generated as a result of
performing procedure steps on systems in the radiology department. These objects are used by
the Radiologist in the process of creating a Radiological Diagnostic Report and are managed
inside the Radiology Department. Evidence Documents represent the uninterpreted informationthat is primarily managed and used inside Radiology, although distribution outside Radiology is
not precluded. In contrast, the diagnostic reports described in the Simple Image and Numeric
Reports Profile represent the interpreted information which is the primary output of theRadiology department and are available for wide distribution.
______________________________________________________________________________
24
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

715

720

Note that IHE Integration Profiles are not statements of conformance to standards, and IHE is nota certifying body. Users should continue to request that vendors provide statements of theirconformance to relevant standards, such as DICOM and HL7. Standards conformance is aprerequisite for vendors adopting IHE Integration Profiles.
Also note that there are critical needs for any successful integration project that IHE cannot
address. Successfully integrating systems still requires a project plan that minimizes disruptions
and describes fail-safe strategies, specific and mutually understood performance expectations,well-defined user interface requirements, clearly identified systems limitations, detailed cost
objectives, plans for maintenance and support, etc.
2.1.1 Scheduled Workflow (SWF)

725

730

The Scheduled Workflow Integration Profile establishes the continuity and integrity of basic
departmental imaging data acquired in an environment where examinations are generally beingordered. It specifies a number of transactions that maintain the consistency of patient andordering information as well as defining the scheduling and imaging acquisition procedure steps.
This profile also makes it possible to determine whether images and other evidence objects
associated with a particular performed procedure step have been stored (archived) and areavailable to enable subsequent workflow steps, such as reporting. It may also provide central
coordination of the completion of processing and reporting steps as well as notification of
appointments to the Order Placer.
2.1.2 Patient Information Reconciliation (PIR)

735

740

The Patient Information Reconciliation Integration Profile extends the Scheduled Workflow
Integration Profile by offering the means to match images, diagnostic reports, and otherevidence objects acquired for a misidentified or unidentified patient (for example, during a
trauma case) with the patient’s record. In the example of the trauma case, this integration profile
allows subsequent reconciliation of the patient record with images that are acquired (either
without a prior registration or under a generic registration) before the patient’s identity could bedetermined. Thus images, diagnostic reports and other evidence objects can be acquired andinterpreted immediately and later, when the patient’s official registration and order informationis entered into the ADT, Order Placer and Order Filler Systems, this information is matched withthe acquired image set, greatly simplifying these exception-handling situations.
2.1.3 Consistent Presentation of Images (CPI)

745

750

The Consistent Presentation of Images Integration Profile specifies a number of transactions thatmaintain the consistency of presentation for grayscale images and their presentation state
information (including user annotations, shutters, flip/rotate, display area, and zoom). It also
defines a standard contrast curve, the Grayscale Standard Display Function, against which
different types of display and hardcopy output devices can be calibrated. It thus supports
hardcopy, softcopy and mixed environments.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2.1.4 Presentation of Grouped Procedures (PGP)

755

760

The Presentation of Grouped Procedures Integration Profile (PGP) addresses what is sometimes
referred to as the linked studies problem: viewing image subsets resulting from a single
acquisition with each image subset related to a different requested procedure (e.g., CT chest,
abdomen and pelvis). It provides a mechanism for facilitating workflow when viewing images
and reporting on individual requested procedures that an operator has grouped (often for the sakeof acquisition efficiency and patient comfort). A single acquired image set is produced, but the
combined use of the scheduled workflow transactions and the consistent presentation of images
allow separate viewing and interpretation of the image subsets related to each of the requested
procedures.
2.1.5 Access to Radiology Information (ARI)765

The Access to Radiology Information Integration Profile specifies a number of querytransactions providing access to radiology information, including images and related reports, in a
DICOM format as they were acquired or created. Such access is useful both to the radiology
department and to other departments such as pathology, surgery and oncology.
2.1.6 Key Image Note (KIN)

770

The Key Image Note Integration Profile specifies transactions that allow a user to mark one ormore images in a study as significant by attaching to them a note managed together with thestudy. This note includes a title stating the purpose of marking the images and a user comment
field. Physicians may attach Key Image Notes to images for a variety of purposes: referring
physician access, teaching files selection, consultation with other departments, and image quality
issues, etc.
2.1.7 Simple Image and Numeric Report (SINR)

775

The Simple Image and Numeric Report Integration Profile facilitates the growing use of digital
dictation, voice recognition, and specialized reporting packages, by separating the functions ofreporting into discrete actors for creation, management, storage and viewing. Separating thesefunctions while defining transactions to exchange the reports between them enables a vendor to
include one or more of these functions in an actual system.
2.1.8 Basic Security (SEC) - DEPRECATED

780

This profile has been superseded by the ITI Audit Trail and Node Authentication (ATNA)
Integration Profile and the Radiology Audit Trail Option on ATNA. See sections 2.2.1 and 10 for
details on backward compatibility of this option and the Basic Security Profile.
2.1.9 Charge Posting (CHG)785

The Charge Posting Integration Profile specifies the exchange of information from the
Department System Scheduler/Order Filler Actor to the Charge Processor Actor regarding
charges associated with particular procedures, as well as communication between the
ADT/Patient Registration and Charge Processor Actors about patient demographics, accounts,______________________________________________________________________________
26
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

790

795

800

805

insurance, and guarantors. The Charge Posted Transaction contains all of the required procedure
data to generate a claim. Currently, these interfaces contain fixed field formatted or HL7-styledata. The goal of including this transaction in the IHE Technical Framework is to standardize theCharge Posted Transaction to a Charge Processor, thus reducing system interface installation
time between clinical systems and Charge Processors. Additionally, the Charge Posted
Transaction reduces the need of the billing system to have knowledge of the radiology internals.
The result is that the Charge Processor will receive more complete, timely and accurate data.
2.1.10 Post-Processing Workflow (PWF)
The Post-Processing Workflow Integration Profile addresses the need to schedule, distribute andtrack the status of typical post-processing workflow steps, such as Computer-Aided Detection or
Image Processing. Worklists for each of these tasks are generated and can be queried, workitems
can be selected and the resulting status returned from the system performing the work to thesystem managing the work. IMPORTANT NOTE: As of June 2012, IHE introduces a new
Trial Implementation Profile: Post-Acquisition Workflow (PAWF). The use cases addressed
are largely the same as PWF, but the underlying mechanisms are improved. The PWF Profile
documented in this section has been deprecated by the Radiology Domain and is now replaced
by PAWF. When the PAWF Profile becomes Final Text, the contents of Section 10 will be
removed. In the interim, new implementations should be based on PAWF, found at
http://www.ihe.net/Technical_Framework/index.cfm#radiology.
2.1.11 Reporting Workflow (RWF)810

The Reporting Workflow Profile addresses the need to schedule, distribute and track the status of
the reporting workflow tasks such as interpretation, transcription and verification. Worklists foreach of these tasks are generated and can be queried; workitems can be selected and the resulting
status returned from the system performing the work to the system managing the work.
2.1.12 Evidence Documents (ED)

815

820

The Evidence Documents Profile defines interoperable ways for observations, measurements,
results and other procedure details recorded in the course of carrying out a procedure step to be
output by devices, such as acquisition systems and other workstations; to be stored and managed
by archival systems; and to be retrieved and presented by display and reporting systems. This
allows detailed non-image information, such as measurements, CAD results, procedure logs, etc.
to be made available as input to the process of generating a diagnostic report. The Evidence
Documents may be used either as additional evidence for the reporting physician or in somecases for selected items in the Evidence Document to be included in the diagnostic report.
2.1.13 Portable Data for Imaging (PDI)825

The Portable Data for Imaging Integration Profile specifies actors and transactions that allow
users to distribute imaging related information on interchange media. The intent of this profile isto provide reliable interchange of evidence objects and diagnostic reports for import, display or
print by a receiving actor. A single physical transport means is specified that supports the______________________________________________________________________________
27
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
multiple usage scenarios described in this profile. The CD format was chosen for supporting thedescribed use cases.
2.1.14 NM Image (NM)830

The NM Image Integration Profile specifies how Acquisition Modalities and workstations should
store NM Images and how Image Displays should retrieve and make use of them. It defines thebasic display capabilities Image Displays are expected to provide, and also how result screens,both static and dynamic, such as those created by NM Cardiac Processing Packages, should be
stored using DICOM objects that can be displayed on general purpose Image Display systems.
2.1.15 Teaching File and Clinical Trial Export (TCE)

835

840

The Teaching File and Clinical Trial Export Profile addresses the need to select DICOM
instances, series or studies (which may contain images, key image notes, reports, evidence
documents and presentation states) that need to be exported for teaching files or clinical trials.
It defines an actor for making the Export Selection, which would typically be grouped with an
Image Display or Acquisition Modality, and an actor for processing the selection, which is
required to support a configurable means of de-identifying the exported instances. Additional
options are provided for de-identification of pixel data, remapping of identifiers topseudonymous values, export of additional teaching file information, and delaying export for avariety of reasons.
2.1.16 Cross-Enterprise Document Sharing for Imaging (XDS-I.b)

845

850

855

IMPORTANT NOTE: The XDS-I Profile has been superseded by the Cross-Enterprise
Document Sharing for Imaging (XDS-I.b) Integration Profile. See sections 18 for details on
the replacement Profile.
The Cross-Enterprise Document Sharing for Imaging (XDS-I.b) Integration Profile specifies
actors and transactions that allow users to share imaging information across enterprises. This
profile depends on the IHE IT Infrastructure Cross-Enterprise Document Sharing (XDS.b)
Profile. Cross-Enterprise Document Sharing for Imaging (XDS-I.b) defines the information to beshared such as sets of DICOM instances (including images, evidence documents, andpresentation states), diagnostic imaging reports provided in a ready-for-display format.
Since the XDS-I.b Profile depends on and extends the IT Infrastructure XDS.b Profile including
the use of terms defined in XDS (e.g., XDS Affinity Domain, submission set, etc.) the reader of
XDS-I.b is expected to have read and understood the XDS Profile.
2.1.17 Mammography Image (MAMMO)

860

The Mammography Image Profile specifies how DICOM Mammography images and evidence
objects are created, exchanged and used. It describes how Acquisition Modalities transfer Full
Field Digital Mammography (FFDM) Images, how CAD systems act as Evidence Creators, and
how Image Displays should retrieve and make use of images and CAD results. It defines the______________________________________________________________________________
28
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
basic display capabilities Image Displays are expected to provide, and which attributes should be
used to implement those capabilities.
2.1.18 Image Fusion (FUS)865This section intentionally, temporarily left blank.
2.1.19 Import Reconciliation Workflow (IRWF)

870

875

The Import Reconciliation Workflow Integration Profile (IRWF) specifies how data Importers
obtain local demographics, coerce patient and procedure attribute values in the imported data andreport progress/status of the importation process. The Profile complements the Scheduled
Workflow Profile by using the existing workflow mechanisms for notification and storage ofimported Evidence Objects. IMPORTANT NOTE: As of June 2012, IHE introduces an
updated Import Reconciliation Profile (IRWF.b) for Trial Implementation. In addition to theoriginal use cases, several new use cases are addressed, and the underlying mechanisms are
improved. The IRWF Profile documented in this section has been deprecated by the Radiology
Domain and is now replaced by the IRWF.b. When that supplement becomes Final Text, thecontents of Section 21 will be removed. In the interim, new implementations should be basedon IRWF.b, found at http://www.ihe.net/Technical_Frameworks/#radiology.
2.1.20 Radiation Exposure Monitoring (REM)

880

885

The Radiation Exposure Monitoring Integration Profile specifies communications between
systems generating reports of irradiation events (generally acquisition modalities andworkstations) and systems which receive, store, or process those reports (generally local dose
information management systems and/or national/regional dose registries). It defines how
DICOM SR objects for CT and projection X-ray dose objects are created, stored, queried,
retrieved, de-identified, and may be processed and displayed.
2.1.21 Mammography Acquisition Workflow (MAWF)
This section intentionally, temporarily left blank.
2.1.22 MR Diffusion Imaging (DIFF)
This section intentionally, temporarily left blank.
2.1.23 CT/MR Perfusion Imaging with Contrast (PERF)

890

This section intentionally, temporarily left blank.
2.1.24 Basic Image Review (BIR)
This section intentionally, temporarily left blank.
2.1.25 Chest X-Ray CAD Display (CXCAD)This section intentionally, temporarily left blank.
______________________________________________________________________________
29
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
895

900

2.1.26 Imaging Object Change Management (IOCM)
The Imaging Object Change Management Integration Profile (IOCM) specifies how one actor
communicates local changes applied on existing imaging objects to other actors that manage
copies of the modified imaging objects in their own local systems. The supported changes
include (1) object rejection due to quality or patient safety reasons, (2) correction of incorrect
modality worklist entry selection, and (3) expiration of objects due to data retention
requirements. It defines how changes are captured and how to communicate these changes.
2.1.27 Cross-Community Access for Imaging (XCA-I)

905

The Cross-Community Access for Imaging (XCA-I) Integration Profile specifies actors andtransactions to query and retrieve patient-relevant medical imaging data being held by othercommunities.
Within a community, a group of facilities/enterprises shares clinical information via anestablished mechanism such as XDS-I (in which case the community can be referred to as an
XDS Affinity Domain). This profile addresses sharing between such communities.

910

The XCA-I Profile extends the IT Infrastructure XCA Profile. XCA provides access toDiagnostic reports and Imaging Manifests. XCA-I provides access to the imaging objects
referenced in the Manifests. The reader of XCA-I is expected to have read and understood the
XCA Profile, including the meaning of terms such as Community, homeCommunityId, etc.

2.2 Options to other Domains’ Profiles
915

2.2.1 ITI-Audit Trail and Node Authentication
The Radiology Audit Trail Option is an option on the ITI Audit Trail and Node Authentication(ITI-ATNA) Profile. The ITI-ATNA Profile provides security and privacy mechanisms like acommon audit trail and authentication for distributed applications. Refer to the ITI-ATNA
Profile (ITI TF-1: 9) for the full definition of this profile.

920

The Radiology Audit Trail Option deals largely with the details of the Record Audit Eventtransaction in the IHE ITI Technical Framework. It defines audit events on IHE Radiology
transactions for a Secure Node. This option does not extend the Authenticate Node transaction in
the ATNA Profile.

2.3 Actor Descriptions
925

930

Actors are information systems or components of information systems that produce, manage, or
act on information associated with operational activities in the enterprise. The following are theactors defined by IHE and referenced throughout the rest of this document.
It is acknowledged that some of the terms used as modifiers for the actor names are not usedconsistently (e.g., Evidence Creator, Image Display). At this point, the benefit in doing extensive
renaming to gain consistency is outweighed by the risk of introducing significant confusion that______________________________________________________________________________
30
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

935

940

945

950

955

960

965

970

would result from renaming many of the existing actors. Therefore the actor names will remain
as defined below.
Acquisition Modality – A system that acquires and creates medical images while a patient ispresent, e.g., a Computed Tomography scanner or Nuclear Medicine camera. A modality may
also create other evidence objects such as Grayscale Softcopy Presentation States for theconsistent viewing of images or Evidence Documents containing measurements. A modality may
also create and store Dose SRs.
ADT Patient Registration – A system responsible for adding and/or updating patient
demographic and encounter information. In particular, it registers a new patient with the Order
Placer and Department System.
Charge Processor – Receives the posted charges and serves as a component of the financial
system. Further definition of this actor is beyond current IHE scope.
Change Requester – A system that communicates changes to an Image Manager / Archive,
indicating that certain imaging instances should be deleted. In addition, it may also send newversions of these imaging instances containing corrected information.
Department System Scheduler/Order Filler – A department-based information system (forinstance, Radiology or Laboratory) that provides functions related to the management of orders
received from external systems or through the department system’s user interface. Upon adefined workflow action, makes procedures available for charge posting. The action/event that
actually causes charges to post is defined by the actor.
Display – Primary description for this actor can be found in ITI TF-1: Appendix A. The required
capabilities for its use within the Radiology Technical Framework add the ability to view "webviewable" diagnostic and therapeutic imaging information on interchange media.
Document Consumer – The Document Consumer Actor queries a Document Registry Actor for
documents meeting certain criteria, and retrieves selected documents from one or more
Document Repository Actors.
Document Registry – The Document Registry Actor maintains meta-data about each registereddocument in a document entry. This includes a link to the Document Repository where the actual
document is stored. The Document Registry responds to queries from Document Consumer
Actors about documents meeting specific criteria. It also enforces some healthcare specifictechnical policies at the time of document registration.
Document Repository – The Document Repository Actor persistently stores documents. It
assigns and maintains a unique identifier for each document, to allow Document Consumers toretrieve them.
Dose Information Consumer – Responsible for supplemental handling of irradiation events,
generally on an individual basis (e.g., display, analysis, or further processing).
Dose Information Reporter – Responsible for the aggregation, analysis, reporting and businesslogic related to irradiation events, which may include meeting facility obligations to de-identify
and submit data to various dose registries.
Dose Registry – Collates information about irradiation events from a number of facilities,
generally to perform analysis.
______________________________________________________________________________
31
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

975

980

985

990

995

1000

1005

1010

Enterprise Report Repository – A system that receives Structured Report Export Transactions
from the Report Manager and stores them.
Evidence Creator – A system that creates additional evidence objects such as images,presentation states, Key Image Notes, and/or Evidence Documents and transmits them to an
Image Archive. It also makes requests for storage commitment to the Image Manager for the datapreviously transmitted. It may also retrieve worklist entries for post-processing steps from the
Post-Processing Manager and provide notification of completion of the step, allowing theenterprise to track the status of post-processing work.
Export Manager – A system that can de-identify and pseudonymize the attributes, andoptionally the pixel data, of a selected list of instances, before exporting them.
Export Selector – A system that allows a user to select one or more instances, series or studies
for export, for a specific purpose, with a specific disposition, optionally with the inclusion of
additional information.
External Report Repository Access – A system that performs retrieval of clinical reports
containing information generated outside the imaging department and presented as DICOM
Structured Reporting Objects.
Image Archive – A system that provides long term storage of evidence objects such as images,presentation states, Key Image Notes, Evidence Documents and Dose SR.
Image Display – A part of a system that can access imaging evidence objects (images,
Presentation States, Key Image Notes, Evidence Documents) through network query/retrieve or
reading interchange media and allow the user to view these objects.
Image Manager – A system that provides functions related to safe storage and management ofevidence objects. It supplies availability information for those objects to the Department System
Scheduler. It also accepts/commits dose data and supports query/retrieve.
Imaging Document Consumer – The Imaging Document Consumer Actor parses an imaging
manifest document that is retrieved by the Document Consumer Actor from the Document
Repository Actor, and retrieves DICOM SOP Instances referenced within that manifest from theImaging Document Source Actor.
Imaging Document Source – The Imaging Document Source Actor is the producer andpublisher of imaging documents. It is responsible for providing imaging documents and metadata to the Document Repository Actor, which subsequently registers the imaging documentswith the Document Registry Actor. It also supports the retrieval services for DICOM SOP
Instances referenced in a published imaging manifest document.
Importer – A system that imports evidence objects such as images, presentation states, Key
Image Notes or Evidence Documents from hardcopy or digital media.
Master Patient Index (MPI) – A system that maintains unique enterprise-wide identifiers forpatients. Note that this is not supported in the current scope of the IHE Technical Framework
Order Placer – A hospital or enterprise-wide system that generates orders for various
departments and distributes those orders to the correct department.
Patient Demographics Supplier – A repository of patient information that can be searched on
demographic related fields. This actor is defined in the ITI Technical Framework.
______________________________________________________________________________
32
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1015

1020

1025

1030

1035

1040

1045

1050

Performed Procedure Step Manager – A system that re-distributes the Modality Performed
Procedure Step information from the Acquisition Modality or Evidence Creator to the
Department System Scheduler/Order Filler, Image Manager and Report Manager.
Portable Media Creator – This actor assembles the content of the media and writes it to thephysical medium.
Portable Media Importer – This actor reads the DICOM information contained on the media,
and allows the user to select DICOM instances, reconcile key patient and study attributes, andstore these instances. The actor grouped with the Media Importer can then process the instances.
Post-Processing Manager – A system that provides functions related to post-processing
worklist management. This involves the ability to schedule post-processing worklist items(scheduled procedure steps), provide worklist items to post-processing worklist clients, andupdate the status of scheduled and performed procedure steps as received from post-processing
worklist clients.
Print Composer – A system that generates DICOM print requests to the Print Server. Print
requests include presentation state information in the form of Presentation Look-Up Tables(Presentation LUTs). It may also read the DICOM information contained on interchange media.
Print Server – A system that accepts and processes DICOM print requests as a DICOM Print
SCP and performs image rendering on hardcopy media. The system must support pixel rendering
according to the DICOM Grayscale Standard Display Function.
Receiver – A system that can receive exported instances over the network, whose behavior isotherwise unspecified unless grouped with other actors.
Report Creator – A system that generates and transmits draft (and optionally, final) diagnostic
reports, presenting them as DICOM Structured Reporting Objects. It may also retrieve worklist
entries for reporting steps from the Report Manager and provide notification of completion of thestep, allowing the enterprise to track the status of an awaited report.
Report Manager – A system that provides management and short-term storage of DICOM
Structured Report objects during the reporting process then distributes text or structured reports
to report repositories. It also manages the worklists and status of reporting.
Report Reader – A part of a system that can access reports through network query/retrieve or
reading interchange media and allow the user to view reports presented as DICOM Structured
Reporting Objects.
Report Repository – A system that provides long-term storage of diagnostic reports and theirretrieval as DICOM Structured Reporting Objects.
Initiating Imaging Gateway – The Initiating Imaging Gateway Actor proxies Imaging
Document Set Retrieve requests from an Image Document Consumer to a Responding Imaging
Gateway with a Cross Gateway Retrieve Imaging Document Set transaction.
Responding Imaging Gateway – The responding Imaging Gateway proxies Cross Gateway
Retrieve Imaging Document Set requests from an Initiating Imaging Gateway to an Imaging
Document Source with an Image Document Set Retrieve request.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2.4 Transaction Descriptions

1055

1060

1065

1070

1075

1080

1085

1090

Transactions are interactions between actors that transfer the required information throughstandards-based messages. The following are the transactions defined by IHE and referenced
throughout the rest of this document.
1. Patient Registration – The ADT system registers and/or admits a patient and forwards theinformation to other information systems.
2. Placer Order Management – The Order Placer informs the Order Filler of the initiation orcancellation of an order. The Placer/Filler Order Management transaction will sometimes bereferred to as “-New” when a new order is being initiated, or as “-Cancel” when an existingorder is canceled.
3. Filler Order Management – The Order Filler informs the Order Placer of the initiation,
cancellation, or change in the status of an order. The Placer/Filler Order Managementtransaction will sometimes be referred to as “-New” when a new order is being initiated, or
as “-Cancel” when an existing order is canceled.
4. Procedure Scheduled – Schedule information is sent from the Department System
Scheduler/Order Filler to the Image Manager and to the Report Manager.
5. Query Modality Worklist – In response to a query (with optional filtering) a list of
Scheduled Procedure Steps with selected demographic and order information is returned.
6. Modality Procedure Step In Progress – An Acquisition Modality notifies the Performed
Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs
the Department System, Image Manager and the Report Manager.
7. Modality Procedure Step Completed – An Acquisition Modality notifies the Performed
Procedure Step Manager of the completion of a Procedure Step and the PPS Manager
informs the Department System, Image Manager and the Report Manager.
8. Modality Images Stored – An Acquisition Modality sends acquired or generated images tothe Image Archive.
9. Modality Presentation State Stored – An Acquisition Modality requests that the Image
Archive store a Grayscale Softcopy Presentation State (GSPS) for the acquired or generated
images.
10. Storage Commitment – Request and receive from an actor which has stored DICOM
objects (such as images or Evidence Documents) confirmation of receipt and ownership forthe specified objects, generally to allow the requesting actor to safely delete those objects.
11. Images Availability Query – The Department System Scheduler/Order Filler and ReportManager asks the Image Manager if a particular image or image series is available.
12. Patient Update – The ADT Patient Registration System informs the Order Placer and theDepartment System Scheduler/Order Filler of new information for a particular patient. The
Department System Scheduler may then further inform the Image Manager and ReportManager.
13. Procedure Update – The Department System Scheduler/Order Filler sends the ImageManager and Report Manager updated order or procedure information.
14. Query Images – An Image Display queries the Image Archive for a list of entries
representing images by patient, study, series, or instance.
______________________________________________________________________________
34
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1095

1100

1105

1110

1115

1120

1125

1130

1135

15. Query Presentation States – An Image Display queries the Image Archive for a list of
entries representing image Grayscale Softcopy Presentation States (GSPS) by patient, study,
series, or instance.
16. Retrieve Images – An Image Display or an Imaging Document Consumer requests andretrieves a particular image or set of images from the Image Archive or an Imaging
Document Source, respectively.
17. Retrieve Presentation States – An Image Display or an Imaging Document Consumer
requests and retrieves the Grayscale Softcopy Presentation State (GSPS) information for aparticular image or image set.
18. Creator Images Stored – An Evidence Creator sends new images to the Image Archive.
19. Creator Presentation State Stored – An Evidence Creator requests that the Image Archive
store the created Grayscale Softcopy Presentation State objects.
20. Creator Procedure Step In Progress – An Evidence Creator notifies the Performed
Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs
the Department System and Image Manager.
21. Creator Procedure Step Completed – An Evidence Creator notifies the Performed
Procedure Step Manager of the completion of a Procedure Step and the PPS Manager
informs the Department System and Image Manager.
22. Intentionally unassigned
23. Print Request with Presentation LUT – A Print Composer sends a print request to the Print
Server specifying Presentation LUT information.
24. Report Submission – A Report Creator sends a draft or final diagnostic report to the ReportManager.
25. Report Issuing – A Report Manager sends a draft or final diagnostic report to the Report
Repository.
26. Query Reports – A Report Reader provides a set of criteria to select the list of entries
representing diagnostic reports by patient, study, series, or instance known by the Report
Repository or External Report Repository Access.
27. Retrieve Reports – A Report Reader or an Imaging Document Consumer requests andretrieves a diagnostic report from the Report Repository, External Report Repository Accessor an Imaging Document Source.
28. Structured Report Export – A Report Manager composes an HL7 Result transaction bymapping from DICOM SR and transmits it to the Enterprise Report Repository for storage.
29. Key Image Note Stored – An Acquisition Modality or an Evidence Creator sends a Key
Image Note to the Image Archive
30. Query Key Image Notes – An Image Display queries the Image Archive for a list of entries
representing Key Image Notes by patient, study, series, or instance.
31. Retrieve Key Image Note – An Image Display or an Imaging Document Consumer requests
and retrieves a Key Image Note from the Image Archive or an Imaging Document Source,
respectively.
32. Authenticate Node [DEPRECATED] – This transaction is identical to, and has beensuperseded by the Authenticate Node as part of the ITI Audit Trail and Node Authentication
Profile (ITI TF-II 3.19).
______________________________________________________________________________
35
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1140

1145

1150

1155

1160

1165

1170

1175

1180

33. Maintain Time [DEPRECATED] – This transaction identical to, and has been supersededby the Maintain Time as part of the ITI Consistent Time Profile (ITI TF-II 3.1).
34. Record Audit Event [DEPRECATED] – This transaction has been superseded by the
Record Audit Event as part of the ITI Audit Trail and Node Authentication Profile (ITI TF-II
3.20).
35. Charge Posted - The Department System Scheduler/Order Filler sends descriptions ofpotential procedure and material charges.
36. Account Management – The ADT Patient Registration Actor informs the Charge Processor
about creation, modification and ending of the patient’s account.
37. Query Post-Processing Worklist – Based on a query from a worklist client (Evidence
Creator), a worklist is generated by the worklist manager (Post-Processing Manager)
containing either Post-Processing or Computer Aided Detection (CAD) workitems thatsatisfy the query. Workitems are returned in the form of a list of General Purpose Scheduled
Procedure Steps.
38. Workitem Claimed – A worklist client (Evidence Creator, Report Creator) notifies theworklist provider (Post-Processing Manager, Report Manager) that it has claimed theworkitem.
39. Workitem PPS In Progress – A worklist client (Evidence Creator, Report Creator) notifies
the worklist provider (Post-Processing Manager, Report Manager) that it has started work
(i.e., created a General Purpose Performed Procedure Step).
40. Workitem PPS Completed – A worklist client (Evidence Creator, Report Creator) notifies
the worklist provider (Post-Processing Manager, Report Manager) of the completion of aGeneral Purpose Performed Procedure Step.
41. Workitem Completed – A worklist client (Evidence Creator, Report Creator) notifies theworklist provider (Post-Processing Manager, Report Manager) that it has finished theworkitem (i.e., completed a General Purpose Scheduled Procedure Step).
42. Performed Work Status Update – The worklist provider informs other interested actors of
the on-going status and completion of performed work.
43. Evidence Document Stored – A source actor of Evidence Documents (Acquisition Modality
or Evidence Creator) sends recorded, measured or derived diagnostic evidence in the form of
a DICOM Structured Report to the Image Archive.
44. Query Evidence Documents – A user of Evidence Documents (Image Display, ReportCreator or Report Reader) queries the Image Archive for a list of entries representing
Evidence Documents.
45. Retrieve Evidence Documents – A user of Evidence Documents (Image Display, ReportCreator or Report Reader) or an Imaging Document Consumer requests and retrieves an
Evidence Document from the Image Archive or an Imaging Document Source, respectively.
46. Query Reporting Worklist – Based on a query from a Report Creator worklist client, aworklist is generated by the Report Manager containing reporting task workitems that satisfy
the query. Workitems are returned in the form of a list of General Purpose Scheduled
Procedure Steps.
47. Distribute Imaging Information on Media – A source actor (Portable Media Creator)
writes image data, other evidence objects and reports onto a piece of interchange media. The
media is physically transported to another actor (Portable Media Importer, Image Display,______________________________________________________________________________
36
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1185

1190

1195

1200

1205

1210

1215

1220

Report Reader, Display or Print Composer) which then imports, displays or prints theevidence objects and reports. The media can also be provided to a patient or a referring
physician for web-based viewing.
48. Appointment Notification – The Department System Scheduler/Order Filler sends the Order
Placer Actor the date and time of the appointment(s) related to one or more Scheduled
Procedure Step(s).
49. Instance Availability Notification – The Image Manager/Image Archive notifies interested
workflow actors (such as the Department System Scheduler/Order Filler, Post-Processing
Manager and Report Manager) about the availability status of instances at specified storage
locations.
50. Store Instances – An Export Selector sends to an Export Manager instances that are to be
de-identified, pseudonymized and exported.
51. Store Export Selection – An Export Selector sends to an Export Manager an instance of a
Key Object Selection Document that references a list of instances that are to be de-identified,pseudonymized and exported.
52. Store Additional Teaching File Information – An Export Selector sends to an Export
Manager instances containing additional information about the instances that are to beexported.
53. Export Instances – An Export Manager sends to a Receiver instances that have been
exported.
54. Provide and Register Imaging Document Set [DEPRECATED] - This transaction has
been deprecated and is superseded by the Provide and Register Imaging Document Set –MTOM/XOP Transaction (RAD TF-3: 4.68) as part of the Cross-Enterprise Document
Sharing for Imaging (XDS-I.b) Profile.
55. WADO Retrieve – A WADO Retrieve transaction is issued by an Imaging Document
Consumer to an Imaging Document Source to retrieve DICOM objects over HTTP/HTTPS
protocol [RAD-55].
56. Intentionally, temporarily Left Blank
57. Intentionally, temporarily Left Blank
58. Intentionally, temporarily Left Blank
59. Import Procedure Step In Progress – The Performed Procedure Step Manager receives
progress notification of an importation Procedure Step and in turn notifies the Order Filler,
Image Manager and the Report Manager.
60. Import Procedure Step Completed – The Performed Procedure Step Manager receives
completion notification of an importation Procedure Step and in turn notifies the Order Filler,
Image Manager and the Report Manager.
61. Imported Objects Stored – A system importing DICOM Objects or digitized hardcopy
sends imported DICOM Composite Objects to the Image Archive.
62. Store Dose Information – Send details of Irradiation Events encoded in DICOM SR using
DICOM Store.
63. Submit Dose Information – Send details of Irradiation Events encoded in DICOM SR using
secure FTP.
64. Query Dose Information – Obtain a list of references to Dose objects matching a given
filter.
______________________________________________________________________________
37
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1225

1230

1235

1240

1245

65. Retrieve Dose Information – Obtain specific Dose objects containing descriptions ofIrradiation Events.
66. Rejection Note Stored – Create and send a manifest referencing images that are rejected for
quality or patient safety reasons, rejected for incorrect modality worklist selection, or deleted
due to data retention expiration. The manifest can be used to hide or provide rejected images
later in routine use, based on specific configuration.
67. Intentionally, temporarily Left Blank
68. Provide and Register Imaging Document Set – MTOM/XOP – An Imaging Document
Source Actor uses the Provide and Register Imaging Document Set Transaction to submit
documents with associated metadata to a Document Repository. [RAD-68 specializes ITI41].
69. Retrieve Imaging Document Set – An Imaging Document Consumer Actor uses thisTransaction to issue a web service request to retrieve a set of DICOM instances. [RAD-69
specializes ITI-43].
70. Intentionally, temporarily Left Blank
71. Intentionally, temporarily Left Blank
72. Intentionally, temporarily Left Blank
73. Intentionally, temporarily Left Blank
74. Replacement Instances Stored – A Change Requester send new updated instances withcorrected header information to an Image Manager/Image Archive.
75. Cross Gateway Retrieve Imaging Document Set – An Initiating Imaging Gateway sends arequest for an Imaging Document Set to a Responding Imaging Gateway.

2.5 Product Implementations
Developers have a number of options in implementing IHE actors and transactions in productimplementations. The decisions cover four levels of optionality:
1250•

For a system, select which actors it will incorporate. (Multiple actors per system is
acceptable).

•

For each actor, select which Integration Profiles it will participate in.

•

For each actor-profile, select which optional transactions will be implemented. All
required transactions must be implemented for the profile to be supported. (Refer to theIntegration Profile Tables in sections 3-14)•

Finally, for each transaction, select which optional features will be supported. (Refer tothe transaction descriptions in TF Volume 2 and Volume 3)

1255

1260

Implementers should provide a statement describing which IHE Actors, IHE Integration Profiles,
optional transactions and optional features are incorporated in a given product. The
recommended form for such a statement is defined in Appendix D.
In general, a product implementation may incorporate any single actor or combination of actors.
However, in the cases specified below, the implementation of one actor requires theimplementation of one or more additional actors:______________________________________________________________________________
38
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•The Image Archive in any Radiology profile shall be grouped with the Image Manager,
and the Image Manager shall be grouped with the Image Archive.

•

The Image Manager participating in Scheduled Workflow or Reporting Workflow
Integration Profiles shall be grouped with a Performed Procedure Step Manager. The
grouped Performed Procedure Step Manager shall be capable of being disabled via
configuration.

1270

•

The Department System Scheduler/Order Filler participating in any of the following
profiles, Scheduled Workflow, Patient Information Reconciliation, Charge Posting,Presentation of Grouped Procedures, Import Reconciliation Workflow, or Reporting
Workflow, shall be grouped with a Performed Procedure Step Manager. The grouped
Performed Procedure Step Manager shall be capable of being disabled via configuration.

1275

•

The Print Composer in any Radiology profile shall be grouped with an Image Manager,an Acquisition Modality, an Image Display or an Evidence Creator.

•

The Evidence Creator participating in Post-Processing Workflow shall be grouped withan Image Display from one or more Radiology profiles.

•

A Radiology Profile Actor which is grouped with a Secure Node Actor or Secure
Application Actor of the ITI Audit Trail and Node Authentication Integration Profile (ITI
TF-1: 9.4) shall support the applicable Radiology events and semantics defined in RAD
TF-3: 5.1.

•

The Post-Processing Manager in the Post-Processing Workflow Profile shall be groupedwith either an Image Manager or a Department System Scheduler.

•

The Portable Media Importer in the Portable Data for Imaging Profile shall be groupedwith at least one of the following actors from one or more Radiology profiles in order toperform import of the supported evidence objects and/or Diagnostic Reports:

1265

1280

1285

1290

1295
•

•

Evidence Creator (Evidence Documents)•

Acquisition Modality (Images, Key Image Notes, Evidence Documents)•

Image Manager/Image Archive (Images, Presentation States, Key Image Notes,
Evidence Documents)•

Report Creator (Diagnostic Reports)•

Report Manager (Diagnostic Reports)•

Report Repository (Diagnostic Reports)•

Importer

The Imaging Document Consumer shall be grouped with an ITI XDS.b Document
Consumer, thereby supporting the Document Consumer’s transactions for querying a
Document Registry and retrieving from a Document Repository as defined in ITI XDS.b.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•The Importer Actor in the Import Reconciliation Workflow Profile is generic in terms of
not defining a specific transport mechanism for the Evidence Objects it imports. It may
be necessary for the Importer to be grouped with additional Actors to support specifictransport mechanisms. For example, to support import from PDI Media, the Importer
Actor must be grouped with the Portable Media Importer Actor.

•

The Change Requester is generic in terms of not defining a specific mechanism forobtaining the original instances that it requests changes to. It shall be grouped with atleast one of the following actors in order to obtain the original instances:

1300

1305

1310

1315

1320

1325

Evidence Creator•

Acquisition Modality•

Image Manager/Image Archive

When multiple actors are grouped in a single product implementation, all transactions originatingor terminating with each of the supported actors shall be supported (i.e., the IHE transactions
shall be offered on an external product interface). The exceptions to this rule are any transactions
defined between actors in the required groupings defined above.
For example, the Procedure Step In Progress/Completed transaction does not need to besupported between the Performed Procedure Step Manager and the Image Manager when theseare grouped together in a single system. On the other hand, the Report Submission Transaction
must be supported even by an implementation that groups the Report Creator and the ReportManager.
When two or more actors are grouped together, internal communication between actors is
assumed to be sufficient to allow the necessary information flow to support their functionality;
for example, the Image Manager provides necessary information updates to the Image Archive tosupport its Query/Retrieve functionality. The exact mechanisms of such internal communication
are outside the scope of the IHE Technical Framework.
The following examples describe which actors typical systems might be expected to support.
This is not intended to be a requirement, but rather to provide some examples to aid
understanding.
•

A modality system, such as an MRI scanner and console or Ultrasound system mighttypically include an Acquisition Modality Actor and a Print Composer Actor.

•

An imaging workstation, such as a post-processing workstation or advanced review
station might typically include an Image Display Actor, an Evidence Creator Actor and a
Print Composer Actor.

•

An HIS registration and order entry system might typically include the ADT Patient
Registration Actor and an Order Placer Actor.

•

A departmental RIS system might typically include a Department System Scheduler
Actor, an Order Filler Actor, a Performed Procedure Step Manager Actor, a ReportManager Actor and a Report Reader Actor.

1330

1335

•

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
•

1340

1345

1350

1355

An Ultrasound system that generates echo report measurements would likely include an
Acquisition Modality Actor that supports both the Scheduled Workflow Profiles and the
Evidence Documents Profile.

When an implementation has an actor supporting multiple integration profiles, the actor isrequired to support logical cross-behaviors/ transactions. For example, if an Evidence Creatorsupports the Post-Processing Workflow and Evidence Documents Profiles, then the actor must
generate PPS messages when creating evidence documents. If an Image Display supports the
Simple Image and Numeric Reports and Consistent Presentation of Images Profiles, then theactor must make use of any GSPS referenced by the Simple Image and Numeric Report whenrendering the relevant images.
If an implementation supports the Consistent Presentation of Images Integration Profile withboth an Image Display and a Print Composer, both actors shall support calibration against the
Grayscale Softcopy Display Function, in a consistent manner across both actors. In addition, thecombined actors must perform the image data manipulations necessary to match the presentationof the Hardcopy with the Softcopy presentations.
If an implementation includes a Print Composer in combination with an Image Manager,
Acquisition Modality, or Evidence Creator (and not an Image Display), then it is recommended
but not required that the Print Composer calibrate its display system. In addition the Print
Composer must be able to perform the image data manipulations specified by the Grayscale
Softcopy Presentation State that is related to the image.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3 Scheduled Workflow (SWF)

1360

1365

The Scheduled Workflow Integration Profile establishes the continuity and integrity of basic
departmental imaging data. It specifies a number of transactions that maintain the consistency ofpatient and ordering information as well as providing the scheduling and imaging acquisition
procedure steps. This profile also makes it possible to determine whether images and otherevidence objects associated with a particular performed procedure step have been stored(archived) and are available to enable subsequent workflow steps, such as reporting. It may also
provide central coordination of the completion of processing and reporting steps as well as
notification of appointments to the Order Placer.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3.1 Actors/Transactions
Figure 3.1-1 diagrams the actors involved with this profile and the transactions between actors. .
Note: In an attempt to simplify Figure 3.1-1, not all of the “optional” transactions listed in Table 3.1-1 are shown in the
diagram.

1370
ADT
Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓↓ Pt. Registration [RAD-1]↓ 12: Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]→ Appointment Notification [RAD-48]

Order Placer

DSS/ Order Filler↑ Modality PS in Progress [RAD-6]↑ Modality PS Completed [RAD-7]↑ Creator PS in Progress [RAD-20]↑ Creator PS Completed [RAD-21]↓ Procedure Scheduled [RAD-4]↑ Image Availability Query [RAD-11]↓ Procedure Updated [RAD-13]↑ Performed Work Status Update [RAD-42]↓ Performed Work Status Update [RAD-42]↑ Instance Availability Notification [RAD-49]

Evidence Creator

Image Display↓ Creator PS in Progress [RAD-20]↓ Creator PS Completed [RAD-21]
StorageCommitment [RAD-10]↓

Performed
Procedure
Step Manager→ Modality PS in Progress [RAD-6]→ Modality PS Completed [RAD-7]→ Creator PS in Progress [RAD-20]→ Creator PS Completed [RAD-21]

Image
Manager

StorageCommitment [RAD-10] ↑↓ Creator Images
Stored [RAD-18]↓ Query Images[RAD-14]↓ Retrieve Images[RAD-16]

Image
Archive↑ Modality Image Stored [RAD-8]← Modality PS in Progress [RAD-6]← Modality PS Completed [RAD-7]
Acquisition
Modality← Query Modality Worklist [RAD-5]

Figure 3.1-1: Scheduled Workflow Diagram

1375

Table 3.1-1 lists the transactions for each actor directly involved in the Scheduled Workflow
Integration Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile that implementations may choose tosupport is listed in Volume 1, Section 3.2.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Table 3.1-1: Scheduled Workflow - Actors and Transactions
ActorsADT Patient Registration
Order Placer

Department System Scheduler/
Order Filler

Acquisition Modality

Image Manager/
Image Archive

Transactions

Optionality

Vol. 2/3
SectionPatient Registration [RAD-1]

R

4.1

Patient Update [RAD-12]

R

4.12

Patient Registration [RAD-1]

R

4.1

Patient Update [RAD-12]

R

4.12

Placer Order Management [RAD-2]

R

4.2

Filler Order Management [RAD-3]

R

4.3

Appointment Notification [RAD-48]

O

4.48

Patient Registration [RAD-1]

R

4.1

Patient Update [RAD-12]

R

4.12

Placer Order Management [RAD-2]

R

4.2

Filler Order Management [RAD-3]

R

4.3

Procedure Scheduled [RAD-4]

R

4.4

Query Modality Worklist [RAD-5]

R

4.5

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]

R

4.7

Images Availability Query [RAD-11]

O

4.11

Procedure Updated [RAD-13]

R

4.13

Creator Procedure Step in Progress[RAD-20]

R

4.20

Creator Procedure Step Completed[RAD-21]

R

4.21

Performed Work Status Update [RAD42](as the Receiver, see Note 1))

O

4.42

Appointment Notification [RAD-48]

O

4.48

Instance Availability Notification[RAD-49]

O

4.49

Query Modality Worklist [RAD-5]

R

4.5

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Modality Images Stored [RAD-8]

R

4.8

Storage Commitment [RAD-10]

R

4.10

Procedure Scheduled [RAD-4]

R

4.4

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]R

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsPerformed Procedure Step
Manager

Image Display
Evidence Creator

1380

Transactions

Optionality

Vol. 2/3
Section

Modality Images Stored [RAD-8]

R

4.8

Storage Commitment [RAD-10]

R

4.10

Images Availability Query [RAD-11]

R

4.11

Procedure Updated [RAD-13]

R

4.13

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Creator Images Stored [RAD-18]

R

4.18

Creator Procedure Step in Progress[RAD-20]

R

4.20

Creator Procedure Step Completed[RAD-21]

R

4.21

Performed Work Status Update [RAD42](as the Receiver, see Note 1)

O

4.42

Instance Availability Notification[RAD-49]

O

4.49

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Creator Procedure Step in Progress[RAD-20]

R

4.20

Creator Procedure Step Completed[RAD-21]

R

4.21

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Creator Images Stored [RAD-18]

R

4.18

Creator Procedure Step in Progress[RAD-20]

O

4.20

Creator Procedure Step Completed[RAD-21]

O

4.21

Storage Commitment [RAD-10]

R

4.10

Note 1: The Department System Scheduler or the Image Manger may optionally choose to be receivers of Performed Work
Status Update transactions in order to monitor the status of work in workflows that are managed by other systems(see RAD TF-3: 4.42).
Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

3.2 Scheduled Workflow Integration Profile Options
1385

Options that may be selected for this Integration Profile are listed in the Table 3.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Table 3.2-1: Scheduled Workflow - Actors and Options
Actor

OptionVol. & Section

ADT Patient Registration

HL7 v2.5.1

RAD TF-1:3.2.1
RAD TF-2:4.1
RAD TF-2:4.12

Order Placer

Departmental Appointment Notification

RAD TF-3: 4.48

HL7 v2.5.1

RAD TF-1:3.2.1
RAD TF-1:3.3.3.2
RAD TF-2:4.1
RAD TF-2:4.2
RAD TF-2:4.3
RAD TF:2.12

Image Availability

RAD TF-2:4.11

Departmental Appointment Notification

RAD TF-3:4.48

PPS Exception Management

RAD TF-2:4.7

Performed Work Status Update - Receive

RAD TF-2:4.42

Availability of PPS-Referenced Instances

RAD TF-3:4.49

HL7 v2.5.1

RAD TF-1:3.2.1
RAD TF-1:3.3.3.2
RAD TF-2:4.1
RAD TF-2:4.2
RAD TF-2:4.3
RAD TF-2:4.4
RAD TF-2:4.12
RAD TF-2:4.13

Patient Based Worklist Query (note 1)

RAD TF-2:4.5

Broad Worklist Query (note 1)

RAD TF-2:4.5

Assisted Acquisition Protocol Setting

RAD TF-2:4.6

PPS Exception Management

RAD TF-2:4.7

Modality Group Case (note 2)

RAD TF-2:.4.6

Billing and Material Management

RAD TF-2:4.7

Availability of PPS-Referenced Instances

RAD TF-3:4.49

PPS Exception Management

RAD TF-2:4.7

Performed Work Status Update - Receive

RAD TF-2:4.42

HL7 v2.5.1

RAD TF-1:3.2.1
RAD TF-2:4.4
RAD TF-2:4.13

Image Display

No options defined-

Performed Procedure Step Manager

No options defined-

Evidence Creator

Creator Performed Procedure Step

RAD TF-2:4.20
RAD TF-2:4.21

PPS Exception Management (see note 3)

RAD TF-2:4.21

DSS/Order Filler

Acquisition Modality

Image Manager/ Image Archive

Note 1: At least one of these two options is required. Both may be supported.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1390

Note 2: When a modality claims support for the Modality Group Case Option, it is required to support all three grouping
scenarios described in RAD TF-2: 4.6.4.1.2.3.4.
Note 3: An Evidence Creator claiming the PPS Exception Management Option shall also support the Creator Performed
Procedure Step Option.

1395

The Evidence Creator, Acquisition Modality and Image Manager/ Image Archive will likely
support a variety of DICOM SOP Classes. It is expected that this level of optionality will be
documented by a reference in the IHE Integration Statement (see appendix D).
3.2.1 HL7 v2.5.1 Option

1400

The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in thetransactions referenced in Table 3.2-1. The actor shall permit configuration for each system thatit communicates with using the referenced transactions whether HL7 v2.3.1 or HL7 v2.5.1 isused. It is possible that the actor may receive HL7 v2.3.1 messages and send HL7 v2.5.1
messages or vice versa.
The specifications in the HL7 v2.5.1 Option maintain semantic equivalency with HL7 v2.3.1
implementations and the field correspondences are summarized in RAD TF-2 Appendix E.

1405

1410

1415

3.3 Scheduled Workflow Process Flow
This section describes the process and information flow of patient care as it is defined in the IHE
Technical Framework under “normal” circumstances. It covers transactions RAD-1 throughRAD-12 and transaction RAD-23, which reflect a typical patient encounter fromregistration/admission through the performance of an ordered procedure. See appendix C for an
overview of the information exchange between the Department System Scheduler/Order Filler
and Image Manager.
To support the Scheduled Workflow Profile, an actor that claims support of other content
profiles (Consistent Presentation of Images, Key Image Notes or Evidence Documents) is
required to support the relevant storage, query and retrieve transactions and manage creation of
those objects in the same way images are supported. The following diagrams will mostly show
the management of images.
3.3.1 Administrative and Procedure Performance Process Flow

1420

This case covers both inpatient and outpatient procedures. The patient may be new or known tothe current healthcare facility. The following sequence of steps describes the typical process flow
when a request is made to perform an imaging procedure on a patient.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image
Manager

Acquisition
Modality

Register/
Admit
Patient
Patient
Registration [RAD-1]

Create Order
Placer Order Mgmt –New [RAD-2]
Schedule Procedure and/or
Assign Protocol
Procedure Scheduled[RAD-4]
Query Modality
Worklist [RAD-5]

Continued in Figure 3.3-2

Figure 3.3-1: Administrative Process Flow______________________________________________________________________________
48
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
Placer

Department System
Scheduler/ Order
FillerImage
Manager/
Image
Archive

Acquisition
Modality /Print
Composer

Print
ServerModality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform
Acquisition

Modality Images
Stored [RAD-8]
Modality
Presentation StateStored [RAD-9]
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]

Print Request [RAD-23*]
Storage Commitment[RAD-10]
Images Availability
Query [RAD-11]
Order Status
Update [RAD-3]

1425

Figure 3.3-2: Procedure Performance Process Flow
Note: The Print Request [RAD-23] transaction is not a part of this profile; it is displayed for illustration purposes only.

The following should be noted in relation to the Administrative and Procedure Performance
process flow:
1430

1435

•

The Print Composer is grouped with an Acquisition Modality but is shown separately inthe diagram to distinguish the different transactions.

•

Schedule Procedure: The Department System associates the order with a number ofRequested Procedures that have to be performed to satisfy the order. Each Requested
Procedure prescribes a number of actions that have to be performed by Acquisition
Modalities. Actions are grouped into Scheduled Procedure Steps based on the timing andordering. Scheduled Procedure Steps are scheduled, i.e., assigned a time slot andperforming resource (modality).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

Protocol Assigned: The radiologist determines the protocol (i.e., settings and conditions
to be used in performing the Scheduled Procedure Steps); in particular, the ordered list ofcodes identifying the protocol for each of the steps. This may happen prior to,
simultaneous with, or subsequent to the Schedule Procedure process step.

•

The diagram above shows one particular sequencing of the Modality Procedure Step
Completed [RAD-7] transaction. This transaction may occur at any point following thecreation of an image and/or Presentation State (GSPS) objects. This means it can occur
before images and/or GSPS are stored, after storage, after printing (as in this example), oreven after storage commitment. The IHE Technical Framework does not specify thetiming of this transaction in relation to other transactions.

•

The diagram above shows the managed creation of images. The equivalent flow applies
to other Evidence Documents that the actor supports.

1440

1445

1450

3.3.2 Patient Update Flow

1455

This case covers the situation where patient information updates are introduced into the system atthe various stages of the normal process flow. Such updates will cause additional transactions tooccur to assure synchronization of information between interested actors. Only the affected partsof the normal flow diagram are presented below. All subsequent process steps will progress
according to the normal flow diagram.
3.3.2.1 Patient Update Before Procedure Scheduling
If patient information is changed before the corresponding procedure(s) are scheduled by the
Department System Scheduler/Order Filler, the Patient Registration steps are altered as presented
in the Figures 3.3-3 and 3.3-4.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image
Manager

Acquisition
Modality

Register/
Admit
Patient
Patient Registration [RAD-1]

ModifyPatient
Patient
Update [RAD-12]

Create Order
Placer Order Mgmt –New [RAD-2]

1460
Figure 3.3-3: Patient Update Before Order Entry______________________________________________________________________________
51
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image
Manager

Acquisition
Modality

Admit/
Register
Patient
Patient Registration [RAD-1]

Create Order
Placer Order Mgmt –New [RAD-2]
ModifyPatient
Patient
Update [RAD-12]

Figure 3.3-4: Patient Update After Order Entry

1465

The Modify Patient process includes changing inpatient demographics, merging two patient
records and moving the information from one patient record to another.
3.3.2.2 Patient Update After Procedure Scheduling
If patient information is changed after procedure(s) are scheduled by the Order Filler, the Patient
Update transactions are altered as follows:______________________________________________________________________________
52
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image Manager

Acquisition
Modality

Register/
Admit
Patient
Patient Registration[RAD-1]Create Order
Placer Order Mgmt –New [RAD-2]
Schedule Procedure and/or
Assign Protocol
Procedure
Scheduled [RAD-4]

Query Modality
Worklist [RAD-5]
ModifyPatient
Patient
Update [RAD-12]

1470
Figure 3.3-5: Patient Update After Procedure Scheduling

Note that in the Patient Information Reconciliation Profile (PIR), the Image Manager will also be
notified and will have additional responsibility when Patient updates occur.
3.3.3 Order Change Flow1475

3.3.3.1 Order Change Flow, HL7 v2.3.1
This case covers the situation when the Order Placer or the Department System Scheduler/Order
Filler has to change order information or cancel/discontinue an order. When an order information
change is necessary, for HL7 v2.3.1, the IHE Technical Framework requires the initiating actor
to cancel the order and generate the new one using the new information. Figures 3.3-6 and 3.3-7______________________________________________________________________________
53
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1480

depict examples of order cancellation/re-ordering flow initiated by the Order Placer and theDepartment System Scheduler/Order Filler respectively. Note that one should consider thesetransactions as being performed between the process flow fragments depicted in the Figures 3.31 and 3.3-2 to ensure synchronization of information between interested actors.
ADT

Department System
Scheduler/ Order
Filler

Order
PlacerImage Manager

Acquisition
Modality

Cancel Order
Placer Order Mgmt
- Cancel [RAD-2]

Procedure Update[RAD-13]

Query Modality Worklist [RAD-5]
Create Order
Placer Order Mgmt New [RAD-2]

Procedure
Scheduled [RAD-4]

Query Modality Worklist [RAD-5]

1485
Figure 3.3-6: Order Replacement by the Order Placer

Department System Scheduler/Order Filler may cancel an order received from the Order Placer
and place the new order as a replacement, as shown in the Figure 3.3-7.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

ADT

Department System
Scheduler/ Order
Filler

Order
PlacerFiller Order Mgmt
- Cancel [RAD-3]

Image Manager

Acquisition
Modality

Order
Cancelled

Procedure Update[RAD-13]

Query Modality Worklist [RAD-5]

Filler Order Mgmt
– New [RAD-3]

CreateOrder

Procedure
Scheduled [RAD-4]

Query Modality Worklist [RAD-5]

1490
Figure 3.3-7: Order Replacement by the Department System Scheduler/Order Filler

1495

The Department System Scheduler/Order Filler may also generate a new order on its own as ameans of handling the unidentified patient case discussed in section 4.2. The process flow insuch a situation corresponds to the ordering sequence in Figure 3.3-7, without the preceding
Order Cancel transaction.
Note: The IHE Technical Framework does not support notification of the modality of the order discontinuation after the
Modality Procedure Step In Progress message has been generated by the Acquisition Modality, i.e., the current
procedure step will be completed even though the order could be discontinued.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3.3.3.2 Change Order Flow, HL7 v2.5.1 Option

1505

This case covers the situation when the Order Placer or the Department System Scheduler/Order
Filler has to change order information for systems implementing HL7 v2.5.1. When an orderinformation change is necessary, the IHE Technical Framework allows for the initiating actor tochange the order in a single message with the new information. Figures 3.3-8 and 3.3-9 depict
examples of order change flow initiated by the Order Placer and the Department System
Scheduler/Order Filler respectively. Note that one should consider these transactions as being
performed between the process flow fragments depicted in the Figures 3.3-1 and 3.3-2 to ensure
synchronization of information between interested actors.

1510
ADT

Department System
Scheduler/ Order
Filler

Order
PlacerImage Manager

Acquisition
Modality

Modify Order
Placer Order Mgmt Modified [RAD-2]

Procedure Update[RAD-13]

Query Modality Worklist [RAD-5]

Figure 3.3-8: Order Modified by the Order Placer

Department System Scheduler/Order Filler may modify an order originally received from theOrder Placer, as shown in the Figure 3.3-9.
1515______________________________________________________________________________
56
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

ADT

Department System
Scheduler/ Order
Filler

Order
PlacerFiller Order Mgmt
– Modify [RAD-3]

Image Manager

Acquisition
Modality

ModifyOrder

Procedure Update[RAD-13]

Query Modality Worklist [RAD-5]

Figure 3.3-9: Order Modified by the Department System Scheduler/Order Filler

1520

1525

1530

The Order Placer may not change an order that has already been started, i.e., one for which Order
Filler has transmitted an “In-Progress” status. However, if the Order Filler receives the changeorder message after it has sent the Status Update message (for example, in a case of a race
condition between two messages), Order Filler will accept the change order and perform
Transaction RAD-13 Procedure Update to notify Image Manager.
The Order Filler may not change a scheduled procedure step that has already been started, i.e.,
one for which the Acquisition Modality has transmitted an “In-Progress” status. The IHE
Technical Framework does not support notification to the modality of the Scheduled Procedure
Step discontinuation or change after the Modality Procedure Step In Progress message has been
generated by the Acquisition Modality, i.e., the current procedure step will be completed eventhough the order could be changed or discontinued.
3.3.4 Exception Management Workflow
This case addresses the need to manage errors at the modality. The types of exceptions coveredby this case are as follows:

1535

•

Selection of the incorrect Scheduled Procedure Step from the Modality Worklist.

•

The need to handle the consequences of having performed a procedure step other than thescheduled one.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1540

Some of these exception cases are addressed using required functionality for IHE actors in the
Scheduled Workflow Profile and are described first in this section. Other exception cases arelisted separately in this section and this Exception Management Workflow is supported by the
PPS EXCEPTION MANAGEMENT Option or other options in the Scheduled Workflow
Integration Profile. The following numbered items list exception cases that shall be supported by
the actors listed in each item.
In the course of the scheduled workflow, such exceptions may occur at different times:

1545

1550

1555

1560

1565

1. Before the Modality Procedure Step in Progress transaction is issued, theOperator/Radiologist changes the order on the Department System Scheduler which thenprovides the Modality Worklist as defined by the Scheduled Workflow Integration Profile(see the Order Change flow described in section 3.3.3). This will ensure that the most recent
Worklist Information is used by the Modality. This case does not require the PPS
EXCEPTION MANAGEMENT OPTION. The Acquisition Modality shall be able to process
new worklist information that results from this order change; when or how the modality requeries the Department System Scheduler is not specified by this framework.
2. After the Modality Procedure Step in Progress transaction has been issued, but before theModality Procedure Step Completed transaction is issued, the Operator/Radiologist may
discontinue the PPS. In this case any images that may have been acquired are part of the
discontinued PPS and they shall be Storage Committed. This case is supported byAbandoned case (see Volume 2 - section 4.6.4.1.2.3.5) of the Scheduled Workflow
Integration Profile. See the end of this section for discussion of this case and PPS
EXCEPTION MANAGEMENT Option.
3. After the Modality Procedure Step Completed transaction has been issued, theOperator/Radiologist may notice or become aware that an incorrect worklist entry selection
was made. Whether this occurs before the Requested Procedure is read or afterwards, themodality is not responsible for performing the necessary corrections. Rather the ImageManager and the Department Scheduler Actors must make such corrections (See Volume 2 section 4.7.4.1.3.1). The Image Manager and the Order Filler may also offer a correction
capability to recover the erroneous instances. IHE does not provide a mechanism topropagate automatically this correction between the Image Manager/Image Archive and theDepartment System Scheduler/Order Filler.
These next cases are optional for Acquisition Modalities and deal with using a different protocol
at the modality as was scheduled by the Department System Scheduler/ Order Filler.

1570

1575

1. After the Modality Procedure Step in Progress transaction has been issued, but before theModality Procedure Step Completed transaction is issued, the Operator/Radiologist may
decide to modify the “in progress” Performed Procedure Step from what was intended by the
Requested Procedure and Scheduled Procedure Step selected. In the Scheduled Workflow
Integration Profile, the Acquisition Modality Actor notifies the PPS Manager (and in turn the
Image Manager and the Department System Scheduler) by returning a Procedure Code
Sequence of zero length. In addition, if the ASSISTED ACQUISITION PROTOCOLSETTING Option is supported by the Acquisition Modality, it can indicate this change by______________________________________________________________________________
58
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
returning a Performed Protocol Code Sequence different from the Scheduled Protocol Code
Sequence (see Figure 3.3-8 below).
1580

2. Before the Modality Procedure Step in Progress transaction is issued, theOperator/Radiologist decides to proceed without changing the order on the Department
System Scheduler/Order Filler by performing one or more Procedure Steps different thanscheduled by the Modality Worklist entry as defined by the Scheduled Workflow Integration
Profile. Its handling at the Acquisition Modality may be facilitated by the ASSISTEDACQUISITION PROTOCOL SETTING Option.

1585
Order
Placer

Department System
Scheduler/ Order
FillerImage
Manager/
Image Archive

Acquisition
Modality /Query Modality Worklist [RAD-5]
Select MWL
Entry (SPS)
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform Acquisition(changed from scheduled)

Modality Images
Stored [RAD-8]
Modality
Presentation StateStored [RAD-9]
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]
Procedure Codeand (Performed
Protocol Code)

Procedure Codeand (Performed
Protocol Code)

Figure 3.3-8: Exception Management Workflow (Changed from Scheduled on Modality)

1590

1595

The last case in this section describes how the PPS EXCEPTION MANAGEMENT Option may
be utilized in the Scheduled Workflow Integration Profile. This feature is optional for theAcquisition Modality, Department System Scheduler and Image Manager Actors.
1. After the Modality Procedure Step In Progress transaction has been issued, theOperator/Radiologist may realize that the wrong SPS has been selected (incorrect patient orincorrect Requested Procedure/Order for the same patient). In this case some of the acquired
images or other evidence objects may already have been stored to the Image Manager/Image
Archive (with or without storage commitment confirmed). With the PPS EXCEPTION______________________________________________________________________________
59
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1600

MANAGEMENT Option of the Scheduled Workflow Integration Profile, the Acquisition
Modality Actor notifies the PPS Manager (and in turn the Image Manager and theDepartment System Scheduler/Order Filler) of the error so that these systems takeappropriate action (See Volume 2 - Section 4.7.4.1.3.1 and Figure 3.3-9 below).

1605

IHE does not define how the modality may dispose of and/or correct the images or otherevidence objects. Each implementation shall decide if it is useful to support the storage of thecorrected images or other evidence objects, when clinically meaningful. However if they do,
new Modality Procedure Step in Progress/Completed and Storage Commitment transactions
shall be used.

1610

In this case, the PPS EXCEPTION MANAGEMENT Option of the Scheduled Workflow
Integration Profile provides further functionality. The Modality Actor notifies the PPSManager (and in turn the Image Manager and the Department System Scheduler) of thereason for the discontinuation so that these systems may take the appropriate actions (seeFigure 3.3-10 below).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
Placer

Department System
Scheduler/ Order
FillerImage Manager/
Image Archive

Acquisition
Modality /Query Modality Worklist [RAD-5]
Select (wrong)
MWL Entry (SPS)
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform Acquisition(for wrong MWL entry)

Modality Images
Stored [RAD-8]
Modality
Presentation StateStored [RAD-9]

Modality Procedure Step
Completed [RAD-7]
Discontinue withwrong MWL entry
selected

Modality Procedure Step
Completed [RAD-7]
Discontinue withwrong MWL entry
selected

Query Modality Worklist [RAD-5]
Select (right) MWL
Entry (SPS)
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]
Optional
Recycling ofacquired
instances withwrong WL
entry
selected.

Update instances(for right MWL entry)

Modality Images
Stored [RAD-8]
Modality
Presentation StateStored [RAD-9]

Modality Procedure Step
Completed [RAD-7]
Completed

Modality Procedure Step
Completed [RAD-7]
Completed

Figure 3.3-9: Exception Management Workflow (Wrong Worklist Entry Selected)______________________________________________________________________________
61
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
Placer

Department System
Scheduler/ Order
FillerImage
Manager/
Image Archive

Acquisition
Modality /Query Modality Worklist [RAD-5]
Select MWL
Entry (SPS)
Modality Procedure StepModality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform Acquisition(PPS Discontinued)

Modality Images
Stored [RAD-8]
Modality
Presentation StateStored [RAD-9]

Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]
Reason for
Discontinue

Reason for
Discontinue

1615
Figure 3.3-10: Exception Management Workflow (Discontinued with a Reason)

3.3.5 Implicit Post-Processing
1620

1625

1630

This case addresses image post-processing tasks performed as an implicit part of the Scheduled
Workflow.
In general, post-processing tasks scheduled and managed explicitly using post processing
worklists are addressed by the Post-Processing Workflow Integration Profile (see Volume 1,
section 12 for further details on that profile). However, at some sites, post-processing tasks
performed on the acquisition system or adjacent workstations are implied by the information in
the acquisition worklist. In such cases, the post-processing is managed by the technician simply
carrying out the steps following acquisition.
Technicians may be instructed that certain post-processing should always be performed forcertain acquisitions, or alternatively, different protocol codes may be provided in the acquisition
worklist to indicate intended post-processing. In either case, no worklist is used on the postprocessing Evidence Creator.
In the case of this “implicit post-processing workflow”, the Evidence Creator may obtain source
images and other evidence objects necessary for post-processing by receiving them from theAcquisition Modality Actor (either pulled or pushed via some non-IHE defined mechanism) or______________________________________________________________________________
62
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1635

by being grouped with an Image Display Actor (giving the system query/retrieve capabilities).
Based on the information contained in the images, the Evidence Creator can send status
messages and store its results according to the IHE transactions as shown in the following use
cases.
The following sequence of steps describes the typical process flow when the Evidence Creatorreceives the images from an Acquisition Modality via some non-IHE means.
Department System
Scheduler/ Order
FillerImage
Manager/
Image Archive

Acquisition
Modality

Evidence
CreatorQuery Modality Worklist [RAD-5]
Select MWL
Entry (SPS)
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform Acquisition
Modality Images
Stored [RAD-8]
Modality Presentation
State Stored [RAD-9]
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]
Transfer
ImagesCreator Procedure Step Creator Procedure Step
In Progress [RAD-20] In Progress [RAD-20]
Perform PostProcessing
Creator Images
Stored [RAD-18]
Creator Presentation
State Stored [RAD-19]
Creator Procedure Step
Completed [RAD-21]

Creator Procedure Step
Completed [RAD-21]

1640
Figure 3.3-11: Post-processing in Scheduled Workflow______________________________________________________________________________
63
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Note: the Modality Presentation State Stored [RAD-9] and Creator Presentation State Stored [RAD-19] transactions are nota part of this profile; they are displayed for illustration purposes only.

1645

1650

1655

The following should be noted in relation to the Post-Processing process flow in Scheduled
Workflow as described above:•

The images for post-processing are transferred from the Acquisition Modality to the
Evidence Creator by means that are out of scope of the IHE Technical Framework.

•

Perform Post-Processing: The Evidence Creator uses the source images and/or otherevidence objects it receives from the Acquisition Modality to perform post-processing
tasks and generate new set(s) of images and/or other evidence documents. It uses
information from the source images to populate the newly created objects and the Creator
Performed Procedure Step Messages.

The following sequence of steps describes the typical process flow when Evidence Creator isgrouped with Image Display.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/ Order
FillerImage Manager/
Image Archive

Acquisition
Modality

Evidence
Creator/ Image
Display

Query Modality Worklist [RAD-5]
Select MWL
Entry (SPS)
Modality Procedure Step
Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform Acquisition
Modality Images
Stored [RAD-8]
Modality Presentation
State Stored [RAD-9]
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]

Query Images [RAD-14]

Retrieve Images[RAD-16]Creator Procedure Step
In Progress [RAD-20]

Creator Procedure Step
In Progress [RAD-20]

Creator Images
Stored [RAD-18]
Creator Presentation
State Stored [RAD-19]
Creator Procedure Step
Completed [RAD-21]

Perform
PostProcessing

Creator Procedure Step
Completed [RAD-21]

Figure 3.3-12: Post-processing in Scheduled Workflow (performed on Evidence Creator)
Note: the Modality Presentation State Stored [RAD-9] and Creator Presentation State Stored [RAD-19] transactions are nota part of this profile; they are displayed for illustration purposes only.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1660

1665

1670

The following should be noted in relation to the Post-Processing process flow on the independentworkstation:•

The Evidence Creator is grouped with the Image Display and the images for postprocessing are retrieved from the Image Archive where the Acquisition Modality has
transferred them.

•

Perform Post-Processing: The Evidence Creator uses the source images and/or otherevidence objects it receives from the Image Archive to perform post-processing tasks andgenerate new set(s) of images and/or other evidence documents. It uses information fromthe source images to populate the newly created objects and the Creator Performed
Procedure Step Messages.

3.3.6 Departmental Appointment Booking
This case addresses the use of the Departmental Appointment Notification Option by the Order
Placer and Order Filler Actors.

1675

1680

1685

1690

Order Fillers that support this option shall have ability to be configured so that the Appointment
Notification transaction is not sent when connected to an Order Placer that does not support the
Departmental Appointment Notification Option.
In the IHE Scheduled Workflow Integration Profile, the scheduling needed to perform an Orderis managed by the Departmental System Scheduler/Order Filler. The Order Placer may request
along with an Order a preferred date and time for this Order, but it is the Order Filler that sets,
updates and possibly cancels the appointment(s) for examinations. When a new Order is placedby the Order Placer or the Order Filler, an Appointment Notification (New Bookings) is sent to
the Order Placer. This Appointment Notification (New Bookings) may include several
appointments bookings in case some of the Scheduled Procedure Steps require separate
appointments. Equally, one or more Scheduled Procedure Steps may be scheduled during thesame appointment booking.
If any changes to some of these appointments are made by the Order Filler, it issues an
Appointment Notification (Reschedule Bookings) to inform the Order Placer of the change. If
that appointment is cancelled by the Order Filler, it issues an Appointment Notification (Cancel
Bookings) to the Order Placer.
This Departmental Appointment Notification Option allows the Order Placer to remain aware ofany scheduling changes that may be made by the Order Filler, but not to request an appointmentchange. For such a change, it may be necessary to use means not defined in this Integration
Profile (e.g., a phone call to the person entering orders on the Order Filler) that an appointment
booking has to be changed.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerImage
Manager

Department System
Scheduler/ Order Filler

Create Order
Placer Order Mgmt –New [RAD-2]
Appointment Notification New Bookings [RAD-48]

Schedule Procedure Steps
and/or Assign Protocol
Procedure Scheduled[RAD-4]

Appointment Notification –Reschedule Bookings [RAD-48]

Reschedule Procedure
Step(s)Procedure Update[RAD-13]

Appointment Notification Cancel Bookings [RAD-48]

Cancel Procedure orProcedure Steps
Procedure Update[RAD-13]1695

Figure 3.3-13: Departmental Appointment Bookings Process Flow

3.4 Data Model for Scheduled Workflow

1700

This section defines the integrated data model adopted by the IHE Technical Framework for the
HL7 messages and the DICOM Information Object Definitions (IODs). The Entity Relationship(ER) diagram represents the integration of proper subsets of HL7 2.3.1 and the DICOM Modelof the Real World with minor extensions as noted in section 3.4.1 and described in appendix B.
3.4.1 Model of the Real World

1705

Figure 3.3-1 depicts the model of the real world within scope of the Scheduled Workflow
Profile. This model provides an overview of the high-level integration of the DICOM and HL7models. This integrated model differs from the DICOM Model of the Real World (refer to
DICOM 2011 PS 3.3) in the following respects:•

The Service Episode, Procedure Plan and Procedure Type entities have been excluded
and are outside the scope of the IHE Technical Framework•

The relationship between the Visit and Imaging Service Request has been excluded and isoutside the scope of the IHE Technical Framework.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1710

1715

•

The HL7 Placer Order and Filler Order entities have been inserted into the DICOM
hierarchy between the Patient entity and Imaging Service Request entity. IHE requiresthat a single Placer Order shall correspond to one and only one Filler Order.

•

The DICOM Imaging Service Request Entity is equated with the HL7 Filler Order entity.
In this relationship, IHE provides clarification of the use of the Accession Number DICOM attribute (0008,0050); see appendix A for further discussion.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1

0-n
has

Patient

Visit

1
Is thesubject of
0-n
Placer Order1
is fulfilled by1

Filler Order/
Imaging Service
Request

1
has

1-n
0-n

Requested Procedure
1

Results iniscomposedof
1-n1Scheduled
Procedure Step

1-nincludesProtocol Code

0-n

0-n
1

describes

Results in0-m0-mModality Performed
Procedure Step

SeriesBelongs to1

1-n

Instance

Belongs to
1

0-n

Figure 3.4-1: Real World Model for Scheduled Workflow

1720

3.4.2 Scheduled Workflow Concepts in Practice
The IHE “Real World” model for Scheduled Workflow described above offers three major levelsof control that can be used to customize a broad range of specific workflow situations:______________________________________________________________________________
69
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

Order: A request for an Imaging Service•

Requested Procedure: Unit of work resulting in one report with associated codified,billable acts.

•

Scheduled and Performed Procedure Step: the smallest unit of work in the workflowthat is scheduled (work to do) and/or performed (work done).

1725

1730

The Order Filler/Department System Scheduler uses the Universal Service ID in each order thatit receives to determine what specific Requested Procedures are needed, and for each Requested
Procedure the Procedure Steps that need to be scheduled.
A departmental Procedure Plan may be used in the Order Filler Actor to predefine for each oneof the types of Orders that may be requested from the imaging department (generally defined in
the Order Placer) the breakdown in Requested Procedure (with a specific procedure code) andfor each Requested Procedure Code, the breakdown in Scheduled Procedure Steps.

1735

The figure below defines an example of the breakdown of a “rule out pulmonary embolism”
Order.
Order :R/O Pulmonary Embolism
Requested Procedure : Chest X-ray
Scheduled Procedure Step :Chest PA and Lateral
Requested Procedure : NM Ventilation Perfusion
Scheduled Procedure Step :NM Ventilation Acquisition
Scheduled Procedure Step
NM Perfusion Acquisition

1740

In this Procedure Plan, for this specific Order, two Requested Procedures are defined. The Chest
X-ray that will be read and reported by a different radiologist than the NM Ventilation-Perfusion,
hence two different Requested Procedures. The NM Ventilation Perfusion Procedure has beenscheduled as two different Scheduled Procedure Steps, to account for the fact that the patient will
have the two NM acquisitions performed at a different time, thus allowing for patient preparation
between the two examinations. This is the way this institution has decided to handle this Order.
Another Institution may choose to require the same radiologist to read both the X-ray and the______________________________________________________________________________
70
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
1745

NM images. In that case it would define in its Procedure plan for the same Order to have a single
Requested Procedure with three Scheduled Procedure Steps.
Many Orders processed in a Radiology Department would have a simpler breakdown such as thisChest X-ray example.
Order :
Chest X-ray
Requested Procedure : Chest X-ray
Scheduled Procedure Step :Chest PA and Lateral

1750

1755

It should be noted that the three level Order breakdown has been defined in the IHE Scheduled
Workflow so that any type of Orders, from the simple case to the more complex cases may be
handled by the same workflow concepts, thus providing a general approach that can be easily
customized by each imaging department in the definition of its Procedure Plan.
In the IHE Scheduled Workflow, the Accession Number identifies the Order. The requested
Procedure ID distinguishes among Requested Procedures when an Order requires multiple
Procedures. IHE sets a common meaning for these two terms to provide clinicians with aconsistent and non-ambiguous access across different vendor products (RIS, PACS and
Modalities).
3.4.2.1 Tracking Performed Procedure Steps1760

The IHE Scheduled Workflow not only addresses the breakdown of Orders into Requested
Procedures and Scheduled Steps but also allows tracking the Procedure Steps that have actually
been performed. The Performed Procedure Steps may or may not correspond to the Scheduled
Procedure Steps. This provides the flexibility needed to adjust on the Modality if the actual
acquisition differs from what was scheduled.

1765

Using the Pulmonary Embolism example above, one may decide to follow the Order breakdown
as defined in the procedure Plan.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order :R/O Pulmonary Embolism
Requested Procedure : Chest X-ray
Performed Procedure Step :Chest PA and Lateral

Scheduled Procedure Step :Chest PA and Lateral
Requested Procedure : NM Ventilation Perfusion

1770

Scheduled Procedure Step :NM Ventilation Acquisition

Performed Procedure Step :NM Ventilation Acquisition

Scheduled Procedure Step
NM Perfusion Acquisition

Performed Procedure Step
NM Perfusion Acquisition

The Chest X-ray Requested Procedure would contain the series of images associated with the
Chest PA and Lateral Performed Procedure and the NM Ventilation Perfusion would containboth the series for the ventilation and the series of images for the perfusion. From this example
one can see how the Requested Procedure forms the “folder” where the radiologists find theimages to be read resulting from the Scheduled Procedures Steps.
Using the Pulmonary Embolism example above, one may decide that following the Chest X-ray,
it is not necessary to perform the NM Perfusion Ventilation.
Order :R/O Pulmonary Embolism
Requested Procedure : Chest X-ray
Performed Procedure Step :Chest PA and Lateral

Scheduled Procedure Step :Chest PA and Lateral
Requested Procedure : NM Ventilation Perfusion

1775

Scheduled Procedure Step :NM Ventilation Acquisition

Performed Procedure Step :NM Ventilation Acquisition

Scheduled Procedure Step
NM Perfusion Acquisition

Performed Procedure Step
NM Perfusion Acquisition

In this later case, the Nuclear Scheduled Procedure Steps will be cancelled. Only the Chest X-ray
Requested Procedure will “contain” the Image corresponding to the Chest PA and lateral Chest
X-ray.
1780

To illustrate further the capabilities of the IHE Scheduled Workflow, let's look at a
Chest/Abdomen/Pelvis Order that a radiology department chooses to break down into a Chest
Requested Procedure and an Abdomen/Pelvis Requested Procedure in order to take advantage ofthe subspecialties of its radiologists. Some hospitals also may want to produce separate reports toalign with the charging policies.
______________________________________________________________________________
72
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order :CT Chest/Abdomen/Pelvis
Requested Procedure : CT Chest
Scheduled Procedure Step :CT Chest w/o contrast
Requested Procedure : CT Abdomen/Pelvis

Performed Procedure Step :CT Chest/Abdomen/pelvis w/ocontrast

Scheduled Procedure Step :CT Abdomen/ Pelvis w/o contrast

1785

In this example, a single Performed Procedure Step has been performed in response to two
Scheduled Procedure Steps. IHE refers to this as a Group Case (see Volume 2, section 4.6). At
the time of reading, the same series of images produced by this Performed Procedure Step would
be read once in the context of the CT Chest Requested Procedure and again in the context of theAbdomen/Pelvis Requested Procedure.

1790

3.4.2.2 Extending the Scheduled Workflow Concepts to Include Post-Processing
Tasks
The workflow concepts (as described in section 3.4.2.1 above) may be extended to include other
Scheduled Procedure Steps, such as those used to describe post-processing tasks.

1795

Some of the Scheduled Procedure Steps may be Image Post-Processing related. These Scheduled
Procedure Steps would result in Post-Processing Performed Procedure Steps. This is illustrated
by the following example of an MR Brain with a Functional Analysis Post-Processing.
Order :MR Brain Functional Analysis

Requested Procedure : MR Brain Functional Analysis

1800

1805

Scheduled Procedure Step :MR Brain Acquisition

Performed Procedure Step :MR Brain Acquisition

Scheduled Procedure Step
MR Functional Analysis

Performed Procedure Step
MR Functional Analysis

In the above example, two different Scheduled Procedure Steps have been defined for theRequested Procedure. This reflects the fact that in this radiology department, the functional
analysis post-processing is not performed by the MR Technologist, but by the Radiologist andtherefore needs to be independently scheduled on an independent workstation. Anotherdepartment may well choose to have the Technologist perform the post-processing immediately
after the MR acquisition (either on the MR itself or on a co-located workstation). In that case theRequested Procedure would include a single Scheduled Procedure Step that includes both theacquisition and the post-processing task.
______________________________________________________________________________
73
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
This Section does not provide an exhaustive description of all the workflow cases supported by
the IHE Scheduled Workflow Profile, nor does it describe the Workflow enabled by other IHE
Integration Profiles such as the Presentation of Grouped Procedures, Post-Processing Workflow
and Reporting Workflow.
1810

3.4.3 Scheduled Workflow Information Model
The Scheduled Workflow Model is represented in this section as an Entity Relationship (ER)diagram. The Scheduled Workflow Model is based on the DICOM and HL7 standards. The keys
relating the entities and the unique keys of each entity are defined and the cardinality of theentities is indicated.

1815

An example of the conventions used to specify an entity’s relationships is presented in Figure
3.4-2

1
N
Entity Name
Foreign Key (FK) relating this entity to previous - The FK is shown to clarify the ER diagram and notintended to represent a relational model.
Unique Key (U) for this entity. There are cases where Unique keys that are identical within the scope of
this document have different contextual meanings, as defined in this document. The "+" symbol
indicates two attributes must be combined to guarantee uniqueness.

Figure 3.4-2: Example of the Entity Relationship Diagram

1820
Figures 3.4-3 and 3-4.4 present the overview of the IHE Information Model. Mappings between
specific HL7 Elements and DICOM Attributes are identified in Volume 2, Appendix B.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Patient

10-nPatient ID + Issuer of Patient ID

1
Visit

0-n
Patient ID + Issuer of Patient ID

Placer Order

Visit Number

Patient ID + Issuer of Patient ID
Placer Order Number + Issuer of Placer Order Number

1
1Filler Order / Imaging Service Request
Placer Order Number + Issuer of Placer Order Number
Filler Order Number + Issuer of Filler Order Number
Accession Number

11-n*Requested Procedure*The Order Filler can expandthat single order into multiple
Requested Procedures. See
Volume II, Section 4.4 for moredetails.

Filler Order Number + Issuer of Filler Order Number
Accession Number
Study Instance UID
Requested Procedure ID

1825

To Modality
rformed Procedure
Step Entity

To Scheduled
Procedure Step

Figure 3.4-3: Schedule Workflow Information Model______________________________________________________________________________
75
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

From Requested Procedure Step
1

1-n
Scheduled Procedure Step
Requested Procedure ID
Study Instance UID
Scheduled Procedure Step ID

0-n**

0-n**

0-m**
0-m**

Modality Performed Procedure Step
Scheduled Procedure Step ID
Study Instance UID
Performed Procedure Step UID***
Affected SOP Instance UID

11-n**See Volume II, Section 4.6 fora thorough description of the
cardinality relationship optionsof Modality Performed
Procedure Step.
***The Performed Procedure
Step UID is present as theAffected SOP Instance UID.

SeriesPerformed Procedure Step UID***
Series Instance UID

10-n
DICOM Instance
Series Instance UID
SOP Instance UID

1830
Figure 3.4-4: Schedule Workflow Information Model, continued______________________________________________________________________________
76
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4 Patient Information Reconciliation (PIR)
1835

1840

1845

The Patient Information Reconciliation Integration Profile extends the Scheduled Workflow
and the Reporting Workflow Integration Profile by offering the means to match images,
diagnostic reports, and other evidence objects acquired for a misidentified or unidentified patient(for example, during a trauma case) with the patient’s record. In the example of the trauma case,this integration profile allows subsequent reconciliation of the patient record with images that are
acquired (either without a prior registration or under a generic registration) before the patient’s
identity can be determined. Thus images can be acquired and interpreted immediately and later,when the patient’s official registration and order information is entered into the ADT, Order
Placer and Order Filler Systems, this information is matched with the acquired image set andreports, greatly simplifying these exception handling situations. In addition, this Integration
Profile allows the Image Manager and Report Manager to receive patient update messages tomaintain consistency of the patient information. The Image Manager and Report Manager do notreceive those transactions in the Scheduled Workflow Integration Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4.1 Actors/Transactions
1850

Figure 4.1-1 diagrams the actors involved with this profile and the transactions between actors.
The shaded actors are NOT actually included in this profile but are included to show the otherendpoint of transactions that ARE part of the profile (e.g., Query Reporting Worklist, Query/
Retrieve Reports and Query/ Retrieve Images). As a result, the shaded actors are not listed inTable 4.1-1.
ADT→ Patient Update [RAD-12]

Order Placer

Patient Update [RAD-12] ↓DSS/ Order Filler↓ Patient Update [RAD-12]↓ Procedure Update [RAD-13]↑ Modality PS in Progress [RAD-6]↑ Modality PS Completed [RAD-7]↓Images Availability Query [RAD-11]↓ Patient Update [RAD-12]↓ Procedure Update [RAD-13]

ReportManager↑ Query Reporting Worklist [RAD-46]↑ Query Reports [RAD-26]↑ Retrieve Reports [RAD-27]

Performed
Procedure
Step
Manager

Report Creator/
Report Reader
Image
Manager→ Modality PS in Progress [RAD-6]→ Modality PS Completed [RAD-7]

Image
Archive

Query Images [RAD-14] ↑Retrieve Images [RAD-16] ↑Image
Display← Modality PS in Progress [RAD-6]← Modality PS Completed [RAD-7]
Acquisition Modality← Query Modality Worklist [RAD-5]

1855

Figure 4.1-1: Patient Information Reconciliation Diagram______________________________________________________________________________
78
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1860

Table 4.1-1 lists the transactions for each actor directly involved in the Patient Information
Reconciliation Integration Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). Transactions labeled “O”
are optional. A complete list of options defined by this Integration Profile that implementations
may choose to support is listed in Volume 1, Section 4.2.
Table 4.1-1: Patient Information Reconciliation - Actors and Transactions
Actors

Optionality

Vol. 2/3
Section

ADT Patient Registration

Patient Update [RAD-12]

R

4.12

Order Placer

Patient Update [RAD-12]

R

4.12

Department System Scheduler/
Order Filler

Patient Update [RAD-12]

R

4.12

Procedure Update [RAD-13]

R

4.13

Acquisition Modality

Image Manager/
Image Archive

Performed Procedure Step
Manager

Report Manager (optionallygrouped with a Report
Repository)

1865

Transactions

Query Modality Worklist [RAD-5]

R

4.5

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]

R

4.7

Images Availability Query [RAD-11]

O

4.11

Query Modality Worklist [RAD-5]

R

4.5

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]

R

4.7

Patient Update [RAD-12]

R

4.12

Procedure Update [RAD-13]

R

4.13

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Query Images [RAD-14]

R

4.16

Retrieve Images [RAD-16]

R

4.16

Images Availability Query [RAD-11]

R

4.11

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7]

R

4.7

Patient Update [RAD-12]

R

4.12

Procedure Update [RAD-13]

R

4.13

Query Report [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Query Reporting Worklist [RAD-46]

R

4.46

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Note that this is an enhancing profile. Actors must perform reconciliation for all other profiles
they support.

1870

1875

1880

1885

Where the actor entry in the table refers to another integration profile (e.g., Scheduled
Workflow), all required transactions in the referenced profile for that actor must be implemented.
Some of these transactions in the referenced integration profile (for example the Department
System Scheduler responsibilities in the Patient Update transaction) are extended as specified inVolume 2 and Volume 3.
To support the Patient Information Reconciliation Profile, an actor that claims support of othercontent profiles (Consistent Presentation of Images, Key Image Notes, Simple Image & Numeric
Reports or Evidence Documents) is required to support reconciliation of the relevant Evidence
Objects. The following diagrams will mostly show the management/ reconciliation of images.
The Report Manager must update existing workitems based on the patient information update but
since the report content is not modified the rest of the reporting workflow is not affected. In otherwords, no additional reporting workitems will be scheduled or cancelled because of this update.
The report status is also not affected e.g., a verified report in which the patient information has
been updated remains verified. This profile does not require notification of other actors about thepatient update.
In case of DICOM SR, the patient information might be included in the content sequence. The
update of the patient information in the report header might result in inconsistent header
information with the report content. The patient information update shall not create a new SR
SOP instance, according to DICOM SR SOP Class behavior as described in DICOM PS 3.4,
Annex O.

4.2 Patient Information Reconciliation Integration Profile Options
1890

Options that may be selected for this Integration Profile are listed in the Table 4.2-1 along with
the Actors to which they apply.
Table 4.2-1: Patient Information Reconciliation – Actors and Options
OptionsVol. & Section

ADT Patient Registration

Actor

HL7 v2.5.1

RAD TF-1:4.2.1
RAD TF-2:4.12

Order Placer

HL7 v2.5.1

RAD TF-1:4.2.1
RAD TF-2:4.12

DSS/Order Filler

HL7 v2.5.1

RAD TF-1:4.2.1
RAD TF-2:4.12
RAD TF-2:4.13

Acquisition Modality
Image Manager/ Image Archive

MPPS Manager

No options defined
HL7 v2.5.1

RAD TF-1:4.2.1
RAD TF-2:4.12
RAD TF-2:4.13

No options defined-______________________________________________________________________________
80
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Actor
Report Manager

OptionsVol. & Section

HL7 v2.5.1

RAD TF-1:4.2.1
RAD TF-2:4.12
RAD TF-2:4.13

4.2.1 HL7 v2.5.1 Option
1895

1900

The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in thetransactions referenced in Table 4.2-1. The actor shall permit configuration for each system thatit communicates with using the referenced transactions whether HL7 v2.3.1 or HL7 v2.5.1 isused. It is possible that the actor may receive HL7 v2.3.1 messages and send HL7 v2.5.1
messages or vice versa.
The specifications in the HL7 v2.5.1 Option maintain semantic equivalency with HL7 v2.3.1
implementations and the field correspondences are summarized in RAD TF-2 Appendix E.

4.3 Unidentified Patient Image Acquisition and Reconciliation

1905

1910

1915

1920

1925

This section describes the general process flow related to the handling of procedures forunidentified patients. The transactions covered are Patient Registration [RAD-1], Placer OrderManagement [RAD-2], Procedure Scheduled [RAD-4], MWL Provided [RAD-5], Modality
Procedure Step In Progress [RAD-6], Modality Procedure Step Completed/Discontinued [RAD7], Patient Update [RAD-12], and Procedure Update [RAD-13].
The Unidentified Patient case covers the trauma case or emergency room patient when apatient’s condition requires that a procedure be conducted immediately. This is done before
proper patient registration, ordering and/or scheduling of the procedure are performed (due to thelack of either information or time or other deviation from the normal process flow). In this casepatient/study information must be later reconciled and properly updated at the ADT, Order
Placer, Department System Scheduler/Order Filler, Image Manager and Report Manager. There
are several examples of information flow in this case. These examples are described in use cases(see sections 4.4.1 – 4.4.5 for details):•

Case 1: Unidentified Patient registered at ADT and ordered at Order Placer.

•

Case 2: Unidentified Patient registered at ADT and ordered at Department System
Scheduler/Order Filler.

•

Case 3: Unidentified Patient registered at ADT but acquisition completed at Modality
prior to order.

In cases 1, 2, and 3, the ADT may utilize the Master Patient Index (MPI) internally. Theinteraction of the ADT with MPI to resolve the patient information to the correct Patient ID may
be embedded in the process of patient information reconciliation within the ADT role. The IHE
Technical Framework in future years may define patient reconciliation transactions using MPI.
The IHE Technical Framework also supports cases when registration or temporary registration ofa patient by ADT is not applicable or desired, for example:______________________________________________________________________________
81
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

Emergency Department patient can be identified but, due to time or system availability
constraints the procedure must be performed before proper order entry and scheduling
may occur.

•

Patient ID, though valid, has never been propagated to all actors due to communication
failures, or the wrong patient record was used in ordering/scheduling.

•

Patient ID, though valid, has been mistyped at the modality.

•

Patient cannot be registered at the ADT by the time of the procedure. The patient presents
to the Order Filler Actor (Imaging Department) and the order is placed and performed in
the department.

1930

1935

The following additional use cases are identified (see sections 4.4.4 and 4.4.5):•

Case 4: Unidentified Patient assigned temporary Departmental ID and scheduled at
Department System Scheduler/Order Filler.

•

Case 5: Image Acquisition completed without scheduling at Department System
Scheduler/Order Filler.

1940

Cases 4 and 5 require patient reconciliation on the department level. In the case of procedures
performed on the unidentified patient in multiple departments (e.g., Radiology and Laboratory),
this will require reconciliation of patient information in multiple locations. To address this issue,
the IHE Technical Framework in future years may define patient reconciliation transactions
using Master Patient Index (MPI).

1945

The IHE Technical Framework also recognizes that the following 4-step case of handlingunidentified patients may be utilized in certain installations:

1950

1955

1960

1. The patient is delivered to the department, where a temporary departmental Patient ID and/or
name are assigned.
2. The order is then entered by the Department System Scheduler/Order Filler and with thisPatient ID and/or name, and the procedure is performed on the Acquisition Modality.
3. The Department System Scheduler/Order Filler sends a new order transaction to the Order
Placer. This departmental Patient ID is shared by the Image Manager, Department System
Scheduler/Order Filler and Order Placer. However, this departmental Patient ID is not known
to the ADT.
4. After resolution of the patient identity, the ADT registers/admits the patient with the correct
Patient ID and sends a message to the Order Placer and Department System Scheduler/Order
Filler. Each system locally merges the new record with the existing one identified by thedepartmental Patient ID.
Because this case requires reconciliation at multiple points throughout the enterprise, IHE does
not recommend this workflow.
4.3.1 Patient Information Reconciliation during Image Acquisition
This section describes the general process flow related to the handling of procedures for image
acquisition ongoing during patient reconciliation. The transactions covered are Patient______________________________________________________________________________
82
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

1965

1970

1975

Registration [RAD-1], Placer Order Management [RAD-2], Procedure Scheduled [RAD-4],
MWL Provided [RAD-5], Modality Procedure Step In Progress [RAD-6], Modality Procedure
Step Completed/Discontinued [RAD-7], Patient Update [RAD-12], Procedure Update [RAD-13],
Query Images [RAD-14], Query Presentation States [RAD-15], Retrieve Images [RAD-16] andRetrieve Presentation States [RAD-17].
When a Patient Update occurs, in addition to the information exchange between the ADT, Order
Placer and Department System Scheduler/Order Filler, Patient Update information is also sent to
the Image Manager. Even after a Patient Update has occurred images coming from the Modality
may continue to use the original Patient Information, so on-going Patient update with incoming
images from the modality may be necessary. It is the responsibility of the Image Manager toensure that the patient information is updated in the images, Grayscale Softcopy Presentation
States and other Evidence Objects when they are retrieved from the Image Archive. This
example is described in use case 6 (see section 4.4.6).

4.4 Use Cases
The following sections describe the Unidentified Patient use cases. For the purpose of
simplification, the following transactions were omitted from the corresponding diagrams:
1980

1985

•

Modality Performed Procedure Step In Progress [RAD-6]•

Modality Images Stored [RAD-8]•

Modality Presentation State Stored [RAD-9]•

Storage Commitment [RAD-10]

These transactions may occur within the time frame of the diagram, but their content does notaffect each of the use cases.
4.4.1 Case 1: Unidentified Patient Registered at ADT and Ordered at the Order
Placer

1990

1995

The ADT is a single point of patient reconciliation in the enterprise. Process flow requires thatany unidentified patient be assigned a permanent Patient ID and a temporary name (e.g., “John
Doe”). All subsequent transactions follow the normal flow (see section 3.1) including order entry
and procedure scheduling. When the real patient identity is known, the ADT is responsible forreconciliation of its own records as well as informing the Order Placer and Department System
Scheduler/Order Filler about corresponding changes. The ADT sends a Patient Update message
to both the Order Placer and Department System Scheduler/Order Filler. The Department System
Scheduler/Order Filler sends the Patient Update message to the Image Manager and the ReportManager.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager

ReportManager

Acquisition
Modality

Register J.Doe
Patient
Registration [RAD-1]
Placer OrderManagement –New [RAD-2]
Schedule Procedure
ImagesAcquired

Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]

Modality Procedure Step
Completed [RAD-7]

Patient Reconciliation

Modality Procedure Step
Completed [RAD-7]

J.Doe -> J.Smith
Patient Update/
Merge [RAD-12]

Patient Update/
Merge [RAD-12]
Patient Update/ Merge [RAD-12]

Figure 4.4-1: Unidentified Patient– Case 1

Significant Transactions:
2000

2005

•

To reconcile the patient information, the ADT may register a new patient and merge thetemporary patient with the correct patient and send both Patient Registration [RAD-1]
and Patient Update [RAD-12] (Merge) transactions.

•

If a permanent Patient ID was assigned, then the ADT may only send a Patient Update[RAD-12] transaction with proper information.

Note that the Performed Procedure Step Manager is not shown on the Process Flow diagrams
and is presumed to be grouped with the Image Manager. It may be grouped with the Department
System Scheduler/Order Filler with corresponding changes in the flow of PPS relatedtransactions between the Image Manager and Department System Scheduler/Order Filler.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2010

2015

4.4.2 Case 2: Unidentified Patient Registered at ADT and Ordered at Department
System Scheduler/Order Filler
This case is based on case 1. However, in this situation the order for a procedure is generated by
the Department System Scheduler/Order Filler and submitted to the Order Placer. Procedures arescheduled normally and image acquisition uses modality worklist. When the patient informationis reconciled, the ADT sends the Patient Update messages to both the Order Placer and
Department System Scheduler/Order Filler. The Department System Scheduler/Order Filler
sends the Patient Update message to the Image Manager and the Report Manager.
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager

ReportManager

Acquisition
Modality

Register J.Doe
Patient Registration[RAD-1]

Filler OrderManagement –New [RAD-3]

Schedule Procedure

Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]

Modality Procedure Step
Completed [RAD-7]

Patient Reconciliation
J.Doe -> J.Smith

ImagesAcquired

Modality Procedure Step
Completed [RAD-7]

Patient Update/
Merge [RAD-12]

Patient Update/
Merge [RAD-12]

Patient Update/ Merge [12]Figure 4.4-2: Unidentified Patient– Case 22020

Significant Transactions:•

To reconcile the patient information, the ADT may register a new patient and merge thetemporary patient with the correct patient and send both registration and mergetransactions.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

If a permanent Patient ID was assigned, then the ADT may only send a Patient Update
transaction with proper information.

•

A Filler Order Management (New Order) transaction [RAD-3] is sent from Department
System Scheduler/Order Filler to the Order Placer.

2025

4.4.3 Case 3: Unidentified Patient Registered at ADT but Completed at Modality
Prior to Order
2030

2035

As in cases 1 and 2, this uses a permanent Patient ID generated by the ADT. However, no order
entry or scheduling takes place before the Acquisition Modality performs the procedure. A
permanent Patient ID and a temporary name are manually entered at the Acquisition Modality(typically, from a card) and conveyed to the Department System Scheduler/Order Filler and theImage Manager by the Acquisition Modality. Subsequently, the Department System
Scheduler/Order Filler generates and submits an order to the Order Placer. When the patient
information is reconciled, the ADT sends the Patient Update messages to both the Order Placer
and the Department System Scheduler/Order Filler. The Department System Scheduler/Order
Filler sends a Patient Update message to the Image Manager and the Report Manager.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager

ReportManager

Acquisition
Modality

Register J.Doe
ImagesAcquiredPatient Registration[RAD-1]Modality Procedure Step
Completed [RAD-7]
Filler OrderManagement –New [RAD-3]

Modality Procedure Step
Completed [RAD-7]

New Order

Procedure
Scheduled [RAD-4]
Patient Reconciliation
J.Doe -> J.Smith
Patient Update/
Merge [RAD-12]

Patient Update/
Merge [RAD-12]

Patient Update/ Merge [RAD-12]

2040

Figure 4.4-3: Unidentified Patient– Case 3

Significant Transactions:•

On receiving a Modality Procedure Step Completed [RAD-7], the Department System
Scheduler/Order Filler recognizes it as an unscheduled case.

•

The Department System Scheduler/Order Filler sends a Filler Order Management (New
Order) transaction [RAD-3] to the Order Placer.

•

Using the information from the Procedure Step Completed transaction and the placedorder, the DSS/Order Filler creates a new Requested Procedure record and sends a
Procedure Scheduled transaction to the Image Manager.

•

To reconcile the patient information, the ADT may register a new patient and merge thetemporary patient with the correct patient and send both registration and mergetransactions.

2045

2050

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

If a permanent Patient ID was assigned, then the ADT may only send a Patient Update
transaction with proper information.

•

The DSS/Order Filler sends a Patient Update transaction to the Image Manager.

2055

4.4.4 Case 4: Unidentified Patient Assigned Temporary Departmental ID and
Scheduled at DSS/Order Filler
2060

In this case, no valid Patient ID is available to the Department System Scheduler/Order Filler. It
assigns a temporary Patient ID and a temporary name and schedules the required procedure.
Note:

2065

2070

The Department System Scheduler/Order Filler must ensure that the assigned temporary Patient ID is unique
within its scope.

The temporary Patient ID is conveyed to the Image Manager. When patient information becomes
known, the ADT sends new patient information to both the Order Placer and the Department
System Scheduler/Order Filler. The Department System Scheduler/Order Filler reconciles
received patient information with that associated with the temporary Patient ID and merges thepermanent patient record with its own temporary one and sends a Patient Update transaction to
the Image Manager and the Report Manager. At the same time, the Department System
Scheduler/Order Filler generates and submits an order to the Order Placer using a permanent
Patient ID.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/
Order Filler

Order
PlacerADT

ImageManager

ReportManager

Acquisition
Modality

Schedule
Procedure

Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]

ImagesAcquired

Modality Procedure Step
Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]
Register J.Smith

Patient
Reconciliation

Patient Registration[RAD-1]

Patient Update/
Merge [RAD-12]
Filler OrderManagement New [RAD-3]

Patient Update/ Merge [RAD-12]

Procedure Update[RAD-13]

Figure 4.4-4: Unidentified Patient– Case 4

Significant Transactions:•Patient information is reconciled internally by the Department System Scheduler/Order
Filler using the Patient Registration from ADT.

•The Department System Scheduler/Order Filler sends the Patient Update [RAD-12]
transaction to the Image Manager.

•

The Department System Scheduler/Order Filler sends the Filler Order Management (New
Order) transaction [RAD-3] to the Order Placer.

2075

2080

4.4.5 Case 5: Image Acquisition Completed Without Scheduling at Department
System Scheduler/Order Filler
In this case, no valid Patient ID is available to the Department System Scheduler/Order Filler andno scheduling is done before the procedure is performed. A temporary ID and name are enteredby the technologist at the Modality and conveyed to the Department System Scheduler/Order______________________________________________________________________________
89
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2085

2090

2095

Filler and to the Image Manager. The Patient ID and name are selected by the technologist
according to the locally defined rules; for example, selected from the predefined pool of “Patient
ID–patient name” pairs. The rules for selecting temporary Patient ID shall guarantee its
uniqueness within the scope of Department System Scheduler/Order Filler.
Upon receiving the Modality Procedure Step Completed message, the DSS/Order Filler andImage Manager recognize an unscheduled case based on the content of the message (absent or
empty Referenced Study Sequence, see RAD TF-2, Appendix A). When patient information
becomes known, the ADT sends the new patient information to both the Order Placer and
Department System Scheduler/Order Filler. The Department System Scheduler/Order Filler
performs a merge of the permanent patient record with the temporary one and sends a Patient
Update to the Image Manager and the Report Manager. At the same time, Department System
Scheduler/Order Filler generates and submits an order to the Order Placer using a valid PatientID.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

ADT

Department System
Scheduler/ Order
Filler

Order
PlacerImage
Manager

Acquisition Report
Modality Manager
ImagesAcquired

Modality Procedure Step
Completed [RAD-7]
Register J.Smith
Patient
Reconciliation

Patient Registration[RAD-1]Modality
Procedure
Step
Completed[RAD-7]

Patient Update/
Merge [RAD-12]
Patient Update/
Merge [RAD-12]

Filler OrderManagement –New [RAD-3]
Procedure
Scheduled [RAD-4]

2100

Figure 4.4-5: Unidentified Patient – Case 5

Significant Transactions:•

On receiving a Procedure Step Completed transaction, the Department System
Scheduler/Order Filler recognizes it as an unscheduled case.

•

Patient information is reconciled internally by the Department System Scheduler/Order
Filler using the Patient Registration from the ADT.

•The Department System Scheduler/Order Filler sends a Patient Update (Merge)transaction to the Image Manager and to the Report Manager.

2105______________________________________________________________________________
91
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2110

•

The Department System Scheduler/Order Filler sends a Filler Order Management (New
Order) transaction [RAD-3] to the Order Placer.

•

Using the information from the Procedure Step Completed transaction and placed order,
the Department System Scheduler/Order Filler creates a new Requested Procedure recordand sends a Procedure Scheduled [RAD-4] transaction to the Image Manager and ReportManager.

4.4.6 Case 6: Patient Information Reconciliation During Image Acquisition
2115

Updates may need to occur after the initial Patient Registration and Order Placement has
occurred. The Modality may have requested information from the Department System Scheduler
before the update has occurred and continue to send the images with the original Patient
Registration and Order information. The Image Manager will need to continue updating thepatient information from items retrieved from the Image Archive.

2120
Significant Transactions:

2125

•

The Modality may continue to send information using the original patient informationeven after the patient update has occurred.

•

The Image Manager must continue reconciling Patient Information even after the Patient
Update transaction has been completed.

Only partial transactions are shown. Other transactions are performed according to the profile
requirements.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Order
PlacerADT

Department System
Scheduler/ Order Filler

Image Manager/
Image
Archive

Acquisition
Modality

Query Modality Worklist [RAD-5]

Modality Procedure Step
Completed [RAD-7]
ModifyPatient
Patient Update Merge [RAD-12]

Perform
Acquisition
Modality Procedure Step
Completed [RAD-7]
Modality Images
Stored [RAD-8]

Patient Update/
Merge [RAD-12]
Perform
Patient
Reconciliation

Modality Procedure Step
Completed [RAD-7]
Original Patient Data

Modality Procedure Step
Completed [RAD-7]
Original Patient Data

Perform
Acquisition(Append)Modality Images
Stored [RAD-8]

Perform
Patient
Reconciliation

Figure 4.4-6: Patient Information Reconciliation During Image Acquisition

2130______________________________________________________________________________
93
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5 Consistent Presentation of Images (CPI)

2135

2140

2145

The Consistent Presentation of Images Integration Profile specifies a number of transactions
that maintain the consistency of presentation for grayscale images. The presentation of images
depends upon the contrast/brightness and the spatial and graphical operations applied, such as
user annotations, shutters, flip/rotate, display area selection, and zoom. The spatial and graphicaloperations are defined in the Grayscale Softcopy Presentation State. For the consistency of theperceived pixel intensity a standard contrast curve, the Grayscale Standard Display Function, hasbeen defined against which different types of display and hardcopy output devices are calibrated.
This profile is intended to establish consistency between any combination of softcopy andhardcopy displays. In order to guarantee both grayscale contrast/brightness consistency andspatial/ graphical consistency in presentation of images it is required that both the Grayscale
Standard Display Function and the Grayscale Softcopy Presentation State are supported.
Note that this Integration Profiles applies only to grayscale images, and is not applicable forcolor images.
The Scheduled Workflow Profile or Post-Processing Profile, when combined with this profile,allows the process of creating, storing and accessing Presentation States to be managed using
worklist to provide the relevant patient and procedure details; and using performed procedure
steps to provide status information.

2150

5.1 Actors/Transactions
Figure 5.1-1 diagrams the actors involved with this profile and the transactions between actors.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Image Display

Evidence Creator↓ Creator Image Stored [RAD-18]↓ Creator Pres. State Stored [RAD-19]↓ Query Images [RAD-14]↓ Retrieve Images [RAD-16]

Storage Commitment [RAD-10] ↓Image
Manager

Storage Commitment [RAD-10] ↓↓ Query Images [RAD-14]↓ Query Pres. States [RAD-15]↓ Retrieve Images [RAD-16]↓ Retrieve Pres. States [RAD-17]

Image
Archive↑ Modality Image Stored [RAD-8]↑ Modality Pres. State Stored [RAD-9]

Acquisition Modality
Print Composer
Print Request with Presentation LUT[RAD-23] ↓Print Server

Figure 5.1-1: Consistent Presentation of Images Diagram

2155

Table 5.1-1 lists the transactions for each actor directly involved in the Consistent Presentationof Images Integration Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). Transactions labeled “O”
are optional. For a complete list of options defined by this Integration Profile and that
implementations may choose to support are listed in Section 5.2.

2160
Table 5.1-1: Consistent Presentation of Images - Actors and Transactions
ActorsAcquisition Modality

Image Manager/
Image Archive

Transactions
Modality Images Stored [RAD-8]

Optionality

Vol. 2/3
SectionR

4.8

Storage Commitment [RAD-10]

R

4.10

Modality Presentation State Stored[RAD-9]R

4.9Modality Images Stored [RAD-8]

R

4.8

Storage Commitment [RAD-10]

R

4.10

Query Images [RAD-14]

R

4.14

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsImage Display

Evidence Creator

Transactions

Optionality

Vol. 2/3
SectionRetrieve Images [RAD-16]

R

4.16

Creator Images Stored [RAD-18]

R

4.18

Modality Presentation State Stored[RAD-9]R

4.9

Query Presentation States [RAD-15]

R

4.15

Retrieve Presentation States [RAD-17]

R

4.17

Creator Presentation State Stored[RAD-19]

R

4.19

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Query Presentation States [RAD-15]

R

4.15

Retrieve Presentation States [RAD-17]

R

4.17

Creator Images Stored [RAD-18]

O

4.18

Creator Presentation State Stored[RAD-19]

R

4.19

Storage Commitment [RAD-10]

R

4.10

Query Images [RAD-14]

O

4.14

Retrieve Images [RAD-16]

O

4.16

Print Composer

Print Request with Presentation LUT[RAD-23]

R

4.23

Print Server

Print Request with Presentation LUT[RAD-23]

R

4.23

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

5.2 Consistent Presentation of Images Integration Profile Options
2165

Options that may be selected for this Integration Profile are listed in the Table 5.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 5.2-1: Consistent Presentation of Images – Actors and Options
Actor
Acquisition Modality

OptionsVol. & Section

No options defined-

Image Manager/ Image Archive

No options defined-

Image Display

No options defined-

Evidence Creator

No options defined-

Print Composer

User Specifiable Lighting Condition

Print Server

No options defined

RAD TF-2: 4.23.4.2.4-______________________________________________________________________________
96
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5.3 Consistent Presentation of Images Process Flow
2170

2175

2180

This section describes the typical process flow related to viewing images with Grayscale
Softcopy Presentation States and performing image post-processing that may generate newimages and/or Grayscale Softcopy Presentation States. The transactions covered are RAD-14
through RAD-22.
Consistent Presentation of Images is an integration feature that provides access to images with
their full-fidelity content as they were acquired or created. Such access is available either:•

Internally to the source imaging department;•

Between imaging departments (e.g., Cardiology and Radiology); or•

Throughout the Healthcare Enterprise to other departments or care providers other thanan imaging department (e.g., Surgery, Neurology, Oncology).

Consistent Presentation of Images enables advanced review as well as simple or sophisticatedpost-processing of images along with related objects (such as Grayscale Softcopy Presentation
States, or Structured Reports) in a variety of clinical scenarios. Examples include the following:•

Based on patient identifying information, a clinician wishes to look for imaging studies
performed on this patient. The clinician may access one or more series of images, related
to a recent examination;•

A reading physician performing a primary or secondary read wishes to retain viewing
parameters including clinical annotations;•

A clinician reviewing a report that references key images wishes to review those images;•

A technologist about to perform an imaging examination wishes to retrieve a priorimaging examination to ensure consistent patient positioning;•

A reading physician interpreting a study wishes to perform a comparison with images
acquired in a prior study. The physician also needs to review the images as they were
presented when a prior diagnosis was prepared; and•A surgeon creates a 3D volume analysis of an image set to plan surgery on a patient.

2185

2190

2195

2200

The appearance of grayscale images displayed on different types of softcopy display devices orprinted by different types of hardcopy output devices has often been inconsistent. To address thisproblem and achieve consistent presentation of grayscale images the DICOM Standard defines:•

A standard curve, the Grayscale Standard Display Function, against which different typesof display and hardcopy output devices should be calibrated;•

Basic Print Management with Presentation Look Up Table, for controlling the consistentappearance of preformatted images on printed output;•

Grayscale Softcopy Presentation State, an object for storing and communicating theparameters that describe how an image or set of images shall be displayed. A Grayscale
Softcopy Presentation State object contains references to the images it applies to, and the______________________________________________________________________________
97
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2205

transformations (grayscale transformations, shutter transformations, image annotation,
spatial transformations, and display area annotation) that shall be applied when theimages are presented on a softcopy display.
The typical use of these capabilities is depicted in Figure 5.3-1.
Evidence
Creator

Image
Display
Print
Composer

Print
ServerImage
Manager/
Image Archive

PPS
Manager

Query Presentation States [RAD-15]

Retrieve Presentation States [RAD-17]

Retrieve Images [RAD-16]

View Images
with GSPS
Creator Procedure Step In Progress [RAD-20]
Creator Procedure
Step In Progress [RAD-20]

Image and/or
GSPS Creation
Creator Images Stored [RAD-18]
Creator Presentation State Stored [RAD-19]
Print Request
with Presentation LUT [RAD-23]
Creator Procedure Step Completed [RAD-21]

Creator Procedure
Step Completed [RAD-21]

Storage Commitment [RAD-10]

2210
Figure 5.3-1: Consistent Presentation of Images Process Flow______________________________________________________________________________
98
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
The following shall be taken into account in relation to the presented example of the Consistent
Presentation of Images Process Flow:•

The Evidence Creator Actor shall be grouped with an Image Display Actor but is shown
separately in the diagram above to distinguish the transactions;•

In this example, the Print Composer is grouped with the Evidence Creator, but may begrouped with other actors that have access to images;•

The diagram above includes Procedure Step transactions which are not part of thisprofile, but are defined the associated workflow profile. The diagram shows one
particular sequencing of the Procedure Step Completed transaction. This transaction may
occur at any point after image and/or Presentation State (GSPS) creation. This means it
can occur before images and/or GSPS are stored, after storage, after printing as in thisexample, or even after storage commitment. The IHE Technical Framework does not
specify the timing of this transaction in relation to other transactions.

2215

2220

2225

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6 Presentation of Grouped Procedures (PGP)

2230

2235

The Presentation of Grouped Procedures Integration Profile (PGP) addresses what issometimes referred to as the linked studies problem: viewing image subsets resulting from asingle acquisition with each image subset related to a different requested procedure (e.g., CT
chest, abdomen and pelvis). It provides a mechanism for facilitating workflow when viewing
images and reporting on individual requested procedures that an operator has grouped (often forthe sake of acquisition efficiency and patient comfort). A single acquired image set is produced,
but the combined use of the scheduled workflow transactions and the consistent presentation ofimages allows separate viewing and interpretation of the image subsets related to each of therequested procedures.

6.1 Actors/Transactions
Figure 6.1-1 diagrams the actors involved with this profile and the transactions between actors.

DSS/ Order Filler↑ Modality PS in Progress [RAD-6]↑ Modality PS Completed [RAD-7]

Performed
Procedure
Step Manager
Image
Manager

Image
Archive→ Modality PS in Progress [RAD-6]→ Modality PS Completed [RAD-7]↑ Modality Pres. State Stored[RAD-9]← Modality PS in Progress [RAD-6]← Modality PS Completed [RAD-7]
Acquisition Modality

Figure 6.1-1: Presentation of Grouped Procedures Diagram2240______________________________________________________________________________
100
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2245

Table 6-1 lists the required transactions for each actor directly involved in the Presentation ofGrouped Procedures (PGP) Integration Profile. In order to claim support of this Integration
Profile, an implementation must perform the required transactions (labeled “R”). Transactions
labeled “O” are optional. A complete list of options defined by this Integration Profile and that
implementations may choose to support is listed in Volume 1, Section 6.2.
Table 6.1-1: Presentation of Grouped Procedures - Actors and Transactions
ActorsTransactions

Optionality

Department System Scheduler/
Order Filler

Modality Procedure Step In Progress[RAD-6] (note 1)

R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Modality Procedure Step In Progress[RAD-6] (note 1)

R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Modality Presentation State Stored[RAD-9]R

4.9Modality Procedure Step In Progress[RAD-6] (note 1)

R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Modality Presentation State Stored[RAD-9]R

4.9Modality Procedure Step In Progress[RAD-6] (note 1)

R

4.6

Modality Procedure Step Completed[RAD-7]R

4.7

Acquisition Modality

Image Manager/
Image Archive

Performed Procedure Step
ManagerVol. 2/3
SectionRefer to Table 2-1 for other profiles that may be pre-requisites for this profile.

2250

2255

Note 1: This transaction has an extension that is required by this actor in this profile. This detailed definition of thisextension is in Volume 2, section 4.6.4.1.2.3.6.
Note: The use of the integration capabilities offered by the IHE PGP Integration Profile (enabled by the Modality procedure
Step In Progress/Completed and the Modality Presentation State Stored) requires an Image Display to be
integrated with other workflow-aware actors. Such actors may be an Image Manager/Archive or Department
System Scheduler/Order Filler. A stand-alone Image Display cannot directly benefit from the PGP Integration
Profile capabilities. However, if the stand-alone Image Display supports the Consistent Presentation of Images
Integration Profile, it may benefit from the Presentation States generated by the Acquisition Modality
implementing the PGP Integration Profile.

6.2 Presentation of Grouped Procedures Integration Profile Options
2260

Options that may be selected for this Integration Profile are listed in the Table 6.2-1 along with
the Actors to which they apply.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Table 6.2-1: Presentation of Grouped Procedures – Actors and Options
Actor

OptionsVol. & Section

Acquisition Modality

No options defined--

Department System Scheduler/
Order Filler

No options defined--

Image Manager/
Image Archive

No options defined--

Performed Procedure Step
Manager

No options defined--

6.3 Presentation of Group Procedures Process Flow
2265

Presentation of Grouped Procedures (PGP) provides a mechanism for facilitating viewing images
and reporting on individual Requested Procedures that have been fulfilled by a single Performed
Procedure Step acquisition. The transactions covered are RAD-5 through RAD-10.
The following use case defines the PGP transaction flow:•

When a number of Scheduled Procedure Steps, each corresponding to a different
Requested Procedure, are grouped by a technologist and result in the acquisition ofimages forming a single Performed Procedure Step, the Presentation of these Grouped
Procedures can be facilitated by the combined use of Grayscale Softcopy Presentation
States and associated Performed Procedure Steps as defined below.

•

This also applies to Evidence Creators that retrieve images resulting from grouped
procedures on the Acquisition Modality and for which presentation states may be defined
specifically associated with one or more of the Requested Procedures.

•

For each of the Requested Procedures, the operator may create one or more Grayscale
Softcopy Presentation States in order to define the corresponding viewing parameters
applicable to a subset of images related to the Requested Procedure. These Grayscale
Softcopy Presentation States shall be associated with a specific Performed Procedure
Step related to the Requested Procedure.

2270

2275

2280

The following example illustrates the PGP flow:
•

2285

2290

In this illustration, the grouping of chest, abdomen and pelvis Requested Procedures
would result in one PPS related to the acquired images on a spiral CT scanner. Then theoperator would select the chest subset of the acquired images, choose the appropriate
window width/window level for the chest images and produce a GSPS recording thechest presentation state. A Procedure Step Completed transaction related to this chest
view would then be sent to the Image Manager and to the Department System
Scheduler/Order Filler. Likewise for the abdomen and the pelvis, thus resulting in four
PPS, one for the images of the three grouped procedures and three PPS each related to thepresentation states. Finally, the images and GSPSes are stored in the Image Archive andStorage Commitment is performed.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

2295

A reading physician may use the GSPSes (associated with the Requested Procedure
indicated in the PPS transaction) created by the technologist to facilitate viewing andinterpreting the CT chest images separately from the CT abdomen images. This will
facilitate interpretation as well as reviewing the relevant subset of prior images.

The following sequence of steps describes the typical process flow involved in Presentation ofGrouped Procedures:______________________________________________________________________________
103
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/ Order
FillerImage Manager/
Image Archive

Acquisition
Modality

Query Modality
Worklist [RAD-5]

Modality Procedure Step
Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Perform
Acquisition

Modality Images
Stored [RAD-8]

Modality Procedure Step
Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]
Storage Commitment[RAD-10]
Modality Procedure Step
Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Create GSPS
Modality Presentation
State Stored [RAD-9]

Modality Procedure Step
Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7]

This set oftransactions
would berepeated 3 times(once for eachof the threepresentation
states in theexample.

Storage Commitment[RAD-10]Figure 6.3-1: Presentation of Grouped Procedures Process Flow2300______________________________________________________________________________
104
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

7 Access to Radiology Information (ARI)2305

The Access to Radiology Information Integration Profile specifies a number of querytransactions providing access to radiology information, including images and related reports, in a
DICOM format as they were acquired or created. Such access is useful both to the radiology
department and to other departments such as pathology, surgery and oncology. Non-radiology
information (such as lab reports) may also be accessed if made available in DICOM format.

7.1 Actors/Transactions

2310

Figure 7.1-1 diagrams the actors involved with this profile and the transactions between actors.
The italicized transactions represent a “generic” set of query/ retrieve transactions. The specifictransactions required are dependent on which specific content profile(s) are supported by the
Image Display and Image Manager/ Image Archive Actors.

Image Display↓ RAD-xx: Content Query↓ RAD-yy: Content Retrieve

Image
Manager

Report Repository↑ RAD-26: Query Reports↑ RAD-27: Retrieve Reports

Image
Archive

External Report Repository Access↑ RAD-26: Query Reports↑ RAD-27: Retrieve Reports

Report Reader

Figure 7.1-1: Access to Radiology Information Diagram2315______________________________________________________________________________
105
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2320

Table 7.1-1 lists the transactions for each actor directly involved in the Access to Radiology
Information Integration Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). A complete list of options
defined by this Integration Profile and that implementations may choose to support is listed inVolume 1, Section 7.2.
Table 7.1-1: Access to Radiology Information - Actors and Transactions
ActorsTransactions

Report Reader
Report Repository

Optionality

Vol. 2 / 3SectionQuery Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Query Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

External Report Repository
AccessQuery Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Image Display

Required transactions depend on the Content Profiles supported

Image Manager/
Image Archive

Required transactions depend on the Content Profiles supported

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

2325

The Image Display and Image Manager/ Archive Actors are required to support theQuery/Retrieve transactions for each dependent Content Profile they support. They must support
at least one Content Profile, for example the Mammography Image Profile, the NM Image
Profile and others.

7.2 Access to Radiology Information Integration Profile Options
2330

Options that may be selected for this Integration Profile are listed in the Table 7.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 7.2-1: Access to Radiology Information - Actors and Options
Actor

OptionsVol. & Section

Image Display

Multiple Sources

RAD TF-1: 7.3.1

Image Manager/
Image Archive

No options defined

Report Reader

Multiple Sources

Report Repository

No options definedExternal Report Repository Access

No options defined

RAD TF-1: 7.3.1-______________________________________________________________________________
106
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

7.3 Multiple Sources Option
2335

2340

This option requires Image Displays and Report Readers to support query and retrieve frommultiple information sources in order for a user to gain access to distributed radiology
information.
Image Displays, in particular, are typically closely associated with, and draw information from, asingle Image Manager/Image Archive. An Image Display that implements this option supports auser that desires to view information consolidated from multiple sources (e.g., ultrasound miniPACS, cardiology PACS, and radiology PACS).
Querying multiple sources also provides an opportunity for an Image Display to access objects
stored in a “legacy” archive that has been replaced by, and is possibly having its information
migrated to, a new Image Manager/Image Archive.

2345

7.3.1 Requirements for the Multiple Sources Option
In order to claim support for this profile option, an Image Display shall be able to query andretrieve from multiple Image Manager/Image Archives.
In order to claim support for this profile option, a Report Reader shall be able to query andretrieve from multiple Report Repositories.

2350

There is no requirement as to whether the multiple queries or retrieves are done concurrently orsequentially.
Image Displays and Report Readers shall have the ability to be configured to access multiple
Image Manager/Image Archives and Report Repositories (respectively).

2355

2360

Image Managers and Report Managers shall also support the Patient Information Reconciliation
integration profile in order to ensure that the information gathered from them is as accurate as
possible. Since having actors in different ADT (patient identifier) domains could result in
unpredictable query results, this option assumes that all actors are members of the same ADT
domain (i.e., it can be assumed that a given patient identifier uniquely refers to a single patient).
An Image Display or Report Reader supporting this profile option may be configured to initiallyquery only its local information source; however, it shall be possible to query multiple sources
with a single user request.
When an Image Display and Report Reader are combined, a single user request shall suffice totrigger a query of multiple sources for both images (and anything else stored in an ImageManager/Image Archive) and reports.

2365

2370

If communication with an information source fails, an Image Display or Report Reader shallprovide the information it received from the other sources. In addition, the Image Display andReport Reader shall inform the user that they are viewing potentially incomplete results.
When an Image Display or Report Reader performs a study-level or series-level query tomultiple sources and finds the study/series referenced in multiple places, the study/series is either
duplicated or the study/series is split across the systems. When the user requests a retrieval of thestudy/series an Image Display and Report Reader shall collate the information, determine if the______________________________________________________________________________
107
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
information is actually duplicated or split, and present to the user a consolidated view of results.
The consolidated view of results may be shown and updated either as responses are received orwhen the final response has been received from the last responding information source.
2375

A participating Image Display or Report Reader shall manage duplicate instances in a mannerthat avoids redundant retrieval.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

8 Key Image Note (KIN)
2380

2385

The Key Image Note Integration Profile specifies transactions that allow a user to mark one ormore images in a study as significant by attaching to them a note managed together with thestudy. This note includes a title stating the purpose of marking the images and, optionally, a usercomment field. Physicians may attach Key Image Notes to images for a variety of purposes:
referring physician access, teaching files selection, consultation with other departments, andimage quality issues, etc.
It should be noted that while Key Image Notes meet the definition of Evidence Documents, they
are a special case that is dealt with separately in this Profile for historical reasons. Refer to The
Evidence Documents Profile (section 14) for a description of general evidence document
handling.

2390

The process of creating and using Key Image Notes can be managed by worklists that provide
patient/ procedure details and by performed procedure steps that report status information (e.g.,
see Integration Profiles on Scheduled Workflow, Post-Processing Workflow, Reporting
Workflow).

8.1 Actors/Transactions
2395

Figure 8.1-1 diagrams the actors involved with this profile and the transactions between actors.

Image Display

Evidence Creator

Storage Commitment:
RAD-10↓Image
Manager

StorageCommitment: RAD-10 ↑↓ RAD-29: Store Key Image
Note↓ RAD-14: Query Images↓ RAD-16: Retrieve Images↓ RAD-30: Query Key Image Notes↓ RAD-31: Retrieve Key Image Notes

Image
Archive↑ RAD-29: Store Key Image
Note

Acquisition Modality

Figure 8.1-1: Key Image Note Diagram______________________________________________________________________________
109
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2400

2405

Table 8.1-1 lists the transactions for each actor directly involved in the Key Image Notes
Integration Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile and that implementations may choose
to support is listed in Volume 1, Section 8.2.
Table 8.1-1: Key Image Note Integration Profile - Actors and Transactions
ActorsTransactions

Acquisition Modality
Evidence Creator
Image Manager/ Image Archive
Image Archive

Image Display

Optionality

Vol. 2 / 3SectionStorage Commitment [RAD-10]

R

4.10

Key Image Note Stored [RAD-29]

R

4.29

Storage Commitment [RAD-10]

R

4.10

Key Image Note Stored [RAD-29]

R

4.29

Storage Commitment [RAD-10]

R

4.10

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Key Image Note Stored [RAD-29]

R

4.29

Query Key Image Notes [RAD-30]

R

4.30

Retrieve Key Image Notes [RAD-31]

R

4.31

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Query Key Image Notes [RAD-30]

R

4.30

Retrieve Key Image Note [RAD-31]

R

4.31

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

8.2 Key Image Notes Integration Profile Options

2410

Options that may be selected for this Integration Profile are listed in the Table 8.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 8.2-1: Key Image Notes - Actors and Options
Actor

Options

Acquisition Modality

No options definedVol. & Section-

Evidence Creator

No options defined-

Image Manager/
Image Archive

No options defined-

Image Display

No options defined-

8.3 Key Image Note Pattern
The Key Image Note allows a user to mark one or more images in a study as significant byattaching to them one or more notes managed together with the study. Each note includes a title______________________________________________________________________________
110
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2415

stating the purpose of marking the images and a user comment. Physicians may attach Key
Image Notes to images for a variety of purposes: referring physician access, teaching files
selection, consultation with other departments, and image quality issues, etc. The list of titles
used to described why the images are being marked is defined by DICOM and is contained in
CID 7010 (Key Object Selection Document Title) in DICOM PS3.16.

2420

A single Key Image Note may reference several images within a study. Multiple Key Image
Notes may reference the same image.

2425

2430

When a Key Image Note refers to an image, it may also include a reference to a specific
Presentation State for the image thus ensuring that the Key Image Note includes significant
information about the image presentation state (window width/window level, flip, zoom, rotate,graphical and textual annotations as defined in the Consistent Presentation of Images Integration
Profile). This information may be used by the Image Display that supports both the Key Image
Notes and Consistent Presentation of Images Integration Profiles.
The content pattern of a Key Image Note is shown in Figure 8-2-1 and shall use the DICOM Key
Object Selection Document SOP Class definition. The marked images of a study are thosereferenced by a Key Object Selection Document that belong to the same study as the Key Object
Selection Document.
IHE does not require Evidence Creator Actors producing Key Image Notes to support the ability
to reference images outside of the study. However, if they chose to do so, the inclusion of the
Identical Documents Sequence is required per the DICOM Standard.

2435

2440

IHE requires Image Display Actors receiving Key Image Notes to display the fact that images
referenced by the Key Object Selection Document belonging to the same study are flagged. It isbeyond the scope of IHE to specify the means used to show this fact. Although Image Display
recipients of Key Image Notes are required, per the DICOM Standard, to accept the Key Object
Selection Documents with references outside the study, they are not required but may choose tosupport retrieval and display of the images from other studies outside of the one to which the
Key Image Note belongs.

HAS OBS CONTEXT

Document Title(CONTAINER)

Observation Context
1

CONTAINS
0-1

1-n

Key Image Description(TEXT)

Image Reference(IMAGE)

Figure 8.3-1: Key Image Note Pattern______________________________________________________________________________
111
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2445

9 Simple Image and Numeric Report (SINR)

2450

The Simple Image and Numeric Report Integration Profile facilitates the growing use of digital
dictation, voice recognition, and specialized reporting packages, by separating the functions ofreporting into discrete actors for creation, management, storage and viewing. Separating thesefunctions while defining transactions to exchange the reports between them enables a vendor to
include one or more of these functions in an actual system.

2455

Reports exchanged have a simple structure attractive to many imaging departments: a title, anobservation context, and one or more sections, each with a heading, observation context, text,
image references, and optionally coded measurements. Some elements can also be coded tofacilitate computer searches. Such reports can be input to the formal diagnostic report, thus
avoiding re-entry of information.
The process of creating imaging reports can be managed by worklists that provide patient/procedure details and by performed procedure steps that report status information (e.g., see theReporting Workflow Integration Profile).

9.1 Actors/Transactions
2460

Figure 9.1-1 diagrams the actors involved with this profile and the transactions between actors.

Report Creator↓ RAD-24: Report Submission
Report Manager

Structured Report Export: RAD-28 ↓↓ RAD-25: Report Issuing↑ RAD-26: Query Reports↑ RAD-27: Retrieve Reports

Report Repository

Enterprise Report Repository
External Report Repository Access↑ RAD-26: Query Reports↑ RAD-27: Retrieve Reports↑ RAD-26: Query Reports↑ RAD-27: Retrieve Reports

Report Reader

Figure 9.1-1: Simple Image and Numeric Report Diagram

2465______________________________________________________________________________
112
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2470

Table 9.1-1 lists the transactions for each actor directly involved in the Simple Image andNumeric Report Integration Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). Transactions labeled “O”
are optional. A complete list of options defined by this Integration Profile and that
implementations may choose to support is listed in Volume 1, Section 9.2.
Table 9.1-1: Simple Image and Numeric Report - Actors and Transactions
ActorsTransactions

Optionality

Vol. 2 / 3Section

Report Creator

Report Submission [RAD-24]

R

4.24

Report Manager

Report Submission [RAD-24]

R

4.24

Report Issuing [RAD-25]

R

4.25

Query Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Structured Report Export [RAD-28]

O

4.28

Query Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Report Issuing [RAD-25]

R

4.25

Query Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Report Reader
Report Repository

External Report Repository
AccessEnterprise Report Repository

Query Reports [RAD-26]

R

4.26

Retrieve Reports [RAD-27]

R

4.27

Structured Report Export [RAD-28]

R

4.28

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

2475

9.2 Simple Image and Numeric Report Integration Profile Options
Options that may be selected for this Integration Profile are listed in the Table 9.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 9.2-1: Simple Image and Numeric Report - Actors and Options
Actor

OptionsVol. & Section

Enterprise Report Repository

No options defined-External Report Repository Access

No options defined-

Report Creator

Enhanced SR

Report Manager

No options defined

Report Reader

Enhanced SR

Report Repository

No options defined

RAD TF-2: 4.24.4.1.2
RAD TF-2: 4.27.4.2.2-______________________________________________________________________________
113
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2480

The Report Creator, Report Manager and Report Repository will likely support a variety of
DICOM SOP Classes. It is expected that this level of optionality will be documented by areference in the IHE Integration Statement (see appendix D).

9.3 Diagnostic Report Process Flow
2485

This section describes the typical process flow related to diagnostic reporting. The transactions
covered are RAD-24 through RAD-27.
In the initial stage of diagnostic reporting, a reading physician records the diagnosis bygenerating a draft DICOM Structured Report object, which is submitted to the Report Manager.
Once a report is sent to the Report Manager, the Report Creator relinquishes control of the reportto the Report Manager.

2490

There are other documents which are sometimes referred to as “reports” and may be encodedusing DICOM SR (for example, procedure reports, CAD results and echocardiographymeasurement reports) however such documents do not follow the same kind of verification anddistribution process described in this profile. These other documents serve different purposes andare instead addressed in the Evidence Documents Profile.

2495

Reports are processed and modified by the Report Manager. This involves adding and changing
report data as well as verifying draft reports. In all cases, any change in the report content by theReport Manager leads to the creation of a new DICOM Structured Report object. At any time,
the Report Manager can transmit reports to the Report Repository for external access, but at aminimum the final report must be sent to the Report Repository. A Report Creator caneffectively amend a report by submitting a new SR SOP Instance.

2500

The Report Repository provides permanent storage of DICOM Structured Reports. It also allows
reports to be queried and retrieved throughout the enterprise by Report Readers. A Report
Reader provides a user interface to view DICOM Structured Reports that it retrieves from theReport Repository or External Report Repository Access.
2505

The External Report Repository Access is a gateway to obtain other enterprise department
reports, such as Laboratory and Pathology, from within the Imaging department. DICOM
Structured Reports are queried and retrieved by a Report Reader from the External Report
Repository Access.
The Enterprise Report Repository receives diagnostic reports in HL7 format.

2510

The Simple Image Report and Simple Image and Numeric Reports are required minimally tohave the functionality defined in template TID 2000. Creators may introduce increased
complexity as long as it conforms to the SOP class. The templates referenced in the Technical
Framework are included in DICOM Part 16.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ReportCreatorReportManager

ReportRepository

ReportReaderExternal Report
Repository
AccessEnterprise
ReportRepository

ReportCreation
ReportSubmission [RAD-24]
Report Issuing[RAD-25]

Report Modification
or Verification

Report Issuing[RAD-25]
Structured Report Export [RAD-28]

Query Reports [RAD-26]

Retrieve Reports [RAD-27]

View Reports

Query Reports [RAD-26]

Retrieve Reports [RAD-27]

View Reports

2515
Figure 9.3-1: Diagnostic Reporting Process Flow______________________________________________________________________________
115
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

9.4 Diagnostic Reporting Use Cases
2520

DICOM Structured Reports offer the capability to encode arbitrarily structured diagnostic report
data. The IHE Technical Framework stipulates that the reporting actors need to support several
use cases and their specific content patterns, which are detailed in the following sections.
The diagrams in the following sections define the report content pattern and utilize the following
conventions:

2525

2530

•

Each rectangle is a single Content Item.

•

Italic text in a rectangle denotes a generic grouping of Concept Names to be used for theContent Item. These must be configurable in the reporting actors.

•

Uppercase text in a rectangle denotes the Content Item Value Type.

•

Text following the Content Item Value Type specifies the possible Content Item
Value(s), if known (only used for Observation Context).

•

Text on lines defines the relationship between Content Items.

•

Numbers on lines define the cardinality of descendent Content Items.

9.4.1 Simple Image Report2535

The Simple Image Report allows documents with multiple sections (with headings) containing
report text and references to relevant images. Some text items of these documents may also be
related to specific images. This allows a reading physician to identify one or more images fromwhich their conclusions were inferred. This content pattern is shown in Figure 9.4-1 and shalluse the DICOM Basic Text SR Information Object Definition and Basic Image Diagnostic
Report Template (TID 2000 in DICOM 2011 PS3.16). Note that TID 2000 has otherrequirements not shown in the diagram.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________HAS OBS CONTEXT

Document Title(CONTAINER)

Observation Context(See section 9.3.3)

1
1-nCONTAINSHAS OBS CONTEXT

Section Heading(CONTAINER)

Observation Context(See section 9.3.3)

0-1
CONTAINS0-n0-n

Report Text(TEXT)

0-n

Image Reference(IMAGE)

Coded Entry(CODE)

INFERRED FROM

INFERRED FROM

0-n

0-n

Image Reference(IMAGE)

2540

Image Reference(IMAGE)

Figure 9.4-1: Simple Image Report Pattern

9.4.2 Simple Image and Numeric Report2545

The Simple Image and Numeric Report is similar to the Simple Image Report described in
section 9.3.1 but allows the addition of numeric values. This enables a diagnosis to include
measurements and other numeric values. Like the Simple Image Report, particular text values
can be encoded to signify that they are inferred from specific images or numeric values. This
content pattern is shown in Figure 9.4-2 and shall use the DICOM Enhanced SR Information
Object Definition and Basic Image Diagnostic Report Template (TID 2000 in DICOM 2011
PS3.16). Note that TID 2000 has other requirements not shown in the diagram.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Document Title(CONTAINER)

HAS OBS CONTEXT

Observation Context(See section 9.3.3)

1
1-nCONTAINS

Section Heading(CONTAINER)

HAS OBS CONTEXT

Observation Context(See section 9.3.3)

0-1
CONTAINS
0-n
Report Text(TEXT)

0-n

0-n

0-n

Image Reference(IMAGE)

Measurement(NUM)

Coded Entry(CODE)

INFERRED FROM
0-n

INFERRED FROM
0-n

Image Reference(IMAGE)

0-n

Measurement(NUM)

Image Reference(IMAGE)

0-n
Measurement(NUM)

Figure 9.4-2: Simple Image and Numeric Report Pattern

9.4.3 Observation Context
2555

2560

Encoding of the Observation Context for Simple Image Report and Simple Image and Numeric
Report shall follow the definition of corresponding standardized template TID 1001. The
template is contained in DICOM 2011 PS3.16: DICOM Content Mapping Resource (DCMR).
Observation context content items may be descended from the root content item, and may besuperseded by subsequent observation contexts at the section level. Therefore, the observation
context may change throughout the report. This capability allows one report to include, forexample, observations on a mother and fetus, observations by multiple observers, or observations
from multiple studies.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

10 Basic Security (SEC) - DEPRECATED
2565

This profile has been superseded by the Radiology Audit Trail Option on ITI-Audit Trail andNode Authentication (see RAD TF-3: 5.1 for a detailed description of the Radiology Audit Trail
Option).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

11 Charge Posting (CHG)
2570

2575

The Charge Posting Integration Profile specifies information exchange from the Department
System Scheduler/Order Filler to the Charge Processor about charges associated with particular
procedures, as well as communication about patient demographics, accounts, insurance, andguarantors between ADT Patient Registration and Charge Processor. The Charge Posted
Transaction contains some information to generate a claim. Currently, these interfaces containfixed field formatted or HL7-like data. The goal of including this in the IHE Technical
Framework is to standardize interface between clinical systems and the Charge Processors.
Additionally, the Charge Posted Transaction reduces the need of the billing system to haveknowledge of the radiology internals. The result is that the Charge Processor will receive more
complete, timely and accurate data.

2580

The Department System Scheduler/Order Filler indicates to the Charge Processor that procedures
are available for Technical and/or Professional billing. The Charge Posted transaction may occur
at various times in the workflow. Regulations and site operating procedures determine when aprocedure is eligible for Charge Posting. Often, the events are different for technical andprofessional charges.

2585Technical charges are typically eligible at procedure completion.
Professional charges are typically eligible at result verification.
Events that may trigger charges are Procedure Ordered, Procedure Scheduled, Procedure
Completed, Result Dictated, Result Transcribed, and Result Verified.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2590

11.1 Actors/Transactions

ADT

Report Manager↓ RAD-36:
Account
Management↓ RAD-42: Performed Work
Status Update
DSS/Order Filler↑ RAD-6: Modality PS In Progress↑ RAD-7: Modality PS Completed↑ RAD-20: Creator PS In Progress↑ RAD-21: Creator PS Completed↑ RAD-59 Import PS In Progress↑ RAD-60: Import PS Completed

PostProcessing
Manager→ RAD-35:
Charge Posted

Charge Processor↑ RAD-39: Workitem Completed

Performed
Procedure
Step Manager← RAD-20: Creator PS In Progress← RAD-21: Creator PS Completed

Evidence Creator← RAD-6: Modality PS In Progress← RAD-7: Modality PS Completed
Acquisition Modality← RAD-59 Import PS In Progress← RAD-60: Import PS Completed
ImporterFigure 11.1-1: Charge Posting Transaction Diagram

2595

Table 11.1-1 lists the transactions for each actor directly involved in the Charge Posted Profile.
In order to claim support of this Integration Profile, an implementation must perform therequired transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of
options defined by this Integration Profile and that implementations may choose to support islisted in Volume 1, Section 11.2.
Table 11.1-1: Charge Posting – Actors and Transactions
ActorsTransactions

Optionality

Vol. 2 / 3Section

ADT Patient Registration

Account Management [RAD-36]

R

4.36

Department System
Scheduler/
Order Filler/Performed
Procedure Step Manager(note 3)Charge Posted [RAD-35]

R

4.35

Modality Procedure Step In Progress[RAD-6]R

4.6

Modality Procedure Step Completed[RAD-7] (note 2)R

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Actors

Optionality

Vol. 2 / 3SectionCreator PS In Progress [RAD-20]

R

4.20

Creator PS Completed [RAD-21]

R

4.21

Performed Work Status Update [RAD42]

R

4.42

Import Procedure Step In Progress[RAD-59]

R

4.59

Import Procedure Step Completed[RAD-60] (note 4)

R

4.60

Modality Procedure Step In Progress[RAD-6] (note 1)

R

4.6

Modality Procedure Step Completed[RAD-7]

R

4.7

Report Manager

Performed Work Status Update [RAD42]

R

4.42

Evidence Creator

Creator PS In Progress [RAD-20]

R

4.20

Creator PS Completed [RAD-21]

R

4.21

Post-Processing Manager(note 3)

Workitem Completed [RAD-39]

R

4.39

Charge Processor

Charge Posted [RAD-35]

R

4.35

Account Management [RAD-36]

R

4.36

Import Procedure Step In Progress[RAD-59]

R

4.59

Import Procedure Step Completed[RAD-60] (note 4)

R

4.60

Acquisition Modality

Importer

2600

Transactions

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.
Note 1: An Acquisition Modality that claims the Charge Posting Profile shall support the Assisted Protocol Setting Option(see RAD TF-2: 4.6.4.1.2.4.2).
Note 2: In the transaction, the DSS/Order Filler shall use the Billing and Material Management information supplied by the
Acquisition Modality (see RAD TF-2: 4.7.4.1.3.2) or the Importer (see RAD TF-2: 4.7.4.1.3.2, 4.60.4.1.3.2)

2605

Note 3: The Post-Processing Manager participates in this profile only if the Post Processing Workflow Integration Profile isone of the pre-requisite profiles supported. In this case, the Post-Processing Manager shall be grouped with the
DSS/ Order Filler.
Note 4: To claim the Charge Posting Profile, the Importer shall support the Billing and Material Management Option (seeRAD TF-3: 4.60.4.1.2.3).

2610

11.2 Charge Posting Integration Profile Options
Options that may be selected for this Integration Profile are listed in the Table 11.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Table 11.2-1: Charge Posting – Actors and Options
Actor

OptionsVol. & Section

ADT Patient Registration

No options defined-

Department System Scheduler/
Order Filler

No options defined-

Acquisition Modality

PPS Exception Management

RAD TF-2: 4.7

Modality Group Case

RAD TF-2: 4.6

Billing and Material Management

RAD TF-2: 4.7.1.2.3

Performed Procedure Step Manager

No options defined-

Evidence Creator (note 1)

No options defined-

Report Manager

No options defined-

Charge Processor

No options defined-

Importer

Billing and Material Management

RAD TF-3:
4.60.4.1.2.3

Note 1: The Billing and Materials Management Option may in some cases also apply to an Evidence Creator Actor in
Charge Posting. However, it is at this time not specified.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

11.3 Charge Posting Process Flow
ADT

Acquisition
Modality

Importer

Performed Ev idence
Procedure
Creator
Step Manager

ReportManager

DSS/ Order
FillerChargeProcessor

Account Management

Patient Reg istration

Charge Posted

ImportProcedure Step
Co mpleted

ImportProcedure Step
Co mpleted
Charge Posted

Modality
Procedure Step
Co mpleted

Modality
Procedure Step
Co mpleted
Charge Posted

Creator PPS
Co mpleted
Creator PPS
Co mpleted

Charge Posted

ReportingCompleted

Performed Work
Status Update

Charge Posted

2620
Figure 11.3-1: Charge Posting Process Flow______________________________________________________________________________
124
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Events that may trigger a charge posted transaction are Procedure Ordered, Procedure Scheduled,
Procedure Completed, Result Dictated, Result Transcribed, and Result Verified.
2625

11.3.1 Use Cases
This section describes the potential use cases relating to the charge posting functionality. It is the
responsibility of the Department System Scheduler/Order Filler to ensure that the billinginformation is sent to the Charge Processor. The Department System Scheduler/Order Filler
forwards the data that is required by the Charge Processor to generate the claim.

2630

The Charge Processor shall accept the Charge Posted Transaction information. Interpretation andsubsequent billing processes by the Charge Processor are beyond the scope of this profile.
Below are listed the typical use cases:

2635

2640

•

A Department System Scheduler/Order Filler makes technical charges available forposting when the modality has completed the procedure.

•

A Department System Scheduler/Order Filler makes professional charges available forposting at time of report verification.

•

A site makes both technical and professional charges available at time of result
verification.

•

A site may have a single charge that comprises both the technical and professional
components.

11.3.2 Technical Billing

2645

Technical charges are based on the procedure and often include typical materials usage. These
are one or more charges that are included in the Charge Posted Transaction. The Charge Posted
Transaction message can be sent immediately when the Department System Scheduler/Order
Filler receives confirmation that the procedure is completed. Additionally, a site may wish tosend information on materials used during a procedure to the Charge Processor for inclusion withthe technical charges.
Note that it may be site policy to verify from the Image Manager that the images have been
stored. This is dependent on the business rules established for that site.

2650

2655

11.3.3 Professional Billing
Professional charges are based on the reading physician providing the results for the procedure.
These are one or more charges that are included in the Charge Posted Transaction. The
Professional Billing Charge Posted Transaction can be sent anytime after the Department System
Scheduler/Order Filler receives confirmation from the Report Manager that the report has been
completed and verified. This may be done by grouping the Report Manager with Department
System Scheduler.
Note that IHE specifies a non-country specific procedure coding scheme.
The Charge Posted Transaction defines the below sources of information:______________________________________________________________________________
125
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
•
2660
•

2665
•

Patient Order Information•

Scheduling and Requested Procedure•

Scheduling and Scheduled Procedure Step

Modality Performed Procedure Step•

Status Information - Completed / Discontinued•

Protocol Code•

Consumables

Optionally, additional manual input or processing by the Department System
Scheduler/Order Filler•

11.4 Data Model for Charge Posting
2670

The data model adopted by the IHE Technical Framework for the HL7 messages used in theCharge Posting Profile is based on a subset of HL7 2.3.1 as described is section 11.3.1.
11.4.1 Model of the Real World
Figure 11.4-1 depicts the model of the real world within scope of the Charge Posting Profile.
This model corresponds to the approach suggested in the HL7 standard, in particular:

2675

•

Financial data related to the patient are accumulated as properties of accounts. A patient
may have more than one active (open) account at a time.

•

One account may contain financial data pertaining to more than one Visit. A visit,
however, cannot span multiple accounts.

•

There may be multiple Billable Procedures performed and multiple charges posted as aresult of one visit. There may be one charge posted for multiple procedures and one
procedure to be charged in multiple charge postings, for example, for Technical andProfessional charges.

•

Requested Procedures may be Billable Procedures. One Requested Procedure may
correspond to more than one Billable Procedure.

2680

2685

•

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Patient1Has
0-n
Account

1
Encompasses
1-n
Visit
1
has

1-n
Billable Procedure

Requested Procedure

Is a
0-n

1

1-n
is
composedof
1-m•

Procedure Charge•
Figure 11.4-1: Model of the Real World for Charge Posting______________________________________________________________________________
127
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2690

2695

2700

2705

12 Post-Processing Workflow (PWF)
IMPORTANT NOTE: As of June 2012, IHE introduces a new Trial Implementation Profile:
Post-Acquisition Workflow (PAWF). The use cases addressed are largely the same as PWF,
but the underlying mechanisms are improved. The PWF Profile documented in this section
has been deprecated by the Radiology Domain and is now replaced by PAWF. When the
PAWF Profile becomes Final Text, the contents of this section will be removed. In the interim,
new implementations should be based on PAWF, found at
http://www.ihe.net/Technical_Frameworks/#radiology
The Post-Processing Workflow Integration Profile addresses the need to schedule and track thestatus of the typical post-processing workflow steps, such as Computer Aided Detection or
Image Processing. Worklists for each of these tasks are generated and can be queried, workitems
can be selected and the resulting status returned from the system performing the work to thesystem managing the work. Typically the workitems will involve the creation of objects such asimages and evidence documents. The created images and evidence documents contain thenecessary references for maintaining continuity of order information.
The Post-Processing Workflow Integration Profile is a continuation of the Scheduled Workflow
Integration Profile.

12.1 Actors/Transactions

2710

Figure 12.1-1 shows the actors directly involved in the Post-Processing Workflow Integration
Profile and the relevant transactions between them. The italicized transactions represent a“generic” set of query/ retrieve transactions. The specific transactions required are dependent on
which specific content profile(s) are supported by the Image Display and Image Manager/ Image
Archive Actors.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________v

DSS/Order Filler→RAD-11: Images Availability Query←RAD-42: Performed Work Status Update →ImageManager

Image
Archive

Post-Processing
ManagerRAD-37: Query Post-Processing Worklist ↑RAD-38: Workitem Claimed ↑RAD-40: Workitem PPS In Progress ↑RAD-41: Workitem PPS Completed ↑RAD-39: Workitem Completed ↑Evidence
Creator

RAD-10:Storage Commitment ↑RAD-18: Creator Images Stored ↑RAD-14: Query Images ↑RAD-16: Retrieve Images ↑↑ RAD-xx: Query Other Content↑ RAD-yy: Retrieve Other Content

Image Display

Figure 12.1-1: Post-Processing Workflow Actor Diagram

2715

2720

Table 12.1-1 lists the transactions for each actor directly involved in the Post-Processing
Integration Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile and that implementations may choose
to support is listed in Volume 1, Section 12.2.
Table 12.1-1: Post-Processing Integration Profile - Actors and Transactions
ActorsTransactions

Optionality

Vol. 2 / 3Section

Department System Scheduler/
Order Filler

Images Availability Query [RAD-11]

R

4.11

Performed Work Status Update(Send) [RAD-42]

R

4.42

Image Manager/
Image Archive

Images Availability Query [RAD-11]

R

4.11

Query Images [RAD-14]

O

4.14

Retrieve Images [RAD-16]

O

4.16

Creator Images Stored [RAD-18]

O

4.18

Storage Commitment [RAD-10]

O

4.10

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsEvidence Creator/Image
Display

Post-Processing Manager

Transactions

Optionality

Vol. 2 / 3Section

Performed Work Status Update(Send) [RAD-42]

R

4.42

Query Images [RAD-14]

O

4.14

Retrieve Images [RAD-16]

O

4.16

Creator Images Stored [RAD-18]

O

4.18

Storage Commitment [RAD-10]

O

4.10

Query Post-Processing Worklist[RAD-37]R

4.37

Workitem Claimed [RAD-38]

R

4.38

Workitem PPS In Progress [RAD-40]

R

4.40

Workitem PPS Completed [RAD-41]

R

4.41

Workitem Completed [RAD-39]

R

4.39

Query Post-Processing Worklist[RAD-37]R

4.37

Workitem Claimed [RAD-38]

R

4.38

Workitem PPS In Progress [RAD-40]

R

4.40

Workitem PPS Completed [RAD-41]

R

4.41

Workitem Completed [RAD-39]

R

4.39

Note: Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

2725

2730

Table 12.1-1 represents the case where the Evidence Creator and Image Display are performing
post-processing on image objects and therefore the relevant storage, query, retrieve and storage
commit transactions are listed.
The Evidence Creator, Image Display and Image Manager Actors may also support theConsistent Presentation of Images or Key Image Note Profiles. In that case, the Evidence Creator
is expected to create GSPS and Key Image Note objects as part of its scheduled workitems. The
Image Display and Image Manager Actors would be expected to store, commit, query, retrieve
and display those objects as described in the relevant profiles.
The scenarios shown in the following flow diagrams happen not to include GSPS or Key Image
Note related transactions. Those transactions would typically be sequenced in the same location
as the corresponding image object related transactions.

2735

12.2 Post-Processing Workflow Integration Profile Options
Options that may be selected for this Integration Profile are listed in the table below along with
the Actors to which they apply.
Table 12.2-1: Post-Processing Integration Profile – Actors and Options
ActorsDepartment System Scheduler/
Order Filler

OptionNo options definedVol. 2 / 3 Section-______________________________________________________________________________
130
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Actors

OptionVol. 2 / 3 Section

Image Manager/
Image Archive

No options defined-

Image Display

No options defined-

Evidence Creator/Image
Display

No options defined-

Post-Processing Manager

No options defined-

12.3 Implementation Issues
2740

12.3.1 Actor Grouping Clarification
This profile is designed with the following implementation scenarios in mind:
Scenario 1:
The Post-Processing Manager is grouped with the Image Manager in System A. The DSS in
System B needs status information. In this case:2745

System A claims support of the Post-Processing Workflow Profile as the Post-Processing
Manager and Image Manager Actors.
System B claims support of the Scheduled Workflow Profile as the DSS Actor and implements
the optional Performed Work Status Update transaction.
Scenario 2:

2750

The Post-Processing Manager is grouped with the DSS in System A. The Image Manager inSystem B is not interested in status information. In this case:
System A claims support of the Post-Processing Workflow Profile as the Post-Processing
Manager and DSS Actors.
System B claims support of the Scheduled Workflow Profile as the Image Manager Actor.

2755

Scenario 3:
The Post-Processing Manager is grouped with the DSS in System A. The Image Manager inSystem B needs status information. In this case:
System A claims support of the Post-Processing Workflow Profile as the Post-Processing
Manager and DSS Actors.

2760

System B claims support of the Scheduled Workflow Profile as the Image Manager Actor andimplements the optional Performed Work Status Update transaction.
Scenario 4:
A Post-Processing Manager is grouped with the DSS in System A. Another Post-Processing
Manager is grouped with the Image Manager in System B. In this case:______________________________________________________________________________
131
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2765

System A claims support of the Post-Processing Workflow Profile as the Post-Processing
Manager and DSS Actors.
System B claims support of the Post-Processing Workflow Profile as the Post-Processing
Manager and Image Manager Actors.

2770

This leaves the site with the decision of how to reconcile control of the post-processing
workflow. There are two approaches.
Any system implementing the Post-Processing Manager shall be able to disable this functionality
through configuration.

2775

In the first approach, the site selects one of the two systems to be the Post-Processing Manager
for the Post-Processing workflow by configuring the other to disable its workflow management
functionality.

2780

In the second approach, the site may configure one Post-Processing Manager to start PostProcessing worklists for one set of procedure codes and configure the second Post-Processing
Manager to start Post-Processing worklists for a complementary set of procedure codes. Making
sure that the procedure code sets are non-overlapping and complementary is a configuration
responsibility of the site.
12.3.2 Input Availability

2785

2790

2795

In case of being grouped with the Image Manager, the Post-Processing Manager will have someinternal logic to determine when images available are sufficient for the Post-Processing
workflow to begin. In some cases, it may not be necessary for a post-processing to be performed.
Generally these decisions are based on the procedure code of the requested procedure.
In case of being grouped with the Department System Scheduler, the Post-Processing Manager
uses the Image Availability transaction to know when images are available in the Image Archivefor query. The image set needed for the Post-Processing workitem might or might not include all
the instances the Post-Processing Manager has been notified about via previous MPPS or/and
GP-PPS messages related to a requested procedure. Based on the received information and its
internal logic the Post-Processing Manager decides which data the Post-Processing workitem
input consists of.
Generally, the Post-Processing Manager will create a workitem in the Post-Processing worklist
when the required images are available, although it may create the workitem before that with anempty or incomplete Input Information Sequence and the Input Availability Flag set to
PARTIAL, until the images are available in the Image Archive.
The Post-Processing Manager and Post-Processing Client (Evidence Creator) must be preparedto handle workitems with PARTIAL image availability in a stable fashion.

2800

The Post-Processing Client may elect not to present workitems with PARTIAL status to the user
for selection until their status later changes to COMPLETE. If the Post-Processing Client
chooses to let the user select and start work on those items, then the Post-Processing Client is
responsible for monitoring the post-processing worklist and make sure the user/application
receives the full data when it is available.
______________________________________________________________________________
132
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2805

Similarly the Post-Processing Manager may choose to leave workitems with PARTIAL statusout of provided worklists until the status is COMPLETE. If the Post-Processing Manager decides
to provide PARTIAL workitems in the worklists, then it may be expected to check image
availability and provide updated post-processing worklist replies to queries from the PostProcessing Client for workitems the client claims.
12.3.3 Evidence Creators in Scheduled Workflow vs. Post-Processing Workflow

2810

2815

An Evidence Creator that supports the Post-Processing Workflow Profile shall use mechanisms
defined in this profile, i.e., General Purpose Performed Procedure Step, for all post-processing
tasks including unscheduled tasks.
Evidence Creators that only support the Scheduled Workflow Profile may continue to use theModality Performed Procedure Step transactions to communicate tasks performed as describedin the Scheduled Workflow Profile.

12.4 Post-Processing Process Flow
The following are some possible post-processing use cases.
12.4.1 Computer Aided Detection Use Case
2820

A modality procedure (e.g., a mammography screening exam or a lung CT) is to be acquired and
CAD processing is to be performed on the images. The images and CAD processing results will
be interpreted together on a review workstation by the reading physician.

2825

The specific actors in this case are Acquisition Modality (digital mammography or CT
acquisition system), Evidence Creator/Image Display (CAD processing system), Department
System Scheduler, Image Manager/Image Archive, Post-Processing Manager, and Image Display(review workstation).

2830

The Post-Processing Manager is grouped with either the Department System Scheduler or ImageManager and is responsible for providing work to the Evidence Creator. The DICOM Standard
services used are Storage of Images (Digital Mammography X-ray or CT), Query/Retrieve,
General Purpose Worklist, and Storage of Structured Reports (e.g., Mammography CAD or
Chest CAD).

2835

2840

When MPPS Complete has been received and the acquired images are available on the Image
Archive, the Post-Processing Manager would add a CAD workitem to the worklist. The CAD
processing system would query the worklist, claim the workitem and based on the containedreferences, retrieve the images from the Image Manager and perform the scheduled CAD
processing, reporting the status back to the Post-Processing Manager (including references toresult objects created). The generated Evidence documents (CAD processing results) are stored
as DICOM Structured Reports (e.g., Mammography CAD or Chest CAD).
The Evidence Document includes references to the images that were analyzed (typically for
mammography screening, the MLO and CC views of the left and right breasts), a summary of thealgorithms that were executed, including algorithm identification, whether they succeeded or
failed, and the findings detected by the algorithms. For example, CAD processing for______________________________________________________________________________
133
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
mammography or lung studies may include identification of the locations of things likesuspected densities (masses) and micro-calcifications on the images.
2845

2850

Although in this case, the Evidence Creator does not actually create images, just an Evidence
Document object (e.g., a CAD object), it is also possible that if the images were enhanced during
processing (e.g., a filtered image), new versions of the image might also be stored to the ImageManager. At the end, the Post-Processing Manager is notified with a GP-SPS update that thescheduled step is complete.
The images and evidence documents are then available for retrieval by the Image Display Actor
on a Review/Reporting system where they can be reviewed by a reading physician and a proper
diagnostic report generated. In this way, the profile complements the Simple Image and Numeric
Report Profile.
12.4.2 3D Reconstruction Use Case

2855

2860

A modality procedure (e.g., a standard CT lumbar spine exam) is to be acquired andreconstructed and the results sent to a 3D post-processing application where Multi-Planar
Reconstruction (MPR) is performed to get coronal images of the lumbar spine. The originallycreated axial images and the new coronal images are interpreted together, either at the modality
or on a review station.
The specific actors in this case are the Acquisition Modality (e.g., a CT system), Image
Display/Evidence Creator (3D workstation), Department System Scheduler, ImageManager/Image Archive, Post-Processing Manager, and Image Display (review workstation).
The Post-Processing Manager is grouped with either the Department System Scheduler or ImageManager and is responsible for providing work to the Evidence Creator. The DICOM Standard
services used are Storage of Images (CT), Query/Retrieve, and General Purpose Worklist.

2865

2870

When MPPS Complete has been received and the acquired images are available on the Image
Archive, the Post-Processing Manager would add a post-processing workitem (GP-SPS) to theworklist. The 3D-processing system would query the worklist, claim the workitem and based on
the contained references, retrieve the images from the Image Manager and perform the scheduled
MPR processing, reporting the status back to the Post-Processing Manager (including references
to result objects created). The MPR result images are stored as DICOM Images (CT). At the end,
the Post-Processing Manager is notified with a GP-SPS update that the scheduled step iscomplete.
The images are then available for retrieval by the Image Display Actor on a review/reporting
system.

2875

12.4.3 Post-Processing Process Flow Diagrams
The following scenario illustrates a case where an image processing task is performed on
acquired images and then a subsequent CAD step is performed on the processed images. The
Transaction Summary is depicted for two scenarios:•

The Post-Processing Manager is grouped with the Department System Scheduler______________________________________________________________________________
134
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
2880

2885

•

The Post-Processing Manager is grouped with the Image Manager

The Performed Work Status Update (Started) message must be sent sometime after theWorkitem Claimed transaction but at the latest, when the first GP-PPS In Progress is received. In
this scenario it is shown right after the Workitem Claimed. Also, it is conceivable that in somescenarios, the processing workstation has loaded potentially useful studies/images prior toclaiming the workitem or maybe even before getting the worklist.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Image Manager/
Image Archive

DSS /Post-Processing
Manager

ImagesAvailable Query(3D Workstation)
Evidence
Creator/ Image
Display(CAD System)
Evidence Creator/
Image Display(Review)
Image Display

Create Post-Processing Workitem
Query Post-Processing
Worklist

Performed Work
Status Update (Started)

Workitem Claimed(Post-Processing)

Retrieve Images

Post-Processing

Workitem PPS
In Progress

Perform
3D Processing

Creator Images Stored
Storage Commitment
Workitem PPS
Completed

Performed Work
Status Update(Completed)

WorkitemCompleted(Post-Processing)
Create CAD Workitem
Query Post-Processing Worklist

Performed Work
Status Update (Started)

Workitem Claimed(CAD)
Retrieve Images
Workitem PPS
In Progress

CAD

Evidence Documents Stored

Perform
CAD Processing

Storage Commitment
Worktiem PPS
Completed

Performed Work
Status Update(Completed)

WorkitemCompleted(CAD)

Query/Retrieve Images/Evidence Documents

Figure 12.4-1: Post-Processing Manager Grouped with Department System Scheduler______________________________________________________________________________
136
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Manager/
Image Archive Post-Processing
ManagerDSS(3D Workstation)
Evidence
Creator/ Image
Display(CAD System)
Evidence
Creator/I
Di l(Review)
Image Display

Images Available
Create Post-Processing Workitem
Query Post-Processing
Worklist

Performed Work
Status Update (Started)

Workitem Claimed(Post-Processing)

Retrieve Images

Post-Processing

Workitem PPS
In Progress
Perform
3D Processing
Creator Images Stored
Storage Commitment
Workitem PPS
Completed

Performed Work
Status Update(Completed)

WorkitemCompleted(Post-Processing)
Create CAD Workitem
Query Post-Processing Worklist

Performed Work
Status Update (Started)

Workitem Claimed(CAD)
Retrieve Images
Workitem PPS
In Progress

CAD

Evidence Document
StoredPerform
CAD Processing

Storage Commitment
Workitem PPS
Completed
Performed Work
Status Update(Completed)

WorkitemCompleted(CAD)

Query/Retrieve Images/Evidence Documents

2890

Figure 12.4-2: Post-Processing Manager Grouped with Image Manager______________________________________________________________________________
137
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

13 Reporting Workflow (RWF)2895

The Reporting Workflow Profile addresses the need to schedule and track the status of thevarious reporting tasks. Reporting tasks include interpretation, dictation, transcription,verification, comparison, revision, and coding. Workitems for each of these tasks are generated
and can be queried from worklists. Workitems can be claimed. The resulting intermediate andfinal statuses can be returned from the system performing the work to the system managing thework. The system managing the work also makes the status available for other interested systems
in the enterprise.

2900

The output of the Reporting Workflow Profile is defined to be information encoded as DICOM
SR objects. The details for creation, storage, query/ retrieve and encoding are described by the
Simple Image and Numeric Report (SINR) Profile (volume 1, section 9).
The Reporting Workflow Integration Profile is a continuation of the Scheduled Workflow
Integration Profile.

13.1 Actors/Transactions
2905

Figure 13.1-1 shows the actors directly involved in the Reporting Workflow Integration Profileand the relevant transactions between them. Other actors that may be indirectly involved due totheir participation in the Scheduled Workflow, etc. are not necessarily shown. Image Display canparticipate in this profile if it is grouped with a Report Creator.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

DSS/ Order Filler↓ RAD-4: Procedure Scheduled↓ RAD-13: Procedure Update↑ RAD-42: Performed Work Status Update

ReportManager← RAD-46: Query Reporting Worklist← RAD-38: Workitem Claimed← RAD-41: Workitem Completed← RAD-39: Workitem PPS in Progress← RAD-40: Workitem PPS Completed

ReportCreatorReportReaderRAD-7: Modality PS Completed↑

Performed
Procedure
Step Manager

Image
Manager

Image
Archive← RAD-11: Image Availability Query

2910
Figure 13.1-1: Reporting Workflow Actor Diagram

2915

Table 13.1-1 lists the transactions for each actor directly involved in the Reporting Workflow
Integration Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile and that implementations may choose
to support is listed in Volume 1, Section 13.2.
Table 13.1-1: Reporting Workflow Integration Profile - Actors and Transactions
ActorsDepartment System Scheduler/
Order Filler

Image Manager/
Image Archive

Transactions

Optionality

SectionProcedure Scheduled [RAD-4]

R

4.4

Procedure Update [RAD-13]

R

4.13

Performed Work Status Update(Receive) [RAD-42]

R

4.42

Images Availability Query [RAD11]

R

4.11

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsReport Creator (Report
Reader)Report Manager

Performed Procedure Step
Manager

Transactions

Optionality

Query Reporting Worklist [RAD-46]

R

4.46

SectionWorkitem Claimed [RAD-38]

R

4.38

Workitem PPS In Progress [RAD-39]

R

4.39

Workitem PPS Completed [RAD40]

R

4.40

Workitem Completed [RAD-41]

R

4.41

Procedure Scheduled [RAD-4]

R

4.4

Images Availability Query [RAD11]

R

4.11

Procedure Update [RAD-13]

R

4.13

Query Reporting Worklist [RAD-46]

R

4.46

Workitem Claimed [RAD-38]

R

4.38

Workitem PPS In Progress [RAD39]

R

4.39

Workitem PPS Completed [RAD40]

R

4.40

Workitem Completed [RAD-41]

R

4.41

Performed Work Status Update(send) [RAD-42]

R

4.42

Modality Performed Procedure Step
Completed [RAD-7]

R

4.7

Modality Performed Procedure Step
Completed [RAD-7]

R

4.7

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

2920

13.1.1 Actor Grouping Clarification
Any system implementing the Report Manager will have some internal logic to determine when
images stored on the Image Manager are sufficient for the reporting workflow to begin. In somecases, it may not be necessary for a report to be generated. Generally these decisions are basedon the procedure code of the requested procedure.

2925

This profile is currently designed with the following grouping scenarios in mind:
Scenario 1:
The Report Manager is grouped with the Image Manager in System A. The DSS in System B
needs status information. In this case:

2930

System A claims support of the Reporting Workflow Profile as the Report Manager and ImageManager Actors.
System B claims support of the Scheduled Workflow Profile as the DSS Actor and implements
the optional Performed Work Status Update transaction.
Scenario 2:______________________________________________________________________________
140
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

2935

The Report Manager is grouped with the DSS in System A. The Image Manager in System B
needs status information. In this case:
System A claims support of the Reporting Workflow Profile as the Report Manager and DSS
Actors.
System B claims support of the Scheduled Workflow Profile as the Image Manager Actor.
Scenario 3:

2940

A Report Manager is implemented on a system A and is grouped with neither the DSS nor the
Image Manager. The DSS in system B needs status information. The Image Manager in System
C might or might not need the status information. In this case:
System A claims support of the Reporting Workflow Profile as the Report Manager Actor.

2945

System B claims support of the Scheduled Workflow Profile as the DSS Actor and implements
the Performed Work Status Update transaction.
System C claims support of the Scheduled Workflow Profile as the Image Manager Actor andmay implement the optional Performed Work Status Update transaction if the needed.
13.1.2 Input Availability

2950

2955

2960

2965

The Report Manager uses the Images Availability Query transaction to know when images areavailable in the Image Archive for query. The image set relevant for the reporting workflow
might or might not include all the instances the Report Manager has been notified about via
previous MPPS or/and GP-PPS messages related to a requested procedure. Based on the received
information and its internal logic the Report Manager decides which data the reporting workitem
input consists of.
Generally, the Reporting Manager will create a workitem in the reporting worklist when therequired images are available, although it may create the workitem before that with anincomplete Input Information Sequence and the Input Availability Flag set to PARTIAL. The
Reporting Manager and Report Creator must be able to handle workitems with PARTIAL image
availability in a stable way. The Report Creator may not display workitems with PARTIAL
status to the user for selection until their status later changes to COMPLETE. If the ReportCreator allows the user to select and start work on items with partially available input, then theReport Creator is responsible for monitoring the reporting worklist and make sure the user
receives the full data when it is available.
Similarly the Report Manager may choose to leave workitems with PARTIAL status out of theprovided worklist until the status is COMPLETE. If the Report Manager provides workitemswith partially available input data in the worklist, then a later check of the image availability andupdate of the workitem in the worklist may be expected even for workitems that have been
already claimed.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

13.2 Reporting Workflow Integration Profile Options
2970

Options that may be selected for this Integration Profile are listed in the Table 13.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 13.2-1: Reporting Workflow - Actors and Options
Actor
Department System Scheduler /Order Filler

OptionsVol. & Section

HL7 v2.5.1

RAD TF-1:13.2.1
RAD TF-2:4.4
RAD TF-2:4.13

Image Manager/
Image Archive

No options defined-

Report Creator

No options defined-

Report Manager

HL7 v2.5.1

Report Reader

No options defined

Performed Procedure Step Manager

No options defined

RAD TF-1:13.2.1
RAD TF-2:4.4
RAD TF-2:4.13-

2975

13.2.1 HL7 v2.5.1 Option

2980

The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in thetransactions referenced in Table 13.2-1. The actor shall permit configuration for each system thatit communicates with using the referenced transactions whether HL7 v2.3.1 or HL7 v2.5.1 isused. It is possible that the actor may receive HL7 v2.3.1 messages and send HL7 v2.5.1
messages or vice versa.
The specifications in the HL7 v2.5.1 Option maintain semantic equivalency with HL7 v2.3.1
implementations and the field correspondences are summarized in RAD TF-2 Appendix E.

13.3 Reporting Tasks
2985

2990

The process of report creation is considered to be composed of multiple tasks. The following
individual tasks have been identified:•Interpretation - the physician accesses the acquired images, reviews them and typicallygenerates either a draft report or dictation.

•

Interpretation and Dictation - the physician generates an audio file of dictatedobservations that will make up the diagnostic report’s content.

•

Transcription - the transcriptionist accesses the physician’s dictated report and generates
the transcribed text report.

•

Verification - the physician accesses the transcribed or draft report, confirms the text
content accuracy and generates the verified report.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

Review - the physician accesses the report, reviews the content and may generate either
an agreement or disagreement.

•

Comparison - the physician accesses two verified reports, reviews the content, andgenerates either a difference report or confirmation of similarity.

•

Coding - the coder accesses a draft or verified report, and assigns codes.

2995

3000

NOTE: Verification is considered to be different from a signature, although it may trigger a signature. A signature has
policies attached to it. It is not part of this Reporting Workflow profile.

In the report creation process, actors such as the report creator perform relevant workitems
obtained by querying the relevant worklist.

3005

3010

3015

Depending on the capabilities of the system containing the Report Creator Actor and thepermissions of the user, it may be possible to carry out several steps at once. For example, aspeech recognition workstation may support interpretation, dictation and transcription all at once,
and a senior physician may have authority to immediately verify the resulting report. In othersituations or implementations, it may be necessary to perform the steps separately. The types andsequence of tasks may vary from site to site. A sequential process made up of aninterpretation/dictation, a transcription and a verification task is very common, but can vary
between institutions.
The logic of determining what tasks to schedule and when to schedule them is the responsibilityof the Report Manager and is not defined by IHE. Typically, this logic will involve completionof pre-requisite tasks and/or availability of needed input objects. Much of the needed information
is available in the PPS Transactions from the Report Creators, Image Managers and other actors,
in the Image Availability Transaction to the Image Manager, and in reports stored to the ReportManager.

3020

The logic of presenting a relevant list of workitems to the user is the responsibility of the ReportCreator and is only partially defined by IHE in the Query Reporting Worklist transaction.
Typically, this will involve filtering the available workitems based on the Scheduled Workitem
Code (to find particular types of tasks), the Scheduled Human Performer (to find work for aparticular person), the Scheduled Station Name (to find work for a particular workstation),
Patient Name (to find work for a particular patient), Accession Number (to find work for aparticular order), or Procedure Step Status (to find work in a particular state).

3025

A number of common workitem codes are listed in Vol. III, Section 4.46 - Query Reporting
Worklist. Systems may allow sites to configure additional codes that reflect their local workflow
practices and can be used by the Report Creators to filter workitems.

3030

As the Report Creator completes tasks, it reports performed workitem codes to the ReportManager. This is particularly important when the Report Creator performs additional tasks as itenables the Report Manager to modify the workflow. Further robustness and flexibility isprovided by allowing the Report Creator to identify and suggest subsequent workitem codes in
the General Purpose Performed Procedure Step Results Module, giving the Report Manager
additional input to the logic it uses to select subsequent workflow steps in an adaptive manner.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3035

The following diagram (Figure 13.3-1, parts 1 & 2) gives an example of a full Reporting
Workflow from scheduling of the initial Interpretation/Dictation task, to the final release of theverified report. Prior to the start of this, images and evidence documents would have been stored
to the Image Manager and PPS transactions containing references to those objects sent to theReport Manager.
In this example, the Report Manager is grouped with neither the DSS nor the Image Manager,
and the DSS is acting as the Performed Procedure Step Manager.

3040

In the figure(s) below, there are parenthetic notations associated with most of the Query
Reporting Worklist and Workitem PPS In-Progress/ Completed transactions. These notes
indicate the Scheduled or Performed Workitem Codes associated with those transactions. For acomplete set of codes refer to Table 4.46-4 in Volume 3, section 4.46.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Acq
Modality

ReportManager

Image Manager/
DSS
Image Archive

ReportCreator/ Image
Display

Modality
Images Stored

ReportCreator/Report

ReportRepository

ReaderEvidence DocsStoredMPPS Completed

MPPS Completed
Images Available

Create Interpretation Worklist Task
Query Reporting
Worklist
Workitem Claimed(Interpretation)

Performed Work
Status (in progress)
Retrieve Images
Retrieve Evidence Docs
Workitem PPS
In Progress(Interpretation)

Interpretation& Dictation

Workitem PPS
Completed(Interpretation)
Workitem PPS
In Progress(Dictation)
Workitem PPS
Completed(Dictation)

Perform
Interpretation &Dictation
CreateAudio Report“External Audio Storage”

Workitem Completed
Create Transcription Worklist Task
Performed Work
Status (completed)

3045

Figure 13.3-1 (part 1): Reporting Workflow Overall Sequence______________________________________________________________________________
145
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Manager/
Image Archive

ReportCreator/ Image
Display

ReportManager

DSS

ReportCreator/ Report
ReaderReportRepository

Query Reporting Worklist(Transcription)
Workitem Claimed(Transcription)“Retrieve External Audio”

Performed Work
Status (in progress)
Workitem PPS In Progress(Transcription)

Perform
Transcription

Transcription

Report creation

Report Submission

Workitem PPS Completed(Transcription)
Workitem Completed
Performed Work
Status (completed)

Image Manager/
Image Archive

DSS

Create Verification Worklist Task

ReportManager

ReportCreator/ Image
Display

ReportCreator/ Report

ReportRepository

Reade

Query Reporting Worklist
Workitem Claimed(Verification)
Performed Work
Status (in progress)

Retrieve Report(Preliminary)Workitem PPS In Progress(Verification)
Perform Verification

Verification

Report Submission
Report Issuing(Verified)
Workitem PPS Completed(Verification)

ReportReaderWorkitem Completed
Performed Work
Status (completed)
Query Reports
Retrieve Reports

Figure 13.3-1 (part 2): Reporting Workflow Overall Sequence______________________________________________________________________________
146
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3050

13.4 Diagnostic Reporting Use Cases
This section describes diagnostic reporting creation uses cases. Each use case is a combination of
one or many reporting tasks. These use cases do not cover all reporting use cases. However, theirfeasibility is demonstrated.
13.4.1 Use case 1: Predefined Report

3055

The primary user is the reading physician. When interpreting a study, the user chooses a reportfrom a list of pre-configured draft reports and can edit the report’s content in order to customize
it. This use case covers the situation where the user can use a predefined/ canned report (which isfrequently the case when the results are normal), and has permission to verify the report.
This use case finally results in:

3060

•

multiple Performed Procedure Steps for each of the performed workitems Interpretation,
Transcription and Report Verification, each having a corresponding code value in the
Performed Workitem Code Sequence;•a report which has been verified and is referenced in the output results status message;•

removing the workitem from the worklist, after the workitem status was set to completed.

3065
The basic flow is illustrated in Figure 13.4-1______________________________________________________________________________
147
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ReportManager

Image Manager/
DSS
Image Archive

ReportCreator/ Image
Display

ReportCreator/Report
ReaderMPPS Completed
Images Available

Create Interpretation Worklist Task
Query Reporting
Worklist
Workitem Claimed(Interpretation)

Performed Work
Status (in progress)
Retrieve Images

Workitem PPS
In Progress(Interpretation)
Workitem PPS
Completed(Interpretation)

Report Creation

Verify Report

Workitem PPS
In Progress(Verification)
Workitem PPS
Completed(Verification)
Report Submission

Performed Work
Status (completed)

Workitem CompletedFigure 13.4-1 Use Case 1: Predefined Report

13.4.2 Use case 2: Workitem Deferred3070

The primary user can be the reading physician, the transcriptionist, or the verifying physician.
This use case takes place when the user starts to work on the workitem and decides not tocomplete it.
At the end of this use case the workitem status is set to scheduled and the workitem remains in
the worklist.

3075

The basic flow is illustrated in Figure 13.4-2 (optional transactions denoted by dotted lines).
Transactions Workitem PPS In Progress and Workitem PPS Completed are optional since some
implementations may let the user skip before sending these transactions______________________________________________________________________________
148
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Manager/
Image Archive

DSS

ReportManager

MPPS Completed

ReportCreator/Report

ReportCreator/ Image
Display

ReaderCreate Interpretation Worklist Task

Images Available

Query Reporting
Worklist

Performed Work
Status (in progress)

Work item Claimed

Query Images
Retrieve Images

Start
Interpretation

Work item PPS
in progress(in progress)

Work item PPS
Completed(discontinued)
Performed Work
Status (scheduled)3080

Work item
Completed(scheduled)

Figure 13.4-2 Use Case 2: Workitem Deferred

13.4.3 Use case 3: Direct Report Creation

3085

3090

The primary user is the reading physician. This use case takes place when the user creates thereport’s content. The user may define a template or choose a template from pre-defined ones tofill in. The major difference between this use case and the “Predefined Report” use case (13.4.1)
is that in this use case, the user is expected to have to perform more “customization/ tailoring” of
the report content (i.e., in contrast to the ‘canned report’ nature of the Predefined Report case).
At the end of this use case the workitem status is set to completed, the workitem is removed fromthe worklist, a report is generated, the output results status message references the generated
report, the suggested subsequent workitem is set to Report Verification and the multiple
Performed workitem code sequences include Interpretation and Transcription.
The basic flow is illustrated in Figure13.4-3.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
This use case has an extension when the user has verification permission. In this case thegenerated report is verified, and the multiple Performed workitem code sequences include
Interpretation, Transcription and Report Verification.
ReportManager

Image Manager/
DSS
Image Archive

ReportCreator/ Image
Display

ReportCreator/Report
ReaderMPPS Completed
Images Available

Create Interpretation Worklist Task
Query Reporting
Worklist
Workitem Claimed(Interpretation)

Performed Work
Status (in progress)
Retrieve Images

Workitem PPS
In Progress(Interpretation)
Workitem PPS
Completed(Interpretation)
Workitem PPS
Completed(Verification)

Report Creation
Report content created/edited by user

Extension: Verify
ReportReport Submission

Performed Work
Status (completed)

Workitem Completed

3095
Figure 13.4-3 Use Case 3: Direct Report Creation

13.4.4 Use case 4: Interpretation and Dictation
3100

The primary user is the reading physician. This use case takes place when the user dictates theinterpretation.
This use case finally results in:______________________________________________________________________________
150
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3105

•

multiple Performed Procedure Steps for each of the performed workitems Interpretation
and Dictation, each having a corresponding code value in the Performed Workitem Code
Sequence;•

an output results status message, referencing the generated audio file and suggesting its
Transcription as subsequent workitem;•

removing the workitem from the worklist, after the workitem status was set to completed.

The basic flow is illustrated in Figure 13.4-4 (optional transactions denoted by dotted lines).
3110

3115

NOTE: It is beyond the scope of the IHE Technical Framework to define the “External Audio Storage” transaction shownin this figure.

This use case has two variations. The first variation is when a voice recognition system isavailable at the Report Creator. In this case a report is generated, the output results reference thegenerated report, the suggested subsequent workitem is set to Report Verification, and two
Performed Procedure Steps are created each having a Performed Workitem Code Sequence valueof Interpretation or Transcription respectively. The second variation takes place when a voicerecognition system is available at the Report Creator and the user has verification permission. In
this case the generated report is verified, and three Performed Procedure Steps are created eachhaving a Performed Workitem Code Sequence value of Interpretation, Transcription or Report
Verification respectively.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Manager/
Image Archive

DSS

ReportManager

MPPS Completed

ReportCreator/Report

ReportCreator/ Image
Display

External Audio
Repository

ReaderCreate Dictation Worklist Task

Images Available
Query Reporting
Worklist(interpretation,
Dictation)
Performed Work
Status (in progress)

Work item Claimed
Query Images
Retrieve Images

Dictation

Perform
Interpretation,
Dictation
CreateAudio Report

Work item PPS
in progress(interpretation,
Dictation)“External Audio Storage”
Work item PPS
Completed(interpretation,
Dictation)
Performed Work
Status (completed)

Work item
Completed

Create Transcription Worklist Task

3120
Figure 13.4-4 Use Case 4: Interpretation and Dictation

13.4.5 Use case 5: Transcription
3125

The primary user is the transcriptionist. This use case can start when an audio file is available,
and takes place when the transcriptionist transcribes the audio content into a transcribed report.
This use case finally results in:•a Performed Procedure Step for Transcription, having a corresponding code value in its
Performed Workitem Code Sequence;•an output results status message, referencing the generated report and suggesting its
Verification as subsequent workitem;•

removing the workitem from the worklist, after the workitem status was set to completed.

3130

The basic flow is illustrated in Figure 13.4-5.
______________________________________________________________________________
152
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
NOTE: It is beyond the scope of the IHE Technical Framework to define the “Retrieve External Audio” transaction shownin this figure.
Image Manager/
Image Archive

DSS

ReportManager

ReportCreator/ Image
Display

ReportCreator/Report

External Audio
Repository

ReaderCreate Transcription Worklist Task
Query Reporting
Worklist (Transcription)
Performed Work
Status (in progress)

Work Item Claimed

Transcription“Retrieve External Audio”

Workitem PPS in progress(Transcription)

Perform
Transcription
Report creation

Report Submission

Performed Work
Status (completed)

Workitem PPS Completed(Transcription)
Workitem Completed
Create Verification Worklist Task

3135
Figure 13.4-5 Use Case 5: Transcription

13.4.6 Use case 6: Partial completion
The primary user is the reading physician.
3140

This use case happens when the user begins the task and then decides that this task cannot becompleted at this moment. The reason can be that more input is necessary to perform this tasksuch as additional image acquisition, post- processing (3D) or that the actual data is of bad
quality and new acquisition is required. This may require a new scheduling and a new workitem
when interpretation would be possible again

3145

At the end of this use case the workitem status is set to discontinued, and the workitem isremoved from the worklist.
The Report Creator may decide whether sending partial results to the Report Manager (via the
Workitem PPS transactions) is useful.
The basic flow is illustrated in Figure 13.4-6 (optional transactions denoted by dotted lines).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3150

Preferably the Report Manager would need to know about the reason for discontinuation.
However, this is not possible actually with the DICOM GP PPS transaction. It will be included
later when this becomes possible.
Image Manager/
Image Archive

DSS

ReportManager

MPPS Completed

ReportCreator/Report

ReportCreator/ Image
Display

ReaderCreate Interpretation Worklist Task

Images Available

Query Reporting
Worklist

Performed Work
Status (in progress)

Work item Claimed

Query Images
Retrieve Images

Work item PPS
in progress(in progress)
Start Interpretation
More input
neededWork item PPS
Discontinued(discontinued)

Performed Work
Status (discontinued)

Work item
Completed(dicontinued)

Create Modality/ post- processing
Worklist List

3155

Figure 13.4-6 Use Case 6: Partial Completion

13.4.7 Use case 7: Verification
The primary user is the verifying physician.

3160This use case can start when a non-verified report needs verification. Verification is aconfirmation of the correctness of the report’s content. It is NOT a legal signature. For DICOM
SR instances, verification results in setting the Verification Flag value to “VERIFIED”.
This use case finally results in:______________________________________________________________________________
154
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3165

•

a Performed Procedure Step for Report Verification, having a corresponding code value
in its Performed Workitem Code Sequence;•an output results status message, referencing the verified report;•

removing the workitem from the worklist, after the workitem status was set to completed.

The basic flow is illustrated in Figure 13.4-7.
Image Manager/
Image Archive

DSS

ReportManager

ReportCreator/Report

ReportCreator/ Image
Display

ReaderCreate Verification Worklist Task
Query Reporting
Worklist (Verification)
Performed Work
Status (in progress)

Work item Claimed

Query Reports
Verification
Retrieve Reports

Work item PPS in progress(Verification)
Perform Verification
Report Submission
Work item PPS
Completed(Verification)

Performed Work
Status (completed)

Work item CompletedFigure 13.4-7 Use Case 7: Verification

3170

This use case has an extension when the user needs to correct the report’s content by dictation. In
this case the report is not verified, the output results reference the unverified report and the audio
file, the Performed workitem code sequence includes Report Verification, and the suggested
subsequent workitem set to Transcription.
13.4.8 Use case 8: Double reading

3175

The primary user is the reading physician.
This use case takes place when two report objects are needed for the same requested procedure.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________The Report Manager generates two reporting workitems. Each workitem is processed separately
according to use cases 1 to 7. Once both verified reports are generated, they are comparedaccording to the comparison use case.
3180

13.4.9 Use case 9: Comparison
The primary user is the reading physician
This use case takes place when there are two verified reports for the same requested procedure to
be compared.

3185

At the end of this use case, the user finds the reports either similar or different. In the case of adisagreement, a discrepancy report is generated.
The basic flow is illustrated in Figure 13.4-8. This flow assumes that the reports being comparedhave been submitted to the Report Manager.
Image Manager/
Image Archive

DSS

ReportManager

ReportCreator/Report

ReportCreator/ Image
Display

ReaderCreate comparison Worklist Task
Query Reporting
Worklist
Performed Work
Status (in progress)

Work item Claimed
Query Reports

Comparison

Retrieve Reports

Work item PPS
in progress(in progress)

Perform comparison

Report Submission

Create ”discrepancy”
reportWork item PPS Completed(completed)

Performed Work
Status (completed)

3190

Work item
Completed(completed)

Figure 13.4-8 Use Case 9: Comparison______________________________________________________________________________
156
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
13.4.103195

Use case 10: Review

The primary user is the reading physician. This use case takes place when the user needs toreview the report’s content already verified by another physician. For example, this can happen
when a physician returns from vacation and must review the work done on his behalf by acolleague. In this case, the Report Manager would schedule Review workitems either based on arequest from the user, the administrator, or automatically based on department policy and theuser being marked as “back”.
Another scenario is in an “educational setting” where a ‘student’ is given a list of reports done bya more senior colleague to review with the purpose of learning from it.

3200

13.4.11

Use case 11: Over Read

The primary user is the reading physician. This is often done for the purposes of quality
assurance on the reading process.

3205

In this use case the Report Manager generates two reporting workitems for the same requested
procedure intended to be performed sequentially. The first verified report is used as input into
second reporting workitem. Each workitem is processed separately according to use cases 1 to 7.
At the end of this use case, the user performing the “over read” either agrees or disagrees withthe original report’s content. In the case of an agreement, an additional ‘Verifying Observer
Sequence’ is added to the original report object. In the case of a disagreement, a discrepancy
report is generated.

3210______________________________________________________________________________
157
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

14 Evidence Documents (ED)3215

The Evidence Documents Profile allows detailed non-image information, such as measurements,
CAD results, procedure logs, etc. to be made available as input to the process of generating adiagnostic report either as additional evidence for the reporting physician or in some cases forselected items in the Evidence Document to be included in the diagnostic report.
The process of creating and using Evidence Documents can be managed by worklists thatprovide patient/ procedure details and by performed procedure steps that report status
information (e.g., see Integration Profiles on Scheduled Workflow, Post-Processing Workflow,
Reporting Workflow).

3220

3225

Evidence Documents represent one of the inputs to the reporting process described in theReporting Workflow Profile and may provide details which get included in diagnostic reports
described in the Simple Image & Numeric Reports Profile.
It should be noted that while Key Image Notes meet the definition of Evidence Documents, they
are a special case which is dealt with separately in the Key Image Notes Profile for historicalreasons.

14.1 Actors/Transactions
Figure 14.1-1 shows the actors directly involved in the Evidence Documents Integration Profileand the relevant transactions between them. Other actors that may be indirectly involved due totheir participation in Scheduled Workflow, etc. are not necessarily shown.

Evidence Creator

StorageCommitment: RAD-10↓

Image
Manager

StorageCommitment: RAD-10 ↑Image Display↓ RAD-43: Evidence
Documents
S dReportCreator↓ RAD-44: Query Evidence Documents↓ RAD-45: Retrieve Evidence Documents

Image
Archive↑ RAD-43: Evidence
Documents
S dAcquisition Modality

3230
Figure 14.1-1: Evidence Documents Actor Diagram______________________________________________________________________________
158
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3235

Table 14.1-1 lists the transactions for each actor directly involved in the Evidence Documents
Profile. In order to claim support of this Integration Profile, an implementation must perform therequired transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of
options defined by this Integration Profile and that implementations may choose to support islisted in Volume 1, Section 14.2.
Table 14.1-1: Evidence Document Integration Profile - Actors and Transactions
ActorsEvidence Creator
Acquisition Modality
Image Manager/
Image Archive

Image Display (ReportCreator)Transactions

OptionalitySectionStorage Commitment [RAD-10]

R

4.10

Evidence Documents Stored [RAD-43]

R

4.43

Storage Commitment [RAD-10]

R

4.10

Evidence Documents Stored [RAD-43]

R

4.43

Storage Commitment [RAD-10]

R

4.10

Evidence Documents Stored [RAD-43]

R

4.43

Query Evidence Documents [RAD-44]

R

4.44

Retrieve Evidence Documents [RAD-45]

R

4.45

Query Evidence Documents [RAD-44]

R

4.44

Retrieve Evidence Documents [RAD-45]

R

4.45

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile.

3240

If a Report Creator wishes to participate in this profile, it does not have to support any
transactions directly, however it is required to be grouped with an Image Display in order to beable to Query/Retrieve the Evidence documents, and the Report Creator is expected to be able totransfer some contents of the retrieved document into the report it creates.

14.2 Evidence Documents Integration Profile Options
3245

Options that may be selected for this Integration Profile are listed in the Table 14.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 14.2-1: Evidence Documents - Actors and Options
Actor

OptionsVol. & Section

Evidence Creator

No options defined--

Acquisition Modality

No options defined--

Image Manager/
Image Archive

No options defined--

No options defined--

No options defined--

No options defined--

Image Display(Report Creator)______________________________________________________________________________
159
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3250

3255

The Evidence Creator, Acquisition Modality and Image Manager/ Image Archive will likely
support a variety of DICOM SOP Classes. Each DICOM SOP Class that is supported by theactor shall be listed in the product’s DICOM Conformance Statement. The IHE Integration
Statement (see appendix D) shall reference the DICOM Conformance Statement but does notrepeat the list of DICOM SOP Classes that are considered to contain Evidence Documents.
Examples of DICOM SOP Classes that may contain evidence are listed in RAD TF-3: 4.43,
Table 4.43-1 and Table 4.43-2.

14.3 Evidence Document Process Flow
Evidence Documents belong to the family of Evidence Objects that also includes Images,
Presentation States, and Key Image Notes. These are objects generated as a result of performing
procedure steps on systems in a clinical department.
3260

The start and completion of creating Evidence Documents is reported in the Scheduled
Workflow Profile by the Evidence Creator using Creator Procedure Step In-Progress/Completed
transactions, or by the Acquisition Modality using the Modality Procedure Step InProgress/Completed; and in the Post-Processing Workflow by the Evidence Creator using theWorkitem Procedure Step In-Progress/Completed transactions.

3265

As with other Evidence Objects, Evidence Documents are usually created by the system
operator, and used by the reading physician in the process of creating a Diagnostic Report, either
by reviewing or interpreting the Evidence Document contents, or by copying selected parts into
the Report. Evidence Documents represent the uninterpreted information that is primarily
managed and used inside an imaging department, although distribution outside the imaging
department is not precluded. In contrast, the diagnostic reports described in the Simple Image
and Numeric Reports Profile represent the interpreted information which is the primary output of
the imaging department and are available for wide distribution.

3270

3275

3280

Due to the difference between the way the Evidence Creator reports status in the Scheduled
Workflow Profile (using a Creator Procedure Step transaction to the Performed Procedure Step
Manager) and the way the Evidence Creator reports status in the Post-Processing Workflow
Profile (using a Workitem PPS transaction to the Post-Processing Workflow Manager), two
examples of the process flow will be shown below.
The scheduling part of the workflow that would typically precede the part of the workflow in thefollowing diagram can be seen in Fig. 3.2-1 (Administrative Process Flow) in the Scheduled
Workflow Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Department System
Scheduler/ Order
FillerEvidence Creator/
Image Display

Image Manager/
Image Archive

Image Display/
Report Creator

Query Images
Retrieve Images
Creator Procedure
Step In Progress

Creator Procedure
Step In Progress

Evidence Document
StoredCreator Procedure
Step Completed

Perform
Measurements

Creator Procedure
Step Completed
StorageCommitment

Query Evidence Documents
Retrieve Evidence Documents

Apply
Measurements

Figure 14.2-1: Evidence Document Management In Scheduled Workflow

3285

Note that the Procedure Step transactions and the Query/ Retrieve Images transactions in theabove diagram are not part of the Evidence Documents Profile.
The scheduling part of the workflow that would typically precede the part of the workflow in thefollowing diagram can be seen in Fig. 12.3-1. (Post-Processing Manager Grouped with
Department System Scheduler) in the Post-Processing Workflow Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Image Manager/
Image Archive

DSS /Post-Processing
Manager(CAD System)
Evidence Creator/
Image Display(Review)
Image Display

Query Post-Processing Worklist
Performed Work
Status Update (Started)

Workitem Claimed(CAD)
Retrieve Images
Workitem PPS
In Progress

Evidence Documents Stored

Perform
CAD Processing

Storage Commitment
Worktiem PPS
Completed

Performed Work
Status Update(Completed)

WorkitemCompleted(CAD)

Query Evidence Documents
Retrieve Evidence Documents

3290
Figure 14.2-2: Evidence Document Management In Post-Processing Workflow

Note that the Worklist and Workitem transactions in the above diagram are not part of the
Evidence Documents Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

15 Portable Data for Imaging Integration Profile
3295

3300

The Portable Data for Imaging Integration Profile specifies actors and transactions thatprovide for the interchange of imaging-related information on interchange media. The intent of
this profile is to provide reliable interchange of image data and diagnostic reports for import,
display or print by a receiving actor.
This profile addresses identification of the media content’s source and the patient (whereappropriate), reconciliation of data during import, and the structure of the media contents.
The central elements of the profile are:

3305

•

Reliable interchange of imaging-related information based on the DICOM standard•

A Web Content Option that provides guidelines for including web-viewable content on
media

The Web Content Option addresses the case of media containing both DICOM-encoded objects
and objects in XHTML or JPEG derived from these DICOM-encoded objects.

15.1 Actors/ Transactions
Figure 15.1-1 diagrams the actors directly involved in this profile and the transactions between
actors.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________→ RAD-47: Distribute Imaging
Information on Media

Display→ RAD-47: Distribute Imaging
Information on Media→ RAD-47: Distribute Imaging
Information on Media→ RAD-47: Distribute Imaging
Information on Media

PortableMedia
Creator→ RAD-47: Distribute Imaging
Information on Media

Image
Display

ReportReaderPrint
Composer
Portable
Media
Importer

3310
Figure 15.1-1: Portable Data for Imaging Diagram

3315

3320

Table 15.1-1 lists the transactions for each actor directly involved in the Portable Data for
Imaging Profile. In order to claim support of this Integration Profile, an implementation shallperform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile is listed in RAD TF-1: 15.2. Note that
one of a number of actors must be grouped with Portable Media Importer as described in RAD
TF-1: 2.5.
Table 15.1-1: Portable Data for Imaging Integration Profile - Actors and Transactions
ActorsTransactions

Optionality

Vol. 2/3 Section

Portable Media Creator

Distribute Imaging Information on
Media [RAD-47]

R

4.47

Portable Media Importer

Distribute Imaging Information on
Media [RAD-47]

R

4.47

Image Display

Distribute Imaging Information on
Media [RAD-47]

R

4.47

Report Reader

Distribute Imaging Information on
Media [RAD-47]

R

4.47

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Transactions

Optionality

Vol. 2/3 Section

Print Composer

ActorsDistribute Imaging Information on
Media [RAD-47]

R

4.47

Display (ITI TF)

Distribute Imaging Information on
Media [RAD-47]

R

4.47

15.2 Portable Data for Imaging Integration Profile Options

3325

Options that may be selected for this Integration Profile are listed in Table 15.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified innotes.
Table 15.2-1: Portable Data for Imaging - Actors and Options
Actor

OptionsVol. & Section

Portable Media Creator

Web Content

RAD TF-1: 15.4.2
RAD TF-2: 4.47.4.1.2

Portable Media Importer

No options defined-

Image Display

No options defined-

Report Reader

No options defined-

Print Composer

No options defined-

Display (ITI TF)

No options defined-

15.3 Portable Data for Imaging Process Flow
3330

This section describes the typical process flow related to the use of Interchange Media. The
transaction covered is RAD- 47 – Distribute Imaging Information on Media.
The following steps can be identified in this process flow:•

The source actor (Portable Media Creator) writes a group of image dataset(s) and/or the
associated diagnostic report(s) onto a piece of interchange media. It is presumed that thePortable Media Creator has access to the data from a grouped actor, or another source
outside the scope of IHE.

•

The media is physically transported to a destination where the imaging-related
information contained on the media will be used.

•

The Portable Media Importer reads DICOM objects (images, presentation states, key
image notes, evidence documents and reports) on the media and imports them into the
local information space. The Portable Media Importer reconciles the data as needed (e.g.,
to change the recorded Patient ID to the local Patient ID). If some classes of DICOM
objects are present on the media and cannot be imported, the Portable Media Importer

3335

3340

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
actor notifies the operator of the studies and series affected and makes clear that they are
not supported by the importing application.

3345
•

3350

The Image Display, Report Reader, Display or Print Composer reads the objects it
supports and renders them depending on the receiver’s needs. If some objects are notsupported by the reading application it notifies the operator that those objects are notsupported.

The potential usage scenarios of the data are described in the use cases below.
15.3.1 Use Cases
This profile is not intended to provide an archival solution.

3355

3360

Use Case 1 - Patient/Referring Physician Viewing: Diagnostic and therapeutic imaging data,such as images and reports, is received on media potentially serving multiple use cases. The
patient or the referring physician can view the data, either with a viewer application residing on
the same media or using a web browser. This data is not necessarily intended as a basis fordiagnostic or therapeutic processes, and may just be informative data. For security and privacy
reasons, media given to a patient would not contain data of other patients. Refer to section 15.5
for additional security considerations.
Use Case 2 - Healthcare Enterprise Interchange: One or more patients’ data, such as images,
reports or complete studies, is received on media to enable a diagnostic or therapeutic care
process. Media data are imported at a different site, generally for the purpose of a “second readimport” or “reference import”.
•

Second Read Import: Media data is imported to the Image Manager/Archive to beread/over read. In order to avoid data conflicts, key patient/study attributes may need tobe reconciled with existing local data. Images and related presentation states can be sent
to a Print Composer to be printed.

•

Reference Import: Media data is imported to the Image Manager/Archive and/or Report
Repository to become part of the patient history. It may be used as “relevant prior” data
for future reads. In order to avoid data conflicts, key patient/study attributes may need tobe reconciled with existing local data.

3365

3370

3375

Use Case 3 - Operating Room Viewing: Media data is used to enable diagnostic or therapeutic
processes in environments without a reliable network connection. The volume of data can bevery large and may contain image data, post-processing results and reports. In the operating
room, the surgical staff receives the media and reads its contents using advanced viewing
capabilities, which may include manipulating or processing images.
15.3.2 Process Flow Description
The use cases can be specified in terms of three media-related activities:

3380

•

Media Export•

Media Viewing______________________________________________________________________________
166
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•Media ImportMedia Export (All Use Cases):
The Portable Media Creator assembles the media content (DICOM and web-viewable content)
and writes it to the physical medium.
3385

The following sequence of activities will be performed during media creation:

3390

•

Export of DICOM data (FSC activity).

•

Optionally, export of web-viewable data, which involves deriving easily accessible
informative data from the DICOM data (Web Content Option).

•

Optionally, inclusion of additional content (e.g., a DICOM Viewer or viewing software
components on the media to access DICOM data).

B) Media Viewing:
B1) Web (Use Case 1) (care providers, other users and patients without DICOM viewing
equipment or software):3395

Any web-viewable media content is received and displayed by a Display Actor, which
exists as a generally available resource (i.e., web browser). Note that the Portable MediaCreator cannot rely on the presence of web-viewable content on all media since it will be
included only on media created using the Web Content Option).
B2) DICOM (Use Case 1 and 3) (users with DICOM viewing equipment or software):3400

The DICOM portion of the media content is displayed using specialized applications preexisting in the reading environment or included on the media itself. The variety of
DICOM objects that an Image Display and/or Report Reader Actor can process isindicated by its support of the corresponding content profiles. The Print Composer Actor
sends images from the media to a Print Server for printing.

3405

C) Media Import (Use Case 2):

3410

The “Media Import” activity is accomplished by a Portable Media Importer and deals
exclusively with the DICOM portion of the media content. The Portable Media Importer Actor isgrouped with one or more content actors (Evidence Creator, Report Creator, etc.), depending on
the type of media content to be imported. The grouped actor provides storage capability for the
media data accessed by the Portable Media Importer.
The Portable Media Importer Actor accesses all DICOM instances referenced by the
DICOMDIR file and enables the user to select a media patient dataset to be imported.
•

3415

The Portable Media Importer obtains local data that is known to be accurate within theimporting institution/enterprise and reconciles “key attributes” of patient and study
information (when required). A method for performing these steps is documented in the______________________________________________________________________________
167
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Import Reconciliation Workflow Profile (see Section 3.21). Refer to RAD TF-3: 4.47.4.1.3
for the list of “key attributes” and the related reconciliation actions to be performed.
Note:

3420

3425

The Portable Media Importer may for example be grouped with an Evidence Creator to allow the storage of its
diagnostic and therapeutic imaging content to an Image Manager/Image Archive, or grouped with a ReportCreator to store reports on a Report Repository. This enables use of the content for subsequent “relevant prior”
data for future reads. A grouping with an Acquisition Modality Actor could also be used to allow subsequent“reads/over reads”. In the case of a Portable Media Importer grouped with the Print Composer Actor, theimported content (images and presentation states) can be sent to the Print Server to be printed.

Figure 15.3.2-1 shows an example flow of events covering the use cases described in theprevious sections.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
PortableMedia Creator

ExportWeb
Viewing

DICOM
Viewing

Display

Evidence ReportCreator Creator

Image
Display

Portable
Media
Importer

ReportImage
Manager/ Manager
Archive

Assemble
Media
Content

Distribute
Imaging
Information on
Media
Distribute
Imaging
Information on
Media

Web
Viewing

Access
DICOM
Directory
Info
Evidence
ObjectDisplay

Access
DICOM
Directory Info

Distribute
Imaging
Information on
Media

Reconcilepatient/study
data on mediausing data
locally obtained

ImportStore Diagnostic
Reports
Report Submission
Store Evidence
ImagesCreator Images Stored

Figure 15.3.2-1: Portable Data for Imaging Process Flow______________________________________________________________________________
169
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

15.4 Media Content
3430

3435

The requirements on media content are intended to promote the reliable transfer of imaging data,
including diagnostic reports, and to allow for the viewing of images and reports on general
purpose computers.
The media content can be accessed via two "entry points" on the media: the DICOMDIR file for
DICOM imaging information and optionally the INDEX.HTM file for web-viewable content.
Created media are required to contain DICOM data and may optionally include web-viewabledata derived from it. This web-viewable data, if present, shall faithfully preserve the clinicalintent of the original DICOM information.
15.4.1 DICOM Content

3440

The DICOM data shall be created by using the DICOM General Purpose Media Storage
Application Profile. The DICOMDIR file shall reference all DICOM files stored on the media.
DICOM files shall not be placed in the root directory, but no constraints are placed on the nameof directory that contains them.
15.4.2 Web Content Option

3445

Portable Media Creators implementing the Web Content Option may also include web-viewabledata on the media.
The web-viewable data shall be derived from the DICOM information as XHTML files andreferenced JPEG images. The XHTML entry page (INDEX.HTM) shall allow access to all of
this data. This enables end-users to access relevant media content using a generally available
web browser. The INDEX.HTM file shall be placed in the root directory.

3450

3455

Note that the web-viewable data specified in this integration profile reflects the full set of theexported DICOM data or a subset considered at the time of creation to faithfully represent thepatient's clinical condition. For example, if a DICOM Structured Report references only Key
Images and a larger DICOM dataset, the web-viewable data derived from it may selectively
include the report in XHTML format and only JPEG images derived from the DICOM Key
Images.
15.4.3 Other Content

3460

Viewing applications (for example a DICOM Media Viewer) may optionally be included on the
media. Such viewers may have launch links included in the HTML. Including such viewers on
the media is discouraged due to security issues discussed in the next section, as well as potential
interoperability problems.

3465

Additional data (e.g., a diagnostic report in non-DICOM format) may be also included on the
media. Since the format of any such data is not specified by this profile, such data shall be placedin a separate directory on the media. If such data is referenced in the INDEX.HTM file, it shallbe clearly indicated that this content was not generated in conformance with the IHE Radiology
Technical Framework, and its reliable import has not been addressed.
______________________________________________________________________________
170
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

15.5 Security and Privacy Aspects
Portable Media Creator Actors shall ensure that no malicious software (viruses, etc.) is present
on created media.
3470

The automatic launch of applications from media poses a risk that malicious software could bestarted and it is recommended that media reading actors not allow automatic launching. Portable
Media Creators should therefore also avoid using automatic launching. This includes not
automatically launching a DICOM media viewer that may be present on the media.
Furthermore, if a DICOM media viewer is present, security issues are minimized by:•working under normal (restricted) user privileges and not requiring the user to work withadministrator or root privileges and•not needing software installed on the computer where the media is used.

3475

Audit trails to track export/import/viewing activities are addressed in ITI TF-2: 3.20 and RAD
TF-3: 5.1. Portable Media Creator and media reading actors that claim support of the Audit Trailand Node Authentication Integration Profile shall generate such audit trail entries.
3480

Encryption of data and other access controls to media content are not addressed in this profile.
Media created using this profile should be considered to be unlocked information (e.g., like
paper records). Such media should be handled according to appropriate site policies (e.g., do notgive a patient a disk containing data from other patients, do not leave disks where they can betaken by unauthorized persons, etc.).

3485

For many Use Cases it is not appropriate to place data from multiple patients on a single media
for Security and Privacy Reasons.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

16 NM Image Integration Profile
The NM Image Profile specifies how NM Images are to be stored by Acquisition Modalities andEvidence Creator workstations and how Image Displays should retrieve and make use of them.
3490

It defines the basic display capabilities Image Displays are expected to provide, (such as might
be sufficient for a referring physician) but does not address advanced review features.
It also defines how result screens, both static and dynamic, such as those created by NM Cardiac
Processing Packages, should be stored using DICOM objects that can be displayed on general
purpose Image Display systems.

3495

3500

Note that the NM Image Profile is undergoing revision, and vendors considering implementation
are advised to include the modifications contained in the trial implementation version “NMImage Profile with Cardiac Option”. For additional information please contact the IHE
Radiology Technical Committee at IHE-Rad-Tech@googlegroups.com.
The NM Image Profile can be enhanced by combining it with workflow profiles such as
Scheduled Workflow, Post-Processing Workflow and Reporting Workflow which address how
to schedule, manage and report the status of the steps in which NM Image objects are created.

16.1 Actors/ Transactions

3505

Figure 16.1-1 shows the actors directly involved in the NM Image Integration Profile and therelevant transactions between them. Other actors that may be indirectly involved due to their
participation in the Scheduled Workflow Profile, the Post-Processing Workflow Profile, etc. are
not necessarily shown.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Evidence Creator

RAD-18: Creator
Images Stored ↓Image
Manager

RAD-8: Modality Images
Stored↑Image Display↓ RAD-10: Storage Commitment↓ RAD-14: Query Images↓ RAD-16: Retrieve Images

Image
Archive↑ RAD-10: Storage Commitment

Acquisition Modality

Figure 16.1-1: NM Image Actor Diagram

3510
Table 16.1-1 lists the transactions for each actor directly involved in the NM Image Profile. In
order to claim support of this Integration Profile, an implementation must perform the required
transactions (labeled “R”). Transactions labeled “O” are optional.
3515

A complete list of named options defined by this Integration Profile and that implementations
may choose to support is listed below in Section 16.2.
Table 16.1-1: NM Image Integration Profile - Actors and Transactions
ActorsAcquisition Modality
Evidence Creator
Image Manager/Archive

Image Display

Transactions

Optionality

Sectionin Vol. 2

Modality Images Stored [RAD-8]

R

4.8

Storage Commitment [RAD-10]

R

4.10

Creator Images Stored [RAD-18]

R

4.18

Storage Commitment [RAD-10]

R

4.10

Modality Images Stored [RAD-8]

R

4.8

Creator Images Stored [RAD-18]

R

4.18

Storage Commitment [RAD-10]

R

4.10

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
To participate as an evidence creator in Nuclear Medicine, the system must create derivative datafrom original NM modality image data. Examples of such derivative data include:
3520a) Reconstruction, reorientation, filtering, or other processing of NM data, with output of
NM modality image objects.
b) Quantization of NM data, with the display and storage of result screens as SC or
MFSC image objects.
c) Registration between an NM data set and another data set.

3525

3530

For all NM modality objects created, the evidence creator must meet the requirements of an
acquisition modality with respect to encoding, storage, and inclusion of required DICOM tags, as
noted in 4.8.4.1.2.2.
If the system creates SC or MFSC objects, the evidence creator is encouraged to support the
Result Screen Export option, and conform to the requirements of this option for any stored result
screens.

16.2 NM Image Integration Profile Options
Options that may be selected for this Integration Profile are listed in the Table 16.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
3535

Table 16.2-1: Evidence Documents - Actors and Options
Actor

Options

Acquisition Modality

No options defined

Evidence Creator
Image Archive/Manager
Image Display

3540

Result Screen Export Option

Vol. & Section
RAD TF-2: 4.18.4.1.2.4
RAD TF-2: 4.16.4.2.2.4

No options defined
Review Option

RAD TF-2: 4.16.4.2.2.2.5

The NM Image Profile is designed to provide faithful and complete storage and retrieval of NM
data and sufficient display functionality to allow adequate review of nuclear medicine images byreferring physicians. It should also be sufficient for secondary review (without reprocessing
capability) of cardiac nuclear medicine studies by cardiologists and for correlation of nuclear
medicine images with other imaging modalities during review by general radiologists.
The Review Option is intended to add functionality for primary (non-cardiac) NM interpretation.
The Result Screen Export Option adds functionality for storing Result Screens (which may bestatic or may contain moving components) in commonly displayable DICOM formats.

3545

Acquisition Modality Actors which support Result Screen Export should claim the appropriate
options as an Evidence Creator.
Processing functions of both cardiac and non-cardiac data are not addressed in this profile, andshould be performed on a dedicated NM workstation.
______________________________________________________________________________
174
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

16.3 NM Image Process Flow
Acquisition
Modality

Perform
Acquisition

Evidence Creator/
Image Display

Image Manager/
Image Archive

Image Display

Modality Images
Stored - NM Images
StorageCommitment

Query Images
Retrieve Images NM Images
Creator Images Stored- Result Screens

Generate
Result ScreensStorageCommitment

Query Images
Retrieve Images - NM Images
Retrieve Images - Result Screens

3550

Present NM Images& Result Screens
to User

Figure 16.3-1: NM Image Process Flow

The process of creating, storing and using NM Image content can be managed in much the same
way as other image content using the Scheduled Workflow and Post-Processing Workflow
Profiles. Examples of NM Workflow and Guidelines for carrying it out using the two mentioned
Workflow Profiles can be found in Appendix E: Nuclear Medicine.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3555

3560

17 Teaching File and Clinical Trial Export (TCE)This profile defines a means of selecting the relevant images, key image notes, reports, evidence
documents and presentation states on the Export Selector (which would typically be groupedwith an Acquisition Modality, Image Display, Evidence Creator or Report Creator), a means toenter additional information at that time, a means of transfer to an Export Manager Actor whose
behavior is defined, and a means of transfer to a Receiver Actor whose behavior is not defined(but which might be a teaching file authoring or distribution system, clinical trial image
management system, or a publication authoring system or might be grouped with an ImageManager/Archive or Portable Media Creator).

17.1 Actors/Transactions
3565

Figure 17.1-1 shows the actors directly involved in the Teaching File and Clinical Trial Export
Integration Profile and the relevant transactions between them. Other actors that may be
indirectly involved due to their participation in Key Image Note, Consistent Presentation of
Images, Evidence Document, Simple Image and Numeric Report and Portable Data for Imaging
Profiles, etc. are not shown.

ExportSelector↓ Store Export Selection [RAD-51]

Store Instances[RAD-50] ↓↓ Store Additional Teaching File Inform ation [RAD-52]

ExportManager
Export Ins tances[RAD-53] ↓Receiver3570
Figure 17.1-1: Teaching File and Clinical Trial Export Actor Diagram

3575

Table 17.1-1 lists the transactions for each actor directly involved in the Teaching File andClinical Trial Export Profile. In order to claim support of this Integration Profile, animplementation must perform the required transactions (labeled “R”). Transactions labeled “O”
are optional. A complete list of options defined by this Integration Profile and that
implementations may choose to support is listed in Volume 1, Section 17.2.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Table 17.1-1: Teaching File and Clinical Trial Export Integration Profile - Actors andTransactions
ActorsExport Selector

Export Manager

Optionality

Sectionin Vol. 2 /3Store Instances [RAD-50]

R (see Note)

4.50

Store Export Selection [RAD-51]

R

4.51

Store Additional Teaching File
Information [RAD-52]

O

4.52

R (see Note)

4.50

Store Export Selection [RAD-51]

R

4.51

Store Additional Teaching File
Information [RAD-52]

R

4.52

Export Instances [RAD-53]

R

4.53

Export Instances [RAD-53]

R

4.53

Store Instances [RAD-50]

Receiver3580

Transactions

Note: If the Export Manager is grouped with an Image Manager/Archive, there is no need for RAD-50 Store Instancestransactions between the Export Selector and the Export Manager as long as the instances are already available to
the Export Manager.

17.2 Teaching File and Clinical Trial Export Integration Profile Options

3585

Options that may be selected for this Integration Profile are listed in the Table 17.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 17.2-1: Teaching File and Clinical Trial Export - Actors and Options
Actor

OptionsVol. & Section

Export Selector

Additional Teaching File Information

RAD TF-1: 17.2.3
RAD TF-3 4.52

Delay for Reason

RAD TF-1: 17.2.4
RAD TF-3 4.51.4.1.5

De-identify Pixel Data

RAD TF-1: 17.2.1
RAD TF-3 4.51.4.1.4.4

Remap Identifiers

RAD TF-1: 17.2.2
RAD TF-3 4.51.4.1.4.3

Export Manager

ReceiverAdditional Teaching File Information

RAD TF-1: 17.2.3
RAD TF-3 4.52

Delay for Reason

RAD TF-1: 17.2.4
RAD TF-3 4.51.4.1.5

Additional Teaching File Information

RAD TF-1: 17.2.3
RAD TF-3 4.53______________________________________________________________________________
177
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
17.2.1 De-identify Pixel Data Option
3590

3595

In the default case, the Export Manager is responsible for de-identifying instances by removing
the necessary DICOM attributes or replacing them with alternative identification values(pseudonymization), without invalidating the IOD. This operation would normally be fully
automated, usually according to some pre-configured set of rules.
If identification is burned in to the pixel data however, as is commonly the case with Ultrasoundand Secondary Capture images, it is difficult to remove this automatically. Accordingly, a humanoperator would use an appropriate user interface to “black out” offending areas of text.
This named option requires that the capability to remove the offending information be present,
and that images shall not be forwarded as de-identified and pseudonymized until it has been
confirmed that burned in identification is no longer present.

3600

The option does not specify constraints on how this capability might be implemented, either interms of workflow, such as providing an internally managed work list for operators or userinterface features, such as the size, shape and number of graphic operations needed for editing
the pixels.
17.2.2 Remap Identifiers Option

3605

3610

For teaching file applications, it is rarely necessary to exercise much control over the identifiers
that are generated and used to replace the patient identifiers. As long as valid and globally unique
UIDs are generated, and other identifiers are replaced with values that do not invalidate the IOD,
they may be sequential or arbitrary or random.
For clinical trial applications this may be sufficient as long as the receiving site is informed of
the new arbitrary identifiers and to which trial subject they correspond through some out of bandmechanism, such as a data transmittal form.
However, clinical trial workflow is greatly enhanced if the subject enrollment list is used toremap the patient’s actual identifiers to the trial subject identifiers, and additional clinical trial
attributes are inserted into the header. Provision of such a capability is the “remap identifiers
option”.

3615

Further, in some protocols, the list of expected studies and their mapping to pre-defined time
points is known in advance, and the remapping capability could take advantage of thisknowledge, if available.
This named option requires that such a remapping capability be present.

3620

The option does not specify constraints on how this capability might be implemented, either interms of configuration, such as providing a user interface or preloading capability for the subject
enrollment list or remapping table, or sophistication, such as providing rule-driven generation of
UID and text values at either the patient or the study level.
This option does require that at minimum specific attributes be added or remapped; see thedescription of the Store Export Selection transaction [RAD-51] in RAD TF-3 4.51.4.1.4.3.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3625

17.2.3 Additional Teaching File Information Option

3630

The manifest of instances to be exported (the Export Selection) consists of references only, withno additional information. To allow for the user of the Export Selector to not only flag instancesfor export, but also to add additional information such as text and codes, a named option is
specified that provides for the support of a specific transaction Store Additional Teaching File
Information [RAD-52]. This allows additional information to be encoded in one or more
Structured Report instances that may be stored and included in the set of instances to beexported. The Store Export Selection [RAD-51] Key Object Selection document references the
Additional Teaching File Information SR instances. Once pseudonymized, this information isexported using the Export Instances transaction [RAD-53] just like any other instance.

3635

17.2.4 Delay for Reason Option

3640

Images may have been selected for teaching before the final pathological diagnosis or otherinformation is known, yet may need to be de-identified before transfer to the authoring system,
after which additional material cannot be linked. Since such information may be important to theintegrity of the teaching file, this option defines a mechanism for the Export Manager to delayexport until the system has received the specified information, and then to forward both to the
Receiver.

17.3 Implementation Issues
This profile is designed with the following implementation scenarios in mind:
Scenario 1:
3645

The Export Manager is grouped with an Image Manager/Archive. In this case, there is no needfor RAD-50 Store Instances transactions between the Export Selector and the Export Manager,
as long as the instances are already available to the Export Manager.
Scenario 2:

3650

The Export Manager is not grouped with an Image Manager/Archive. In this case, RAD-50 Store
Instances transactions between the Export Selector and the Export Manager are used to make theinstances available to the Export Manager.
Scenario 3:
The Receiver is grouped with a Portable Media Creator and claims support of the Portable Datafor Imaging Profile. In this case the instances and manifest received are recorded to media.

3655

Scenario 4:
The Export Manager is grouped with the Image Manager/Archive in System A. The Receiver isgrouped with an Image Manager/Archive in System B. In this case, the exported instances andmanifest are made available in System B.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3660

17.4 Teaching File and Clinical Trial Export Integration Profile Process
Flow
This section describes the typical process flow related to the selection, pseudonymization andexport of images, key image notes, reports, evidence documents and presentation states during
the creation of a teaching file or for a clinical trial.
The transactions covered are RAD-50 through RAD-53.

3665

In general, the process flow is as follows.
On an Export Selector, the user selects images, key image notes, reports, evidence documents
and presentation states, either as individual instances or as entire series or studies, that are
relevant for a Teaching File or a Clinical Trial or some other purpose (such as use in a
publication).

3670

3675

The Export Selector is possibly grouped with an Image Display, an Acquisition Modality, an
Evidence Creator and/or a Report Creator. When grouped with an appropriate Actor participatingin the appropriate Profile, the device may also be capable of displaying or importing Portable
Media (PDI Profile), query and retrieval of Reports (SINR Profile), Evidence Documents (EDProfile), query and retrieval of Key Image Notes (KIN Profile), and/or Presentation States (CPI
Profile).
The user selection results in the creation of a manifest, listing what was selected for export. This
document is the Export Selection.
Optionally, the user may enter additional information during selection as text or with simple
structure and codes, which is encoded and sent separately from the manifest.

3680

The instances are transferred to the Export Manager, unless the Export Manager is grouped withan Image Manager/Archive and the instances are known to already reside there (by static
configuration or recollection of the application entity from which the images were received).
The additional information, if any, and the manifest, are transferred to the Export Manager.

3685

3690

The Export Manager is capable of replacing patient identifiers with pseudonymous identifiers,
possibly according to some pre-registered mapping scheme or arbitrarily, and optionallyproviding manual editing of the pixel data to perform de-identification, and optionally delaying
the export until further information (e.g., the histopathology report) is available.
The Export Manager transfers the pseudonymized instances and manifest to a Receiver, whose
further behavior is not defined (except to the extent that the Receiver may be grouped with an
Image Manager/Archive or Portable Media Creator).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ExportSelector

ExportManager

ReceiverStore Instances [RAD-50]
Store Additional TF Info [RAD-52]

Store Export Selection [RAD-51]

Delay for
Pathology
De-identify
Attributes
De-identify
Pixel Data
Remap
Identifiers
Export Instances [RAD-53]

Figure 17.4.1-1: Basic Process Flow in Teaching File and Clinical Trial Export Profile
Note 1: In Figure 17.4.1-1, the sequence of the RAD-50, RAD-51 and RAD-52 transactions is not specified; thesetransactions may overlap or occur in any order.

3695

3700

Note 2: In Figure 17.4.1-1, the RAD-50 transaction may be elided if the Export Manager is grouped with the ImageManager/Archive.

The following use cases are not intended to be exhaustive nor in any way to constrain the mannerin which the profile is implemented. Rather they illustrate a range of scenarios from simple tocomplex that may be satisfied with the same actors and transactions. To provide context, in someuse cases, behavior is described that is outside the scope of this profile. Further, they serve toillustrate the differences and similarities between workflows for teaching files and clinical trials.
17.4.1 Teaching File Use Cases
The teaching file is a vital tool in medical education. Traditionally assembled from collections offilm, teaching files now need to be constructed from digital images. Digital media enables______________________________________________________________________________
181
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3705

3710

broader dissemination of the content both within and outside the enterprise, often as federated
collections that share a common query mechanism.
Teaching file case authors need access to images and related information, which usually reside in
the Image Archive/Manager and are viewed on an Image Display. Cases may also be identified
on the Acquisition Modality. Relevant images, series or studies are often identified whilst theauthor is engaged in other tasks such interpretation; hence need to be flagged for later authoring.
Enterprises frequently restrict access to information containing a patient’s identity on systems on
which teaching files are typically authored; hence the images and related information may need
to be de-identified before transfer to the authoring system. Distribution of teaching files beyond
an institution always involves de-identification.

3715

17.4.1.1 Use Case 1 – Images Selected for Teaching File During Reporting, Review
or Acquisition
User Actions:

3720

3725

A radiologist is performing diagnostic reporting of possibly many studies for different patientsduring the course of the day. Alternatively, the radiologist is consulting on a study received froma referral patient on CD. Or, the radiologist is performing an image-guided biopsy on an
acquisition device.
Images from a particular patient are noted to be of special interest and potentially suitable forteaching. The radiologist selects several relevant images from the current and prior studies to be
de-identified and saved to his teaching file collection. The selection may entail entire series or
studies, such as when later 3D reconstruction or multi-modality fusion may be required. No
additional information is entered at this time since the radiologist is busy.
Sometime later, the radiologist will access his teaching file collection and use a teaching fileauthoring program on his personal computer to create a multi-media teaching file. The manner inwhich the teaching file is authored and distributed is beyond the scope of this profile.

3730

The transfer to the radiologist’s teaching file collection may take place either over the network or
on media (the latter case might be applicable if the radiologist is a locum or from an outsidefacility or if the clinical and teaching networks are not connected).
Implementation:

3735

The radiologist is viewing images on an Image Display grouped with an Export Selector. The
Image Display is also participating in the Portable Data for Imaging Profile in the case of thereview of the referral CD. Or, the radiologist is working on an Acquisition Modality groupedwith an Export Selector.
The Export Selector allows one or more images from current and prior studies to be selected, andthen to be “exported for teaching”.

3740

The Export Selector may be preconfigured to know that the images are already stored on an
Image Manager/Archive with which the Export Manager is grouped; in such a case no Store______________________________________________________________________________
182
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Instances [RAD-50] transactions are required. In the media case, Store Instances [RAD-50]
transactions would be required.
The user action triggers a Store Export Selection [RAD-51] transaction to the Export Manager.
3745

3750

The manifest is encoded as a Key Object Selection document with a Document Title of “For
Teaching File Export”. When entire series or studies have been selected, the manifest will
enumerate all the instances from all the selected series and studies.
There may be multiple different teaching file “folders” to which the case might be added. To
allow the user to identify which teaching file the images are intended for, a free text field or apre-configured pull down list is provided, which is encoded as the disposition in the text value ofthe Key Object Selection document.
No additional content was entered at the time of selection, so no Store Additional Teaching File
Information [RAD-52] transaction is sent.

3755

If the Export Manager is not grouped with an Image Manager/Archive that already has theimages, upon receiving the images via the Store Instances [RAD-50] transaction, the Export
Manager stores them internally.
When the Export Manager receives the Store Export Selection [RAD-51] transaction, and all theimages referenced therein are available, the collection is queued for pseudonymization andexport.

3760

3765

3770

The Export Manager automatically removes all patient identification from the image attributes aswell as other text and private attributes (according to a pre-configured set of rules), checks to be
sure that the SOP Class of the image is not one likely to contain burned-in identification in the
pixel data, and inserts new dummy patient identification and other text attributes so as not toinvalidate compliance of the instance with the IOD. Note that the extent of de-identification is
configurable, and if de-identification is to be performed in the teaching file authoring system
later, may not be performed by the Export Manager at all. This may be the case when thepatient’s identity is required by teaching file authoring system to allow the user to search forother clinical and historical information.
If the Export Manager supports the De-identify Pixel Data Option, any of the images likely tocontain burned in identification information in the pixel data are placed on an internal work list
for a human operator to check and if necessary edit the pixel data to remove the burned in
identification, before the images are forwarded to the Receiver.

3775

The Export Manager then sends the pseudonymized DICOM images and an updated Key Object
Selection document containing the manifest referencing the new identifiers and UIDs to theappropriate Receiver using an Export Instances [RAD-53] transaction.

3780

The Receiver may be the enterprise’s central teaching file authoring system. Upon receiving theimages and the manifest, it extracts the identity of the radiologist who created the manifest fromthe Person Observer Identifying Attribute template encoded within the Key Object Selection
document. It uses this identity, or the disposition information, to route the case to that user’s
folder of pending cases for authoring. The Receiver could be grouped with a Portable Media______________________________________________________________________________
183
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________Creator, in which case the images and manifest could be burned to an IHE PDI CD. Note that the
behavior of the Receiver is described only to illustrate the use case, and is beyond the scope of
this profile.
3785

17.4.1.2 Use Case 2 – Complete Teaching File Authoring During Reporting with
Multiple Instance Types and Multiple Export Targets
User Actions:3795

A radiologist is performing diagnostic reporting. Images from a particular patient are noted to beof special interest and potentially suitable for teaching. In addition to having the clinical reportfor the current case that has just been created, the radiologist has also queried for prior reports,
extracted a surgical pathology report from an external report repository, and had evidence
documents previously created by a quantitative analysis package running on the acquisition
device. The radiologist selects several relevant images from the current and prior studies, saves
presentation states containing the appropriate windows and annotations of interesting lesions, aswell as several evidence documents and the surgical pathology report, and decides to create ateaching file.

3800

The workstation then prompts the radiologist to enter additional information according to a predefined template of headings and plain text sections, including history, organ system, anatomy,
findings, differential diagnosis and final diagnosis. The radiologist uses the workstation’s text
editing capability to cut and paste from the various reports into the template, as well as selecting
organ system, anatomy and diagnoses from pick-lists of codes.

3790

Upon completion, the user instructs the workstation to release the case, which is then madeavailable throughout the enterprise on the PACS and electronic medical record systems with apseudonymous identification in the departmental teaching collection folder, as well as via the
web both inside and outside the enterprise.
3805

3810

3815

Implementation:
The radiologist is viewing images on an Image Display grouped with an Export Selector, as wellas an Evidence Creator, Report Creator and Report Reader. It participates in the Evidence
Document and Simple Image and Numeric Report Profiles and hence has access to Evidence
Documents and Reports, as well as an External Report Repository. It is also participating in theConsistent Presentation of Images Profile hence supports the creation and retrieval of
Presentation States. The Export Selector supports the Additional Teaching File Information
Option.
The Export Selector allows one or more images, reports, evidence documents or presentation
states from current and prior studies to be selected, and then to be “exported for teaching”,
together with the additional information.
The user action triggers Store Instances [RAD-50] transactions, Store Additional Teaching File
Information [RAD-52] transactions and multiple Store Export Selection [RAD-51] transactions
to the Export Manager (one for each Receiver).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

3820

The manifest is encoded as a Key Object Selection document. The additional information is
encoded as a Structured Report according to a pre-defined template.
The Export Manager de-identifies and re-identifies the image, reports, evidence documents,
presentation states and additional information with pseudonymous values as in Use Case 1.

3825

3830

The Export Manager then sends the pseudonymized DICOM instances, the pseudonymized
additional information, and an updated Key Object Selection document containing the manifest
referencing the new identifiers and UIDs to the appropriate Receivers using Export Instances[RAD-53] transactions.
The multiple Receivers in this use case include the Image Managers and Archives for the clinical
PACS and the Electronic Medical Record Systems, as well as a Receiver that is the enterprise’s
own web-based teaching file distribution system, and another Receiver that is a portal to a central
repository of teaching files operated by the parent academic institution.
17.4.1.3 Use Case 3 – Images Selected for Teaching File During Reporting with
Delayed Export Awaiting Pathology
User Actions:3835

A radiologist is performing diagnostic reporting. Images from a particular patient are noted to beof special interest and potentially suitable for teaching. The radiologist selects several relevant
images from the current study to be de-identified and saved to his teaching file collection.
However, the teaching file case cannot be authored until the pathology report is available.
Accordingly, during selection the radiologist chooses the “delay for histopathology report”
modifier to the “export for teaching” action.

3840

Implementation:
The implementation proceeds as in Use Case 1.
The Key Object Selection document, in addition to having a Document Title that indicates thatthe case is for teaching file export, also has a coded Concept Modifier indicating “Delay forhistopathology report”.

3845

3850

When the Export Manager receives the Store Export Selection [RAD-51] transaction, and all theimages referenced therein are available, the collection is queued. However, since the Export
Manager supports the Delay for Reason Option, pre-configured rules within the Export Manager
Actor triggered by the “Delay for Reason” modifier indicate that the device should wait until it
receives a (relevant) histopathology report for the patient, before de-identifying andpseudonymizing the images and the histopathology report and forwarding them to the Receiver.
The manner in which the Export Manager receives the histopathology report is undefined andoutside the scope of this profile, but it must be re-encoded in a DICOM Structured Report(perhaps as plain text) for export to the Receiver, and a reference to it included in a revised
manifest.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
3855

17.4.2 Clinical Trial Use Cases
Clinical trials have similar needs to teaching files, in that images and related information need to
be selected for export to other systems, and other organizations in the case of multi-center trials.
During export, images need to be de-identified and trial-specific identifiers inserted inaccordance with local or national policy and the rules of the trial protocol.

3860

The following use cases serve to illustrate the differences and similarities between workflows forteaching files and clinical trials.
17.4.2.1 Use Case 4 – Series or Studies Selected for Clinical Trial from Referring
User’s Workstation or Acquisition Modality
User Actions:

3865

3870

A patient enrolled in a multi-center clinical trial undergoes an examination, the images of which
require review by a central facility. Though the patient has given their informed consent torelease their identification (PHI) to the central facility, site policy dictates that the images be deidentified first regardless. The managers of the trial supply replacement identifiers to be used.
A technologist, nurse or physician participating in the trial uses a referring user’s workstation on
the PACS to select the relevant studies, or selected series from the study, for export to the central
facility.
Alternatively, the technologist performing a study uses the acquisition device to select therelevant study, or selected series from the study, for export to the central facility.
Implementation:

3875

3880

3885

3890

In this case, the user is viewing images on an Image Display or Acquisition Modality groupedwith an Export Selector. The Export Selector allows images, series and studies to be selected,
and then to be “exported for clinical trial”.
The user action triggers the Export Selector to send images and an Export Selection to the Export
Manager as in Use Case 1, except that the Document Title of the Key Object Selection document
specifies “For Clinical Trial Export” instead of “For Teaching File Export”, and there is no
Additional Teaching File Information transaction.
There may be multiple trials in progress, and a single patient may be a participant in more than
one trial, hence to allow the user to identify which clinical trial the images are intended for, afree text field or a pre-configured pull down list is provided, which is encoded as the dispositionin the text value of the Key Object Selection document.
The Export Manager de-identifies and re-identifies the image, reports, evidence documents,
presentation states and additional information with pseudonymous values as in Use Case 1,
except that the Export Manager supports the Remap Identifiers Option. In order to pseudonymize
the images with the trial-specific identifiers, both as replacements for the conventional patient
identification attributes and to populate the clinical trial specific attributes, the Export Manager
Actor contains a pre-configured mapping of Patient to Subject identifiers (usually referred to as a______________________________________________________________________________
186
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
subject enrollment list). The Export Manager inserts replacement patient identification andclinical trials attributes obtained from its mapping table.
3895

3900

The Export Manager Actor then sends the pseudonymized DICOM images and an updated
manifest to a Receiver as in Use Case 1. Which Receiver to send to may be pre-configured or
may vary depending on the disposition text value of the manifest.
The Receiver may be the system responsible for transferring the images to the central review
facility. For privacy and security considerations, typically it will use a secure Internet channel,
such as a VPN, TLS (SSL) or SSH tunnel. The security mechanism is beyond the scope of thisprofile.
Or, the Receiver could be grouped with a Portable Media Creator, as described in Use Case 1, in
which case CDs would be burned and mailed to the central review facility.
This use case is distinguished from the teaching file use cases in that:

3905

•

Selection is usually at the study or series level, and rarely at the image level•

A mapping to pre-defined replacement identifiers is defined in the Export Manager•

The Export Manager also inserts clinical trial specific attributes•

A means of routing the images to the appropriate trial is required

In other respects, this use case is fundamentally the same as Use Case 1.
17.4.3 Research Collection Use Cases
3910

3915

The selection of instances or entire studies for research purposes shares many similarities withuse cases for teaching files and clinical trials. The studies generally remain in circulation forclinical use, as well as being “copied” into separate “folders” in the clinical ImageManager/Archive or copied to a separate research Image Manager/Archive. De-identification
may not be required for local research collections, but for those maintained centrally (outside theenterprise), remapping of identifiers to predefined pseudonyms is often required.
A specific Document Title of “For Research Collection Export” is provided for such use cases,
which are otherwise no different from the foregoing teaching file and clinical trial use cases interms of user actions, actors or sequencing of transactions.
17.4.4 Publication Authoring Use Cases

3920

3925

The selection of instances for use in a publication shares many similarities with use cases forteaching files. De-identification of the DICOM Header and the pixel data is required. The
disposition for these use cases should reference the target author of the selected instances. A
specific Document Title of “For Publication Export” (TCE008) is provided for such use cases,
which are otherwise no different from the foregoing teaching use cases in terms of user actions,actors or sequencing of transactions. This use case is supported by the process flow shown in
17.4.1-1.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

18 Cross-Enterprise Document Sharing for Imaging (XDS-I.b)
Integration Profile
3930

3935

IMPORTANT NOTE: The Cross-Enterprise Document Sharing for Imaging (XDS-I)
Integration Profile (originally found here) has been deprecated and is replaced by afunctionally equivalent profile called Cross-Enterprise Document Sharing for Imaging (XDSI.b), which is described in the remainder of this section.
The Cross-Enterprise Document Sharing (XDS.b) Profile in the IHE IT Infrastructure Domain
provides a solution for sharing (publishing, finding and retrieving) documents across a group ofaffiliated enterprises. The XDS for Imaging (XDS-I.b) Profile, defined here, extends andspecializes the mechanisms defined by XDS.b to support imaging “documents”, specifically
including the following:•

Imaging studies that include images acquired on a broad range of different modalities, aswell as evidence documents (e.g., post-processing measurements/analysis outcome), andpresentation states.

•

Diagnostic reports resulting from the interpretation of one or more related imaging
studies provided in a ready-for-display form•

A selection of diagnostically significant images associated with the report content.

3940

3945

3950

3955

3960

3965

These document types along with the actor capabilities required to share them are defined by thisprofile.
Since the XDS for Imaging (XDS-I.b) Profile depends on and extends the IT Infrastructure
XDS.b Profile including the use of terms defined in XDS.b (e.g., XDS Affinity Domain,
submission set, etc.) the reader of XDS-I.b is expected to have read and understood the XDS
Profiles (See ITI TF-1: 10). The XDS-I.b specification does not repeat requirements and text for
the XDS-defined Actors Document Repository, Document Registry, and Document Consumer,
and does not place any new requirements on these actors.
Both the XDS.b and XDS for Imaging (XDS-I.b) Integration Profiles are not intended to address
all cross-enterprise EHR communication needs. Many scenarios may require the use of other
IHE integration profiles, such as Patient Identifier Cross-Referencing (PIX), Audit Trail andNode Authentication (ATNA), Enterprise User Authentication (EUA), Cross-Enterprise User
Authentication (XUA) and Retrieve Information for Display (RID). Other scenarios may be only
partially supported, while still others may require future IHE integration profiles, which will bedefined by IHE as soon as the necessary base standards are available. Specifically:
1. The operation of any XDS Affinity Domain will require that a proper security model be
put in place. It is expected that a range of security models should be possible. Although
the XDS-I.b Integration Profile is not intended to include nor require any specific security
model, it is required that XDS-I.b implementers shall group XDS-I.b actors with actors
from the IHE Audit Trail and Node Authentication and will need an Access Control
capability that operates in such a cross-enterprise environment. New IHE Integration
Profiles have been identified as candidates (e.g., Public Key Infrastructure, Access______________________________________________________________________________
188
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Control, etc.). There is a discussion of XDS-I.b security considerations in RAD TF-1:
Appendix H.

3970

3975

3980

3985

2. XDS and XDS-I.b do not address transactions for the management or configuration of an
XDS Affinity Domain. For example, the configuration of network addresses or thedefinition of what type of clinical information is to be shared is specifically left up to thepolicies established by the XDS Affinity Domain.
3. XDS and XDS-I.b do not specifically address the patient information reconciliation
process necessary between the XDS Affinity Domain and any other local patient identity
domains that Document Sources and Document Consumers may be members of. For a
discussion of some of these issues see RAD TF-1: Appendix G.
4. XDS and XDS-I.b do not directly address the rendering and display of the documents
retrieved by the Document and Imaging Document Consumers. Users wishing to achievea well-defined level of display/ rendering capability simply need to request systems thatcombine the XDS-I.b Imaging Document Consumer Actor with an Image Display Actor
from the appropriate Profile (e.g., Mammography Image, NM Image, Basic Image
Review, etc.).
5. XDS and XDS-I.b do not directly address the rendering and display of the documents
retrieved by the Document and Imaging Document Consumers. Users wishing to achievea well-defined level of display/ rendering capability simply need to request systems thatcombine the XDS-I.b Imaging Document Consumer Actor with an Image Display Actor
from the appropriate Profile (e.g., Mammography Image, NM Image, Basic Image
Review, etc.).

18.1 Actors/ Transactions
3990

3995

Figure 18.1-1 shows the actors directly involved in this profile and the transactions between
actors. The shaded XDS actors are NOT actually included in this profile but are included to show
the other endpoint of transactions that ARE part of the profile (e.g., the Document Repository
Actor that is the endpoint for the Provide and Register Imaging Document Set – MTOM/XOPTransaction). As a result, the shaded actors are not listed in Table 18.1-1. The XDS-I.b Profile
does not place any additional requirements on any of these actors above and beyond what it
required of them by the ITI XDS.b Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Registry Stored Query [ITI-18]←

Document Registry(XDS.b)Imaging Document
Consumer↑ Register
Document Set – b [ITI-42]
Provide & Register Imaging
Document Set – MTOM/XOP [RAD-68]→

Document Repository(XDS.b)Document Consumer(XDS.b)Retrieve Document
Set [ITI-43]←

WADO Retrieve [RAD-55] ←Retrieve Imaging Document Set [RAD-69] ←Imaging Document
SourceRetrieve Images [RAD-16] ←Retrieve Presentation States [RAD-17] ←Retrieve Reports [RAD-27] ←Retrieve Key Image Note [RAD-31] ←Retrieve Evidence Documents [RAD-45] ←Figure 18.1-1: Cross-Enterprise Document Sharing for Imaging Diagram

4000

Table 18.1-1 lists the transactions for each actor directly involved in the Cross-Enterprise
Document Sharing for Imaging (XDS-I.b) Profile. In order to claim support of this Integration
Profile, an implementation shall perform the required transactions (labeled “R”). Transactions
labeled “O” are optional. A complete list of options defined by this Integration Profile is listed in
RAD TF-1: 18.2. Note the grouping of actors described in RAD TF-1: 2.4.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4005

Table 18.1-1: Cross-enterprise Document Sharing for Imaging Integration Profile - Actors
and Transactions
ActorsImaging Document Consumer

Transactions

OptionalitySectionin Vol. 2 /3Retrieve Images [RAD-16]

O (note 1)

4.16

O

4.17

O (note 1)

4.27

Retrieve Key Image Note [RAD-31]

O

4.31

Retrieve Evidence Documents [RAD45]

O (note 1)

4.45

WADO Retrieve [RAD-55]

O (note 1)

4.55

Retrieve Imaging Document Set[RAD-69]

O (note 1)

4.69

Provide and Register Imaging
Document Set – MTOM/XOP [RAD68]

R (note 2)

4.68

Retrieve Images [RAD-16]

R (note 3)

4.16

Retrieve Presentation States [RAD17]

R (note 3)

4.17

Retrieve Reports [RAD-27]

R (note 3)

4.27

Retrieve Presentation States [RAD17]
Retrieve Reports [RAD-27]

Imaging Document Source

Retrieve Key Image Note [RAD-31],

R (note 3)

4.31

Retrieve Evidence Documents [RAD45]

R (note 3)

4.45

WADO Retrieve [RAD-55]

R (note 3)

4.55

Retrieve Imaging Document Set[RAD-69]

R (note 3)

4.69

Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to section 18.4 for additional
requirements on the Imaging Document Consumer.
Note 2: Support of at least one of the four document types described by the options in section 18.2 is required.

4010

Note 3: These transactions are only required if the Imaging Document Source supports the ‘Set of DICOM Instances’
option as described in Table 18.2-1.

18.2 Integration Profile Options
Options that may be selected for this Integration Profile are listed in Table 18.2-1 along with theActors to which they apply. Dependencies between options when applicable are specified innotes.
4015
Table 18.2-1: Cross-enterprise Document Sharing for Imaging - Actors and Options
Actor

OptionsVol. &
SectionImaging Document Source

Set of DICOM Instances(Note 1)

RAD TF-1:
18.2.1______________________________________________________________________________
191
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Actor

OptionsVol. &
SectionPDF Report (Note 1)

RAD TF-1:
18.2.2

CDA Wrapped Text
Report (Note 1)

RAD TF-1:
18.2.3

CDA Imaging Reportwith Structured Headings(Note 1)

RAD TF-1:
18.2.4

Imaging Document Consumer

No options defined-

Note 1: At least one of these four options is required

18.2.1 Set of DICOM Instances Option
4020

This option requires the Imaging Document Source to create a DICOM manifest that references
DICOM instances, and to provide and register this document to the Document Repository. The
Imaging Document Source is required to ensure that the referenced images from within apublished manifest are available to be retrieved. For details of the transaction affected by thisoption, refer to RAD TF-2: 4.68.4.1.2.1.

4025

18.2.2 PDF Report Option

4030

This option requires the Imaging Document Source to provide and register an Imaging Report ina PDF format to the Document Repository. The published report may contain embedded images
or pre-computed links that reference images in a non-DICOM format. The Imaging Document
Source is required to ensure that image references are valid links. For details of the transaction
affected by this option, refer to RAD TF-2: 4.68.4.1.2.2.
18.2.3 CDA Wrapped Text Report Option
This option requires the Imaging Document Source to send to the Document Repository a CDA
R2 document containing a Text Report. For details, refer to RAD TF-3: 4.68.4.1.2.2.
18.2.4 CDA Imaging Report with Structured Headings Option

4035This option requires the Imaging Document Source to send to the Document Repository a CDA
R2 document containing an Imaging Report with Structured Headings. For details, refer to RAD
TF-3: 4.68.4.1.2.2.

18.3 Image Information Sharing Process Flow4040

The sharing of imaging related information among different health professionals and facilities,
even across administrative and geographic boundaries can lead to a large variety of information
flows. Typical imaging information sets used in healthcare settings are well known, but thechallenge is to distill the “exchange” scenarios to drive the sharing of imaging information acrossenterprises distributed over a community, region or nation.
______________________________________________________________________________
192
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
18.3.1 Overview of Imaging Information Sharing Use Cases
4045

4050

4055

4060

4065

4070

4075

The following use case scenarios express the core imaging information sharing common to mostclinical settings. They cover:
1. Routine imaging referral. The referring physician in his office requests that a patient
have an examination done at an imaging facility. The physician expects to have electronic
access to the imaging report and to the images if needed after the examination has been
performed on his patient. This use case is further analyzed in this profile.
2. Course of Treatment Consult. An emergency physician orders an imaging examination
for a patient at his hospital. After reviewing the preliminary report the ER physician
decides to consult a surgical specialist at the regional hospital for advice on a course ofaction. For this, the surgical specialist accesses the images and preliminary report andreviews them in order to propose, on the phone, a course of action for the patient. Thisuse case is further analyzed in this profile.
3. Clinical Consult. A general practitioner performs a routine imaging referral, reviews theshared imaging report and chooses to send the patient for evaluation by a specialist (e.g.,an oncologist). The specialist needs access to the imaging report and full image set
produced at the imaging facility where the patient had been sent by his generalpractitioner to perform the examination. This use case is further analyzed in this profile.
4. General imaging record access. A patient relocates or decides to change her physician.
The new physician needs to retrieve relevant information from the patient record, review
its content, including recent labs and imaging studies. A similar situation occurs when apatient is admitted for an emergency and timely access to the patient’s past information isrequired, including prior imaging studies. This use case is further analyzed in this profile.
This profile describes the information sharing transactions for care-delivering systems to publish
patient’s imaging diagnostic documents (EHR-CR) for sharing across enterprises as longitudinalpatient care records (HER-LR). The policies or administrative details regarding the sharing ofimaging information are for the most part not explicitly discussed so as not to obscure clinicalneeds. Administrative variations between countries and regions are expected, and can be added
or modified without losing the clinical information-sharing context.
Since the focus is on the sharing and access to patients imaging records rather than the entire
workflow in which such information sharing takes place, other activities are described as though
they are being done by telephone, paper mail, fax, etc. In an integrated electronic environment
these other activities may be more automated, but those details are separate from the records
access/sharing and are to be addressed by separate Integration Profiles.
18.3.2 Assumptions

4080

The imaging information needs to be shared between multiple care delivery organizations(information sources and consumers), each (typically) with its own RIS and PACS. The point ofservice (“POS”) for physicians may be supported by a variety of systems: hospital EMR,
physician practice system, PACS viewers, EHR web application, etc.
______________________________________________________________________________
193
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4085

The concept of sharing information across enterprises that have agreed to join in such a healthinformation network is based on basic design principles that can be summarized in the following
points:
5. A group of healthcare enterprises have agreed to work together using a common set ofpolicies and to share a common infrastructure of repositories and a registry for an affinity
domain.

4090

6. Information sources (e.g., EHR, lab system, PACS) select the “documents” they wish toshare.
7. Documents may include any information in an agreed format (e.g., a PDF document, a
DICOM manifest, etc.). Documents are stored in multiple document repositories.

4095

8. Shared documents are registered with a central service called a document registry thattracks only indexing information and the location from which documents may be
retrieved.
9. Information consumers may query this well-defined unique/singular indexing service(document registry) to find the document index information for any patient and thelocation from which documents may be retrieved (document repositories).

4100

10. Information sources remain the owner of the documents shared in repositories and,
thereby, remain responsible for replacing or deprecating its documents if necessary.
In each one of the use cases, it is assumed that the people and the information systems thatparticipate in a single “Affinity Domain” have agreed upon mechanisms to address:

4105

•

Governance: operational structure, data stewardship, etc.

•

Privacy: consent management and data masking controls•

Security: Authorization and authentication, network security, audit trails, etc.

•

Normalized patient ID schemes: MPI (Master Patient Index), unique information IDs, etc.

•

Coded Vocabularies used for registry information

18.3.3 Use cases
18.3.3.1 Routine Imaging Referral Use Case
4110

4115

This scenario describes imaging information sharing in a typical patient referral and reportinguse case where:•

An examination is performed upon the request of a referring physician:•The referring physician accesses the regional health information network and reviews thereport along with the key images and may optionally access the full image set that madethe study.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
This scenario is characterized by all the information being provided for sharing at one time, as asingle logical unit, when the imaging study is completed by the radiology enterprise (i.e., a single“document submission set”).
18.3.3.1.1
4120

Figure 18.3.3-1 highlights the people and systems participating in this regional healthinformation network, including:•Physician Office: A referring physician working out of a private office with a physician
practice system for access to information•

RIS/PACS Enterprise A: A radiology enterprise with modality equipment and a
RIS/PACS to manage report and imaging information: Radiology Enterprise A•

RIS/PACS Enterprise B: Another radiology enterprise with a RIS/PACS to manage reportand imaging information: Radiology Enterprise B•

Document Registry: A document registry that serves as the information index for theregional health information network

4125

4130

Process Flow

In the process flow description, steps that pertain to information sharing are shown in bold (andnumbered). In contrast, the steps that do not pertain to the focus of information sharing areshown in italic (and not numbered). These steps are expressed to ensure a more complete
context.
Figure 18.3.3-2 shows the transaction diagram for this process flow.

4135
Exam is ordered
The Referring Physician orders the examination and the patient goes to the Imaging Department:
Radiology Enterprise A.
4140

This is well-understood workflow that may be executed using any combination of paper, faxes,
telephone, and electronic communications. It may or may not be addressed using the IHE
Scheduled Workflow Integration Profile.
Although this step is part of the use case, it is peripheral to the specific steps for sharing ofimaging of information.
Step 1: Obtain Relevant Prior Imaging Information

4145

4150

•

The PACS at Radiology Enterprise A, where the acquisition and reporting is performed,
does a query of the Document Registry to identify relevant prior images and reports. It
should be noted that the determination of what is relevant is the responsibility of theconsumer and not the registry.

•

The PACS at Radiology Enterprise A retrieves prior imaging information from a
repository in another radiology enterprise within the regional health network: Radiology
Enterprise B, in preparation for study acquisition and subsequent reporting______________________________________________________________________________
195
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Radiology Enterprise B

Prior imaging studies

Querydocument

Prior imaging studies

Registry
Querydocument
Provide Imaging
Information for sharing

Query document

Imaging Study

Radiology Enterprise A

Affinity Domain

Physician Office

Figure 18.3.3-1: Data Flow within the Regional Health Network for a Routine Imaging
Referral

4155
Exam is Acquired and Reported
Images are sent from the modality to the PACS. This is well-understood workflow described in
IHE SWF.
4160

The study is reported. This is well understood workflow that is managed by systems withinRadiology Enterprise A
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain)•

4165

The PACS at Radiology Enterprise A, serving as a “Imaging Document Source”,
provides imaging information to the document repository, which register the document in
the registry, for sharing, including:•Acquired DICOM study•

Final report•

Key images along with annotations______________________________________________________________________________
196
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
4170

Step 3: Obtain and Display Study Results•

A physician practice system in the Physician’s office, serving as a document consumer,
queries the Document Registry in the regional health network. This query may betriggered by the patient’s next appointment, a call from the patient to the physician’ssecretary, an electronic notification that the examination’s result is available (using theIHE ITI Notification for Document Availability Profile), etc.

•

The physician practice system presents a list of imaging information available for thepatient•

The referring physician selects the study results and relevant prior studies and reports•

The physician practice system in the Physician’s office, serving as an Imaging Document
Consumer, retrieves the selected documents from the RIS/PACS Document Repositories
in the regional health network and displays them to the referring physician.

4175

4180

Referring Physician reviews the results
4185

The Referring Physician reviews the results of the examination: the report and images from the
RIS/PACS in Radiology Enterprise A, and the results of prior examinations: reports and images
from the RIS/PACS in Radiology Enterprise B
Radiology Enterprise A(Document Consumer)

Radiology Enterprise A(Document Source)Radiology Enterprise A(Document Repository)

Radiology Enterprise B(Document Repository)

Document Registry

Document Consumer(Physician Office)Step 1 - Query for relevant priors
Step 1 - Retrieve relevant prior images and reports

Step 2 - Share Images
and Final Report

Step 2 - Register Images and Final Report

Step 3 - Queryfor Exam

Step 3 - Retrieve Final Report and Images, Relevant
prior images and reports

Figure 18.3.3-2: Process Flow – Routine Imaging Referral Use Case

4190

18.3.3.2 Course of Treatment Consult Use Case
This scenario is a variation on the routine imaging referral use case in that an addendum isgenerated after completion of the final report. As such, this scenario is characterized byinformation being provided for sharing at two separate times while ensuring that the initial
information is supplemented by the addendum report.
______________________________________________________________________________
197
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
4195

The use of addendum reports is commonly encountered in a course of treatment consultation
where:•An ER physician orders an exam, and the study is acquired in the affiliated radiology
department.

•

A department radiologist creates and shares a report as well as identifies key images andannotations.

•

A remotely located surgical specialist, at the request of the ER physician, reviews thereport along with key images and the full study, and provides a consult to the ER
physician (this use case does not constrain the method for communicating the results ofthe consult, e.g., phone, fax, etc.).

•

The radiologist identifies additional information and completes an addendum to the initialreport.

4200

4205

Note that the scenario where the radiologist seeks an opinion from a more senior radiologist issimilar to this use case.
18.3.3.2.1
4210

Process Flow

The process flow description and steps are as for the routine imaging referral, but with thefollowing variations (shown in bold):Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting

4215

Step 2:Share Imaging Information within the Regional Health Network (Affinity Domain)•

4220

The PACS at Enterprise A, serving as a “Imaging Document Source”, provides imaging
information to the document repository, which register the document in the registry, forsharing, including:•Acquired DICOM study•

Report•Key images along with annotations

Step 3: Obtain and Display Study Results
ER Physician reviews the results
Step 4:Share Addendum to Report within the Regional Health Network (Affinity Domain)
4225•

Sometime later on, the radiologist creates an addendum to the initial report. Thisaddendum is transcribed into the RIS at Enterprise A and signed off by the radiologist.
This addendum must now supplement the initial report.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4230

•

The RIS at Enterprise A performs a document query of the document registry for the firstsubmission set•

The RIS at Enterprise A, serving as a “Imaging Document Source”, provides theaddendum for sharing to the document registry including the content of the firstsubmission set and declaring the new document as an addendum to the initial report

Figure 18.3.3-3 shows the transaction diagram for this process flow.
4235
Rad. Enterprise A
Rad. Enterprise A: PACS
(Document Consumer)(Document Source)

Rad. Enterprise A: RIS(Document Source)

Rad. Enterprise A(Document Repository)

Rad. Enterprise B(Document Repository)

Document Registry

Orthopaedic Centre(Document Consumer)

Step 1 - Query or relevant prior exams
Step 1 - Retrieve relevant prior images and reports

Step 2 - Share images and Initial Report(Submission Set 1)

Step 2 - Register images and report

Step 3 - Query for
exam

Step 3 - Retrieve images and report for new exam

Step 4 - Query for new exam (associated submission set)

Step 4 - Register Addendum
Step 4 - Share
Addendum(Submission Set 2)

Figure 18.3.3-3: Process Flow – Course of Treatment Consult Use Case

18.3.3.3 Clinical Consult Use Case
4240

This scenario is an extension of the routine imaging referral use case in that a consult report isgenerated based from the original imaging exam and radiologist report. As such, this scenario ischaracterized by information being provided for sharing at two separate times by two separate
source systems.
The reports shared in this use case are based on the same initial imaging exam. However thereports are generated by different people and registered by different systems.

4245

The generation of consult reports is commonly encountered in cancer treatment. As such, thefollowing clinical consult use case is used to describe the scenario:•

A general practitioner performs a routine imaging referral (as per Use Case 1).

•

In reviewing the imaging exam report from the radiologist, the practitioner chooses tosend the patient to an oncologist for a consultation.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
4250•

The oncologist, located at a Cancer Center, reviews the report along with key images, thefull study, and past imaging information records for the patient•

The oncologist generates an additional report that is made available to the generalpractitioner•

The general practitioner reviews the oncologists report and takes appropriate treatment
action4255

18.3.3.3.1

Process Flow

Figure 18.3.3-4 highlights the people and systems participating in this regional healthinformation network. These are the same as for the routine imaging referral but with one
additional participant:
4260

4265

•

Physician Office•

RIS/PACS Enterprise A•

RIS/PACS Enterprise B•

Document Registry•

Oncologist: An oncologist working out of a cancer center: Cancer Center. This center has
an Electronic Health Record (EHR) application that serves as the POS application forreviewing imaging information within the regional health network. The EHR application
has DICOM Viewing capabilities______________________________________________________________________________
200
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Radiology Enterprise B

Physician’s OfficePrior imaging studies

Prior imaging
studiesQuerydocument

New Exam

Querydocument

Registry

Prior imaging studies

Querydocument

Provide Imaging
Information for sharing

Provide Imaging
Information forsharing
Query document

Imaging Study

Radiology Enterprise A

Affinity Domain

Cancer Center

4270

Figure 18.3.3-4: Data Flow within the Regional Health Network for a Clinical Consult

4275

The process flow description and steps are as for the routine imaging referral, but with certain
variations. The variations that pertain to information sharing are shown in bold (and numbered).
In contrast, the variations that do not pertain to the focus of information sharing are shown initalic (and not numbered).
Exam is ordered
Step 1: Obtain Relevant Prior Imaging Information
Exam Acquisition and Reporting
Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain)

4280

Step 3: Obtain and Display Study Results (General Practitioner)•

This is identical to Step 3 in the routine imaging referral use case•

Based on the radiology report, the general practitioner determines that a consult with anoncologist is required______________________________________________________________________________
201
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Step 4: Obtain and Display Study Results (Oncologist)
4285•

The EHR application in the oncologist’s office, serving as a document consumer, queries
the document registry in the regional health network. This query is triggered by a consult
request from the general practitioner via paper, fax, phone, and/or electronic notification.
The EHR application presents a list of imaging information available for the patient,including the most recent exam completed at Radiology Enterprise A

4290

•

The oncologist selects the exam reported by the radiologist as well as a number of
relevant prior exams•

The EHR application in the oncologist’s office, serving as an Imaging Document
Consumer, retrieves the documents selected from the RIS/PACS document repositories in
the regional health network and displays them to the oncologist•

The oncologist reviews the images using image manipulation tools such as window level,
zoom, pan, invert, measurement, etc. The oncologist may also apply 3D rendering such as
multi-planar reformatting

4295

Oncologist Generates Consult Report

4300

•

The oncologist reviews the results of the examination along with prior exams•

The oncologist generates a consult report

Step 5:Share Consult Report within the Regional Health Network (Affinity Domain)•

4305

The EHR application in the oncologist’s office, serving as an “Imaging Document
Source”, provides the consult report to the document registry for sharing. This hasreference to the original imaging exam, which was used during the consult.

Figure 18.3.3-5 shows the transaction diagram for this process flow.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Rad. Enterprise A
Rad. Enterprise A
Rad. Enterprise A
Cancer Centre
Cancer Centre
Rad. Enterprise B(Document Consumer) (Document Source) (Document Repository) (Document Repository) (Document Consumer)(Document Source)

Document Registry

GP Office(Document Consumer)

Step 1 - Query for relevant priors
Step 1 - Retrieve relevant prior images and reports

Step 2 - Register images and report
Step 2 - Share
Images andFInal Report

Step 3 - Queryfor new exam
Step 3 - Retrieve new exam

Step 4 - Retrieve new exam & relevant
priorsStep 4 - Query for new exam andrelevant priors

Step 5 - Query
new exam(associatedsubmission set)
Step 5 - Share Consult Report
Step 5 - Register consult report

Figure 18.3.3-5: Process Flow – Clinical Consult Use Case

18.3.4 Queries
4310

As presented in the use cases, human or machine users may query the Registry in order toretrieve documents in a subsequent step, based on the query result. The type of query attributes
may vary between users or query scenarios, depending on the intent of the query. For instance,
human users often wish to query specifically, restricting the search by several query attributesand values.

4315

The following query attributes are relevant (but not exhaustive):•

Patient Identity – The patient is expected to be identified by Patient ID•

Exam Identity – The physician is looking for a specific exam. The attributes used to
identify the exam may include one or more of the following:

4320

4325

•

Date

•

Modality•

Body part/anatomical region•

Document type – images, diagnosis, progress report, preliminary report, etc.

•

Author – in the case of reports, the physician may well identify the report by its
author i.e., the radiologist and / or specialist

The metadata in the query response needs to be sufficient to allow the system consumer to parsethe response and identify relevant priors. Relevant metadata includes (but is not limited to):•Exam date______________________________________________________________________________
203
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4330

•

Modality•

Body part/anatomical region•

Procedure code

18.4 Consumer Processing
18.4.1 Consumer Processing – Set of DICOM Instances

4335

When the Imaging Document Consumer retrieves a manifest from the Document Repository, it isexpected to decode the Key Object Selection Document Instance in order to find the references
to DICOM objects. The Imaging Document Consumer is also expected to retrieve the referenced
DICOM objects using DICOM retrieve or WADO. It should not make any assumptions about
whether one or more studies are referenced within the Key Object Selection Document.

18.5 Patient Information Reconciliation
These considerations can be found in Appendix G.
4340

18.6 Security considerations
All XDS-I.b actors shall be grouped with either a Secure Node or Secure Application Actor fromthe ATNA Profile. These actors shall also support the Radiology Audit Trail Option.

4345

This grouping is required to provide the capability for security auditing, for establishing a trust
relationship between systems exchanging information, and to enable secure data exchange. Some
care sites may use alternate mechanisms for providing equivalent security.
Other security considerations can be found in Appendix H.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

19 Mammography Image Integration Profile

4350

4355

4360

The Mammography Image Profile specifies how DICOM Mammography images and evidence
objects are created, exchanged and used. It describes how Acquisition Modalities transfer Full
Field Digital Mammography (FFDM) Images, how CAD systems act as Evidence Creators, and
how Image Displays should retrieve and make use of images and CAD results. It defines thebasic display capabilities Image Displays are expected to provide, and which attributes should be
used to implement those capabilities.
Managing the process of creating, storing and using Mammography Image content is similar toworkflow for other image content (e.g., see Scheduled Workflow and Post-Processing Workflow
Profiles).
The Mammography Image Profile is designed to provide faithful and complete storage andretrieval of Mammography data and sufficient display functionality to allow adequate review ofcurrent and prior images and CAD results for the purpose of primary interpretation byradiologists. It should also be sufficient for secondary review for referring physicians. It does notaddress the use of other modalities appropriate for breast imaging such as MR or US.

19.1 Actors/ Transactions
Figure 19.1-1 shows the actors directly involved in the Mammography Image Integration Profileand the relevant transactions between them.
4365______________________________________________________________________________
205
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Evidence Creator↓ Storage Commitment [10]Image
Manager

Modality Images
Stored [8] ↑Image Display

Evidence Document
Stored [43] ↓↓ Query I mages [14]↓ Retrieve Images [16]↓ Query Evidence Documents [44]↓ Retrieve Evidence Documents [45]Image
Archive↑ Storage Commitment [10]Acquisition Modality
Print Composer
Print Request with Presentation LUT [RAD-23] ↓Print Server

Figure 19.1-1: Mammography Image Profile Actor Diagram

4370

4375

Table 19.1-1 lists the transactions for each actor directly involved in the Mammography Image
Profile. In order to claim support of this Integration Profile, an implementation must perform therequired transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of
options defined by this Integration Profile and that implementations may choose to support islisted in Volume 1, Section 19.2.
Table 19.1-1: Mammography Image Integration Profile - Actors and Transactions
ActorsAcquisition Modality
Evidence Creator

Image Manager/Archive

Transactions

Optionality

Sectionin Vol. 2 /3Modality Images Stored [RAD-8]

R

4.8

Storage Commitment [RAD-10]

R

4.10

Evidence Document Stored [RAD43]

R

4.43

Storage Commitment [RAD-10]

R

4.10

Modality Images Stored [RAD-8]R

4.8______________________________________________________________________________
206
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsTransactions

Optionality

Evidence Document Stored [RAD43]

R

4.43

Storage Commitment [RAD-10]

R

4.10

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Query Evidence Documents [RAD44]

R

4.44

Retrieve Evidence Documents[RAD-45]

R

4.45

Query Images [RAD-14]

R

4.14

Retrieve Images [RAD-16]

R

4.16

Query Evidence Documents [RAD44]

R

4.44

Retrieve Evidence Documents[RAD-45]

R

4.45

Print Composer

Print Request with Presentation
LUT [RAD-23]

R

4.23

Print Server

Print Request with Presentation
LUT [RAD-23]

R

4.23

Image Display

Sectionin Vol. 2 /3

19.2 Mammography Image Integration Profile Options

4380

Options that may be selected for this Integration Profile are listed in the Table 19.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Table 19.2-1: Evidence Documents - Actors and Options
Actor

OptionsVol. & Section

Acquisition Modality

Partial View

RAD TF-2: 4.8.4.1.2.3.1

Image Archive/Manager

No options defined

Image Display

Partial View

-RAD TF-2: 4.16.4.2.2.1.1.7______________________________________________________________________________
207
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

19.3 Mammography Image Profile Process Flow
Evidence
Creator(CAD System)

Acquisition
Modality

Perform
Acquisition

Image Manager/
Image Archive

Image Display

Modality Images
Stored [8] - Mammo
ImagesStorageCommitment [10]Perform
CAD

Evidence Document
Stored [43] Mammo CAD
StorageCommitment [10]Query Ima ges [14]Retrieve Images [16] - Mammo Images
Present Mammo
Imagesto User

Query Evi dence Document [44]Retrieve Evidence Document [45] Mammo CAD
Present Mammo
Images with CAD
to User

4385

Figure 19.3-1: Basic Process Flow in Mammography Image Profile

The workflow between the Acquisition Modality and the Evidence Creator that is the CAD
device is currently outside the scope of IHE to define.
4390______________________________________________________________________________
208
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

20 Image Fusion (FUS)This section intentionally, temporarily left blank.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

21 Import Reconciliation Workflow (IRWF)
4395

4400

4405

4410

IMPORTANT NOTE: As of June 2012, IHE introduces an updated Import Reconciliation
Profile (IRWF.b) for Trial Implementation. In addition to the original use cases, several newuse cases are addressed, and the underlying mechanisms are improved. The IRWF Profile
documented in this section has been deprecated by the Radiology Domain and is now replacedby the IRWF.b. . When that supplement becomes Final Text, the contents of this section will
be removed. In the interim, new implementations should be based on IRWF.b, found at
http://www.ihe.net/Technical_Frameworks/#radiology.
The Import Reconciliation Workflow Integration Profile (IRWF) specifies both the data andworkflow requirements for importing existing Evidence Objects and importing Hardcopy froman external Enterprise. Worklists and Patient Demographics Query are provided as mechanisms
to provide local patient and procedure information to be used in the process of reconciling theimported patient/procedure information. Procedure Step Completed messages enable subsequent
workflow steps to occur based on the importation of the Evidence Objects.
Reconciling critical patient demographics (e.g., Patient Name, Patient ID) and order/procedure
Information (e.g., Accession Number) is an important part of the importation process since thelocal Enterprise will typically have different identifiers (for patient, orders, etc.) from theEnterprise that created the Evidence Objects or Hardcopy being imported.
When the attribute values must be changed, this Profile provides a mechanism to preserve a copyof the original values inside the imported DICOM Composite Objects.

4415This profile also makes it possible to determine whether images, reports and other evidence
objects associated with a particular import have been stored (archived) and are available tosubsequent workflow steps, such as post-processing and reporting.

21.1 Actors/Transactions
Figure 21.1-1 diagrams the actors involved with this profile and the transactions between them.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Patient
Demographics
Supplier

DSS/Order Filler↑ Import PS in Progress [RAD-59]↑ Import PS Completed [RAD-60]→ Import PS in Progress [RAD-59]→ Import PS Completed [RAD-60]
Performed
Procedure
Step Manager

Image
Manager

Image
Archive↑ Storage
Commitment [RAD-10]↑ Imported Objects
Stored [RAD-61]← Import PS in Progress [RAD-59]← Import PS Completed [RAD-60]
Importer← Query Modality Worklist [RAD-5]

4420

4425

→ Patient Demographics Query [ITI-21]

Figure 21.1-1: Import Reconciliation Workflow Diagram

Table 21.1-1 lists the transactions for each actor directly involved in the Import Reconciliation
Workflow Integration Profile. In order to claim support of this Integration Profile, Import
Reconciliation Actors present in the Scheduled Workflow Profile must also support Scheduled
Workflow and perform the required transactions (labeled “R”). Transactions labeled “O” areoptional. A complete list of options defined by this Integration Profile that implementations may
choose to support is listed in section 21.2.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4430

Table 21.1-1: Import Reconciliation Workflow Integration Profile - Actors andTransactions
Transactions

Optionality

Vol.
SectionQuery Modality Worklist [RAD-5]

R

RAD TF2:4.5

Import Procedure Step In Progress[RAD-59]

R

RAD TF3:4.59

Import Procedure Step Completed[RAD-60]

R

RAD TF3:4.60

Patient Demographics Supplier

Patient Demographics Query [ITI-21]

R

ITI TF-2a:
4.21

Importer

Query Modality Worklist [RAD-5](Note 1)O

RAD TF2:4.5

Patient Demographics Query [ITI-21](Note 1)O

ITI TF-2a:
4.21

Import Procedure Step In Progress[RAD-59]

R

RAD TF3:4.59

Import Procedure Step Completed[RAD-60]

R

RAD TF3:4.60

Imported Objects Stored [RAD-61]

R

RAD TF3:4.61

Storage Commitment [RAD-10]

R

RAD TF2:4.10

Import Procedure Step In Progress[RAD-59]

R

RAD TF3:4.59

Import Procedure Step Completed[RAD-60]

R

RAD TF3:4.60

Imported Objects Stored [RAD-61]

R

RAD TF3:4.61

Storage Commitment [RAD-10]

R

RAD TF2:4.10

Import Procedure Step In Progress[RAD-59]

R

RAD TF3:4.59

Import Procedure Step Completed[RAD-60]

R

RAD TF3:4.60

ActorsDepartment System Scheduler/
Order Filler

Image Manager/
Image Archive

Performed Procedure Step
Manager

Note 1: The Importer shall support at least one of the Query Modality Worklist or Patient Demographics Query
transactions.

Refer to Table 2-1 for other profiles that may be pre-requisites for this profile

21.2 Import Reconciliation Workflow Integration Profile Options
4435

Options that may be selected for this Integration Profile are listed in the Table 21.2-1 along with
the Actors to which they apply. Dependencies between options, when applicable, are specified innotes.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4440
Table 21.2-1: Import Reconciliation Workflow - Actors and Options
Actor

OptionVol. 1/2/3

Department System Scheduler/
Order Filler

No Option Defined-

Importer

Scheduled Import (note 1)

RAD TF-1: 21.2.1

Unscheduled Import (note 1)

RAD TF-1: 21.2.2

Billing and Material Management

RAD TF-3: 4.60

Image Manager/ Image Archive

No Option Defined-

Performed Procedure Step Manager

No Option defined-

Note 1: The Importer shall support at least one of the Scheduled Import or Unscheduled Import Options.

4445

The Importer and Image Manager/ Image Archive will likely support a variety of DICOM SOP
Classes. It is expected that this level of optionality will be documented in the DICOM
Conformance Statement.
21.2.1 Scheduled Import Option

4450

Importers claiming the Scheduled Import Option are required to support the Query Modality
Worklist transaction (See RAD TF-2: 4.5) to obtain import worklists and use the patient andprocedure information provided to reconcile the imported data.
For further details of this option, refer to RAD TF-3: 4.59.4.1.2.3.1.
21.2.2 Unscheduled Import Option

4455

Importers claiming the Unscheduled Import Option are required to support the Patient
Demographics Query transaction (See ITI TF-2: 4.21) to obtain patient demographics forreconciling the imported data.
For further details of this option, refer to RAD TF-3 4.59.4.1.2.3.2.
Note that the identifiers provided by the ITI Patient Demographic Supplier Actor are expected tobe consistent with those that would be obtained using SWF transactions. This is necessary toensure the synchronization of the Patient Demographics from both sources.

4460

21.3 Integration Workflow Process Flow

4465

This section describes the workflow related to importing DICOM data or importing hardcopy
created external to the Enterprise. Import Reconciliation Workflow uses many transactions from
Scheduled Workflow (See Section RAD TF–1: 3.3). In most cases there are no changes in thesetransactions. See Appendix C for an overview of the information exchange between the
Department System Scheduler/Order Filler and Image Manager.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Once the desired information has been imported into the local Enterprise it is up to the local
institution to determine the retention policies for physical media associated with the import (e.g.,films, CDs, DVDs) and the imported data itself.
21.3.1 Import Process Flow
4470

This section describes the typical process flow for managed importation. This profile only
applies to data from patients that have been registered and assumes that the patient demographics
information is known and available to the local system and user. If the Patient is not registered,the data is imported and needs to be reconciled by other mechanisms such as PIR.
21.3.1.1 Use Cases

4475

The primary use cases for importing radiology information are:
1. External Acquisition or Read: An institution has referred the patient to an external facility
for acquisition, or for reading. The institution receives the acquired study on media fromthe external facility and imports it to the local archive.

4480

4485

2. External Priors: The institution receives media containing prior images and/or reports fora current patient. The data is imported to the local archive and associated with thepatient’s record so they can be referred to as priors during the reading of the current
study.
3. Patient Referral: The institution receives media containing a patient’s radiological history
associated with a referral or patient transfer. The data is imported to the local archive andassociated with the patient’s record.
The importation may be managed in two different ways:
1. Scheduled Import: The institution schedules the import task on an importation worklist
which provides the local demographics and local procedure information.

4490

2. Unscheduled Import: The institution does not electronically schedule the import task andinstead relies on the Importer to obtain local demographics from a Demographics
Supplier.
In either case it is a prerequisite that the patient has been registered so that locally correct
demographic information for the patients is available. Importation of “locally unknown” patients
followed by Patient Information Reconciliation is not covered by this Integration Profile.

4495

Importation could be performed piecewise on a physician’s workstation, or batched at a central
location.
The data may arrive at the institution by a variety of transport mechanisms including hardcopy(films, prints), media (CDs, DVDs) or simple network transfer. This profile does not dictate aparticular transport mechanism.

4500

For any import, there may exist information in addition to the media, which will be taken into
account by the importing enterprise but its usage is not specified by IHE. This information may
be available electronically, written or orally. Main examples for such information are:______________________________________________________________________________
214
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4505

4510

•

Administrative information like checklists, importation rules, workflow codes or billingitems.

•

Clinical information like lab reports, discharge summaries, ECGs, potentially as PDI web
data.

Note that the person importing the Evidence Objects or Hardcopy can be assumed to have themost comprehensive and complete information available for the importing task. In case of
exceptions, the import may need to be aborted (see RAD TF-3: 4.60.4.1.2.2 for Exception
Management).
After the importation is done and the imported evidence objects are available through the ImageManager/ Image Archive (which may be indicated by an Instance Availability Notification), theenterprise may schedule subsequent steps like reading or reporting.
21.3.1.2 Scheduled Import Process Flow

4515

4520

4525

An enterprise internally schedules an import, e.g., associated with an external acquisition or read.
There may be other scheduling items, which are not within the scope of the Technical
Framework, but will be taken into account by the Enterprise:•

For external referrals, patient and order information needs to be conveyed to the externalEnterprise.

•

Clinical information may be received in addition to the DICOM information, e.g.,
electronic referrals, Lab Reports, Clinical Summaries, or PDI web information.

•

The importation of data is typically a scheduled event separate from how the data is used
(images to be reported, historical data to be used in-conjunction with a current procedure,etc.).

•The importation scheduling information may include instructions, e.g., which studies,
series or images are to be imported.

The following steps can be identified in the scheduled process flow:•

Using Scheduled Workflow, the relevant study data to be imported is available in thescheduled procedure step. Note that the Patient Registration and Procedure Ordering all
use the Scheduled Workflow Profile (See 3.3.1, 3.3.2, 3.3.3).

•

Depending on the type of media to be imported, the procedure step can be scheduled tothe appropriate Importing device (e.g., Film Scanner, PDI Workstation).

•

The SCHEDULED IMPORT Option is used to import the evidence objects and reconcile
the patient and procedure data (e.g., to change the recorded Patient ID to the local PatientID) using the Modality Worklist Query. The resultant DICOM objects are stored in the
PACS.

•

Errors and exceptions during import are handled by using Exception Management
described in RAD TF-3: 4.60.4.1.2.2.

4530

4535

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
•
4540

4545

Subsequent steps may be•

performed, such as implicit post-processing (see section 3.3.5);•

scheduled for a Post-Processing or Reporting Workflow, probably involving the
Availability Notification Option.

This process flow requires that the Patient be registered and that procedure step(s) be scheduled
for the importation. Associated Patient Registration Scheduling, and subsequent Availability or
Notification transactions are part of the Scheduled Workflow (See Section 3.3). The following
sequence of steps describes the typical process flow for the scheduled import of patient data.
Department System
Scheduler/ Order
FillerImporterImage
Manager/
Image
Archive
Query Modality
Worklist [RAD-5]

Import Procedure Step
In Progress [RAD-59]

Import Procedure Step
In Progress [RAD-59]

Imported Objects
Stored [RAD-61]

Import Procedure Step
Completed [RAD-60]

Perform
ImportImport Procedure Step
Completed [RAD-60]

Storage Commitment[RAD-10]Figure 21.3.1-1: Scheduled Import Reconciliation Workflow Process Flow4550______________________________________________________________________________
216
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
21.3.1.2.1

Scheduled Import Data Reconciliation

Importation requires that some of the Patient/Procedure information be treated differently thanprescribed in Scheduled Workflow.
4555

4560

The Study UID provided by the Modality Worklist shall be ignored and the reconciliation rules
shall be followed. As part of the import process, the Importer reconciles the patient data as
needed (e.g., to change the recorded Patient ID to the local Patient ID). See RAD TF-2:
Appendix A.5 for a full list of the reconciliation requirements. The original DICOM object
identifiers must be maintained in the imported DICOM Composite Objects. The policies of theimporting enterprise will determine•

if demographics from the Import Data can be used (e.g., Birth Date, Patient Sex)•

whether or how enterprise-specific codes in the imported data are coerced or ignored

21.3.1.3 Unscheduled Import Process Flow4565

An enterprise has received evidence objects for import that are not part of an order or scheduled
procedure in one of its information systems, e.g., relevant priors prior to a consultation. There isno scheduled procedure to trigger the importation. The actual task of importation may be abatched process that does not schedule individual importations.
•

4570

Aside from the physical media (e.g., films, CDs), there may be clinical information in
addition to the DICOM data in electronic, written or oral format, such as referral letters
The incorporation of this information into the Enterprise is out of scope for the Import
Reconciliation Workflow.

The following steps can be identified in this process flow:•

The User does the import at an appropriate device (e.g., a film scanner is used to digitize
films, a workstation with PDI capabilities is used to import PDI media).

•

The UNSCHEDULED IMPORT Option is used to retrieve the Patient Demographics
information, import the Evidence Objects and to reconcile the patient data (e.g., tochange the recorded Patient ID to the local Patient ID) using the Patient Demographics
Query. The resultant DICOM objects are stored in the PACS.

•

Errors and exceptions during import are handled by using Exception Management
described in RAD TF-3: 4.60.1.2.2.

•

The Evidence Objects are available from the PACS and may be used in subsequentscheduled or unscheduled steps, or at a later time.

4575

4580

4585

This process flow requires that the Patient be registered. Associated Patient Registration, andsubsequent Availability or Notification transactions are part of the Scheduled Workflow (See
Section 3.3). The following sequence of steps describes the typical process flow for theunscheduled import of patient data.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Demographic
Supplier

Department System
Scheduler/ Order
FillerImage
Manager/
Image
Archive

Importer

Patient
Demographic
Query [ITI-21]

Import Procedure Step
In Progress [RAD-59]

Import Procedure Step
In Progress [RAD-59]

Imported Objects
Stored [RAD-61]

Import Procedure Step
Completed [RAD-60]

Perform
ImportImport Procedure Step
Completed [RAD-60]

Storage Commitment[RAD-10]Figure 21.3.1-2: Unscheduled Import Reconciliation Workflow Process Flow______________________________________________________________________________
218
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
4590

21.3.1.3.1

Unscheduled Import Data Reconciliation

As part of the import process, the Importer reconciles the patient data as needed (e.g., to change
the recorded Patient ID to the local Patient ID). The original DICOM object identifiers must be
maintained in the imported DICOM Composite Objects in order to maintain the relationship ofthe Images within the Study (See RAD TF-2: Appendix A.5).
4595

The policies of the importing enterprise will determine•

whether demographics from the Import Data can be used (e.g., Birth Dates, Patient Sex)•

whether or how enterprise-specific codes in the imported data are coerced or ignored

21.3.2 Import Exception Management Workflow
4600

4605

4610

Exception management Workflow is required for Import Reconciliation Workflow. This caseaddresses the need to manage errors generated through the Import Reconciliation Workflow suchas:•

Selection of the incorrect Scheduled Procedure Step from the Modality Worklist•

Selection of the incorrect Patient Demographics from the Patient Demographics List•

The inability to support the DICOM Composite Objects to be imported•

Equipment Failure•

Bad media

Some of these exception cases are addressed using required functionality for IHE actors in the
Import Reconciliation Workflow and Scheduled Workflow Profiles, while others make use of the
IMPORT PPS EXCEPTION MANAGEMENT (See RAD TF-3: 4.60.4.1.2.2). The following
numbered items list exception cases that shall be supported by the actors listed in each item.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

22 Radiation Exposure Monitoring (REM) Integration Profile

4615

This Integration Profile specifies how details of radiation exposure resulting from imaging
procedures are exchanged among the imaging systems, local dose information management
systems and cross-institutional systems such as dose registries. The data flow in the profile isintended to facilitate recording individual procedure dose information, collecting dose data
related to specific patients, and performing population analysis.
Use of the relevant DICOM objects (CT Dose SR, Projection X-Ray Dose SR) is clarified andconstrained.

4620

4625

4630

The Profile focuses on conveying the details of individual irradiation events. A proper radiation
exposure management program at an imaging facility would involve a medical physicist anddefine such things as local policies, local reporting requirements, annual reviews, etc. Although
this Profile is intended to facilitate such activities, it does not define such policies, reports orprocessing, or in itself constitute a radiation exposure management program.
The Profile addresses dose reporting for imaging procedures performed on CT and projection Xray systems, including mammography. It does not currently address procedures such as nuclear
medicine (PET or SPECT), radiotherapy, or implanted seeds.
The Profile is intended to support quality assurance (QA) of the technical process (was the dose
appropriate for the procedure performed). It is less suited to QA of the ordering process (was theprocedure ordered/scheduled appropriate for the indications (appropriateness criteria)), or QA of
the operational process (were any differences between the procedure scheduled and theprocedure performed justified by the situation/equipment/patient and appropriately approved).
Background4635

In the vast majority of medical procedures involving radiation, the potential benefit to thepatients’ health far outweighs the potential risk, but the trade-off should not be overlooked, andtechnological mechanisms can facilitate a conscious evaluation of that trade-off.
Estimating radiation dose delivered to patients for medical purposes can facilitate a number ofimportant activities:

4640

4645

•

For facilities exposing patients to radiation, monitoring such exposures can help ensure
their policies, procedures and protocols are adequate and being followed appropriately.

•

For imaging physicians, monitoring such exposures can assist them in determining howchanges in techniques and protocols impact radiation dose as well as image quality. This
will enable them to maintain patient doses As Low As Reasonably Achievable(ALARA).

•For patients’ physicians, overall data provided from monitoring such exposures can help
them determine (in consultation with the imaging physician) if the benefit from thediagnostic information provided by an individual examination (or additional
examinations) outweigh any small risk that may be associated with the imaging exam.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•For medical physicists, having such post-procedure information available for individual
patients may help them make essential patient-specific dose estimates for pregnant
patients or patients exhibiting skin erythema as a result of long fluoroscopy examinations.

•

For professional societies and regulatory agencies, a collection of exposure data can be
useful when setting or reviewing radiation dose related guidelines and regulations. Manysuch groups have expressed a desire to establish standards of practice or dose reference
levels based on a quantitative understanding of current practice, however they have foundit prohibitively difficult to collect such data.

•

For physicists and physicians, this kind of data can be vital to answering some of thefundamental scientific questions that remain and developing a more detailed
understanding of the health impacts of radiation exposure and how it should be measured
and managed.

4650

4655

4660

However, it is important to understand the technical and practical limitations of such dosemonitoring and the reasons why the monitored values may not accurately provide the radiationdose administered to the patient:•

The values provided by this tool are not “measurements” but only calculated estimates.

•

For computed tomography, “CTDI” is a dose estimate to a standard plastic phantom.
Plastic is not human tissue. Therefore, CTDI should not be represented as the dose
received by the patient.

•

For planar or projection imaging, the recorded values may be exposure, skin dose orsome other value that may not be patient’s body or organ dose.

•

It is inappropriate and inaccurate to add up dose estimates received by different parts ofthe body into a single cumulative value.

4665

4670

Despite such limitations, interest in monitoring radiation dose estimates is clearly expressed insuch documents as the European directive Euratom 97/43 and the American College ofRadiology Dose Whitepaper [1]. DICOM, with advice from the IEC, AAPM, ACR, NCRP andothers, developed DICOM Dose objects appropriate for radiation dose monitoring
4675

By profiling automated methods of distribution, dose information can be collected and evaluated
without imposing a significant administrative burden on staff otherwise occupied with caring forpatients.

22.1 Actors/ Transactions
4680

Figure 22.1-1 shows the actors directly involved in the Radiation Exposure Monitoring
Integration Profile and the relevant transactions between them. Other actors that may be
indirectly involved due to their participation in other relevant transactions are not necessarily
shown.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Dose
Register↑ [RAD-63] Submit Dose Information

Dose Info
Reporter↓ [RAD-64] Query Dose Information↓ [RAD-65] Retrieve Dose Information
Image
Archive

Image
Manager← [RAD-64] Query Dose Information← [RAD-65] Retrieve Dose Information

Dose Info
Consumer↑ [RAD-62] Store Dose Information↑ [RAD-10] Storage Commitment

Acquisition
Modality→ [RAD-62] Store Dose Information

4685

4690

Figure 22.1-1: Radiation Exposure Monitoring - Actor Diagram

Table 22.1-1 lists the transactions for each actor directly involved in the Radiation Exposure
Monitoring Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile and that implementations may choose
to support is listed in Volume I, Section 22.2.
Table 22.1-1: Radiation Exposure Monitoring – Actors and Transactions
ActorsTransactions

Optionality

Section in
Volume 2/3

R

4.62

Acquisition Modality

Store Dose Information
Storage Commitment

R

4.10

Image Manager/Archive

Store Dose Information

R

4.62

Storage Commitment

R

4.10

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsTransactions

Dose Information Reporter

Dose Information Consumer

Dose Registry

4695

4700

Optionality

Section in
Volume 2/3

Query Dose Information

R

4.64

Retrieve Dose Information

R

4.65

Query Dose Information

R

4.64

Retrieve Dose Information

R

4.65

Submit Dose Information

R

4.63

Store Dose Information

R

4.62

Query Dose Information

R

4.64

Retrieve Dose Information

R

4.65

Store Dose Information

R

4.62

Submit Dose Information

R

4.63

An Acquisition Modality Actor in this profile might not necessarily generate the irradiation
itself. An Acquisition Modality Actor may generate Dose objects on behalf of an irradiating
modality system based on irradiation details obtained by manual input and/or some proprietary
method, as long as it can do so completely and correctly.
Actors are encouraged to describe in their DICOM Conformance Statement additional details of
how they implement specific DICOM-based transactions (e.g., the time frame in which an
Acquisition Modality is able to store a Dose object relative to the completion of the irradiation
event).

22.2 Radiation Exposure Monitoring Integration Profile Options
4705

Options that may be selected for this Integration Profile are listed in the Table 22.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
Currently there are no options defined in this profile.
Table 22.2-1: Radiation Exposure Monitoring – Actors and Options
Actor

OptionsVol. &Section

Acquisition Modality

No options defined--

Image Manager/Archive

No options defined--

Dose Information Reporter

No options defined--

Dose Information Consumer

No options defined--

Dose Registry

No options defined

--

4710

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

22.3 Radiation Exposure Monitoring Process Flow
This Profile addresses the flow of dose information from the source, through the organization
and beyond. It does not mandate, but is intended to facilitate the ability to do things like:

4715

4720

•

view the estimated dose a patient (or particular organs) received for a certain exam•

determine if the estimated dose for a given procedure, system or physician regularly
exceeds some reference level, policy trigger or is otherwise an "outlier" requiring further
investigation•

compute the population "dose summary" for a specific exam in a certain hospital orregion•compute the population "dose summary" for a certain pathology or indication•compare exam-specific "dose summaries" against other sites/regions, against local policy
targets or against standards of practice

Note:

4725

4730

To summarize dose for a specific exam type or pathology, the Dose Information Reporter needs to know suchdetails for each dose object. IHE has required that such information be provided in the dose objects as codedvalues so they will be machine readable. If consistent codes are present in the dose objects, they can simply besorted or mapped by a lookup table (See RAD TF-1 Appendix I.1.1 Code Set Management). Alternatively a Dose
Information Reporter might be grouped with a DSS/Order Filler so such details could be obtained for each
Accession #. In either case, a critical task for sites wishing to do such analysis is to choose a set of codes forexam types and pathologies and to distribute and use them consistently across their systems.

22.3.1 General Case
Typically, irradiation events occur on X-ray based imaging modalities, which record them in
Dose objects that are part of the same study as the images and stored to the ImageManager/Archive.

4735

In many organizations, a Dose Information Reporter will collect Dose objects covering aparticular period (e.g., today, this week or last month), analyze them, compare to site policy andgenerate summary reports.
All, or a sampled subset of the Dose objects might be submitted to a National Registry tofacilitate composing population statistics and other research. Such Dose objects will generally
undergo a configurable de-identification process prior to submission.

4740______________________________________________________________________________
224
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Acquisition
Acquisition
Modality 2
Modality
Acquisition(CT) 2(CT) 2
Modality(CT)

Acquisition
Acquisition
Modality 1
Modality
Acquisition(XR) 1(XR) 1Modality(XR)

Perform
Study“Image”
Mgr/Archive

Dose
Information
Reporter

Dose Register

Store Dose Information (XR)
Storage Commitment

Perform
Study

Store Dose Information (CT)Storage Commitment...
Query Dose Information

Initiate Weekly
Report Task

Retrieve Dose Information
Generate Weekly
Reports...
Query Dose Information

Prepare Monthly
Submission

Retrieve Dose Information
Select and De-identify
Reports
Submit Dose Information

Perform
Population
Analysis

Figure 22.3-1: Radiation Exposure Monitoring – General Case

22.3.24745

Real-World Use Cases

To provide additional context for the General Case process flow, the following use cases
describe real-world applications of the dose information.
Use Case:

Department QA (Process Control)

4750

Data will generally be continuously collected and evaluated on all procedures. Process control
and data analysis would focus on local variations attributable to x-ray equipment, operators,
procedures and ordering physicians. For example:

4755

As part of the departmental quality improvement program, the hospital’s medical physicist
accesses the Dose Information Reporter to carry out his bi-monthly assessment of radiation
dose. For a selected set of procedures, the dose-area product of each x-ray procedure isevaluated for each room. No significant variation of the average is found over the last 6months. Another report compares average dose for different performing radiologists over______________________________________________________________________________
225
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
several interventional procedures, and a third report compares performing technologists for
CT and radiographic exams.

4760

4765

4770

It becomes clear that for a certain interventional procedure a newly arrived radiologist tends
to generate 2 to 3 times the dose-area product of his colleagues, whose averages are in anarrow cluster well below the newcomer. While the dose-area product sub-total influoroscopy is similar among the radiologists (and is consistent with the average fluoroscopy
time of the report), there is a significant discrepancy in dose-area product for the acquisition
sub-total. The number of acquired images (higher than the departmental average) also
corroborates this.
The medical physicist writes a memo to the department chair, who raises the issue at the
weekly radiologist meeting. Upon discussion, it becomes clear the radiologist uses a
supplementary acquisition which his colleagues do not. After more discussion, theradiologists agree that the acquisition, although moderately useful, probably does not bringany information that would not be picked up in the rest of the exam, and it is agreed it should
not be done. The medical physicist reviews the situation a month later, and is reassured thatthe results show all radiologists now have similar dose-area product for that procedure.
Hospitals generally have policies relating to patient radiation dose, often benchmarking
performance estimates against published reference levels. Policies (and reference levels) areoften broken down by procedure, patient age group, and perhaps weight group, or gender.

4775

Analysis tools can help sites monitor whether policies are being followed, and measure progress
toward improvement targets. While image quality generally sets the low side limit on dose (toolow and the images are unacceptable to the radiologists), QA programs can be an effective way
to counter dose creep, establish upper trigger levels and encourage lower values.
Use Case:

Patient Impact Evaluation

4780

A few days after a CT exam is carried out for a young female patient, the referring physician
identifies the patient as pregnant (which was not known at the time of the scan). The referring
physician requests an evaluation of the risk to the fetus from the radiologist who read the exam.
The radiologist requests a hospital medical physicist to provide an estimate of the radiation dose
received by the uterus in the course of the CT exam.

4785

The medical physicist retrieves the images and dose data for the study in question, anddetermines with the help of the radiologist which series encompass the uterus. Knowing which
series are of interest, the medical physicist is then able to leverage the dose indicators and weightof the patient contained in the dose and image objects to estimate the total dose to the uterus.

4790

4795

How the information is recorded and distributed will vary, but in this particular hospital, the dose
estimate is then provided to the clinical coordinator of the department, who enters it in the RIS,
appending a statement to the report (which had already been signed off), and demoting the statusof the study to "pending signature". Before signing off the report, the radiologist completes theaddendum with her estimate of the risk to the fetus given the dose measurement, andcommunicates this result by phone to the referring physician, who also receives the written
addendum electronically signed by the radiologist a few days later.
______________________________________________________________________________
226
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Important analysis details include time/date of scans, body area irradiated, exposure values.
Use Case:

4800

4805

Population Dose and Dose Indicators

Organizations wishing to assess Population Dose and Dose Indicators will often set up a Dose
Registry. A sampling of dose estimates with reasonable accuracy are collected from a number ofclinical sites, often for specific targeted procedures. It is not necessary that every procedure
performed be collected; a representative sample of procedures is sufficient. That being said, it
may be easier for a dose registry to discard a portion of the procedures submitted than to try andget each submitting site to follow the same regimen for selecting procedures to submit.
Note that conversion of estimated dose values to patient or population risk involves complex
scientific questions. Streamlining the collection of additional, more detailed data can only help.
For further discussion, see RAD TF-1: Appendix I – Deployment of Dose Registries.
Use Case:

4810

Dose Reference Levels

Quantitative Dose Guidelines are often distributed in the form of Dose Reference Levels fortypical procedures for groups of patients of different characteristics (e.g., a target dose level tostay below for adult head studies).
Such guidelines are often the logical result of analyzing Population Dose or other data mining
performed by a professional society or regulatory body.
Use Case:

4815

Imaging facilities may find it useful to compare their dose profile by modality, exam type, andpathology to other facilities of the same type, facilities in the same region, and to the nation as awhole. A national radiation dose registry might provide facilities submitting data with reports
comparing them to regional and national benchmarks.
Use Case:

4820

4825

Site Benchmarking

Population Epidemiology

To analyze certain population epidemiology questions, e.g., the occupational hazards of being aradiologist, one has patients with a known disease and would like to use the patients’ radiation
history to estimate the likelihood of radiogenic etiology. Requirements include access to acomplete radiation history of each such patient. Because of long latent periods, data must bearchived in a manner that makes it both physically readable and dosimetrically intelligible years,
or decades, after it is written.
Use Case:

Clinical Trials

The radiation dose can be an important component of a clinical trial. For example, a trial of a
proposed low-dose CT lung screening procedure would benefit from being able to collect dose
data to balance against the resulting detection rates for a proper trade-off analysis. Cosubmission of image and Dose objects could facilitate this.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
4830

Use Case:

4835

Some regulations already require that Ka,r be displayed on fluoroscopy systems within sight ofthe primary operator. This permits the operator to factor radiation effects into the continuous
clinical benefit-risk analysis occurring during any procedure (keeping in mind that Ka,r is not thesame as cumulative skin dose). Such direct display can be handled by the modality and has noneed of the transactions provided by this profile
Use Case:

4840

4850

Clinical Management

Dose estimates and dose estimate maps can facilitate planning for subsequent procedures (suchas deciding how much time to allow for tissue to heal, or deciding what direction to image fromto avoid damaged tissues). Particularly for interventional fluoroscopy, the dose distributiondelivered by each procedure should be part of the patients’ medical record.
Use Case:

4845

Procedure Operational Awareness (Quasi-realtime)

Longitudinal Patient Dose Record

The lifetime radiation dose received by a patient can be stored and retrieved from a longitudinal
record, whether it is stored as part of the entire patient history, or as a separate entity. This may
in future form a vital source of information for clinical decision-making with respect to theappropriateness and risk of an additional procedure, as well as remediation in the event of an
unfortunate outcome. As methods evolve for estimating effective dose to radio-sensitive tissues
and quantifying cancer risk, these can be retrospectively applied to stored dose information. Thisuse case is distinct from registry use cases, since the goal is to track the individual, rather than
population, dose. It is distinct from the Clinical Management use case, since it spans a longer
term, multiple episodes of care and multiple sites.
This use case necessarily requires support of acquisition and collation of dose information frommultiple acquisition sites, since a patient may be provided healthcare at many sites over their
entire life time.
22.3.3 Example REM Profile Deployments

4855

These examples are intended to illustrate a few ways the Radiation Exposure Monitoring Profilemight be deployed inside a hospital or clinic. It is not intended to be normative, or to show all
possible deployments. Further practical examples related to the use of a Registry appear in
Appendix I.
22.3.3.1 A Hospital Scenario

4860

The Radiology PACS would perhaps implement the Image Manager/Archive Actor in thisprofile and also the PIR, SWF Profiles.
The RIS might implement the Dose Information Reporter Actor in this profile and be groupedwith a DSS/Order Filler supporting the SWF and PIR Profiles.

4865

A Dose Mapping Workstation might implement both the Dose Information Consumer (to obtain
Dose objects) and the Evidence Creator (to submit new ones).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Perhaps Cardiology has a separate PACS which also implements an Image Manager/Archive forthe cardiology modalities. The Dose Information Reporter (in the Radiology RIS) could query
both Archives and manage dose for the hospital in one place.
22.3.3.2 An Imaging Clinic Scenario
4870

Many imaging clinics will have a PACS and could follow a similar layout to the Hospital above.
Alternatively, a PACS-less clinic which decides they do not need long term archiving or
reconciliation of the Dose objects might not have an Image Manager/Archive.

4875

The Office Management System or a standalone workstation could implement the Dose
Information Reporter, and takes advantage of its ability to receive Dose objects directly from thelocal modalities.
22.3.3.3 A Longitudinal Patient Record Scenario
Multiple sites, including hospitals and imaging clinics, implement Acquisition Modalities and/or
Image Manager/Archives that provide information in response to queries from a local Dose
Information Reporter.

4880

4885

4890

The local Dose Information Reporter transmits identifiable (as opposed to de-identified) dose
information to a remote Dose Register nominated by the patient to act as their lifetime repositoryof longitudinal dose information. Each local site may use different forms of the patient’s nameand different domains for patient identifier, and accordingly the Dose Information Reportershould include multiple identifiers for different domains, and/or regional or national identifiers,
if known, and the Dose Register may need to be grouped with a PIX Manager or similar
mechanism to resolve identities. See also the issues raised in the Multiple ImageManager/Archive (MIMA) Trial Implementation supplement.
If the remote Dose Register is grouped with its own Dose Information Reporter Actor, then given
the appropriate authorization by the patient, another local site with a Dose Consumer Actor may
access the information to make clinical decisions.
Additionally, if remote Dose Register and/or Dose Information Reporter is also capable ofmodeling effective dose using organ segmentation information, it may want to receive and store
the images reconstructed from the irradiation events described in the dose objects, and hence tobe grouped with a remote Image Manager/Archive Actor.

4895

22.4 Radiation Exposure Monitoring Profile Security Considerations
Dose Objects have the same security considerations as images.

4900

Security and Privacy policies may require the de-identification of some or all of the PHI details
prior to the submission or use of Dose Objects (See RAD TF-3: 4.63.4.1.2.1). De-identification
behavior may need to vary by destination due to differences in PHI exposure risk and the need toretain some details, such as approximate patient age or weight, when performing Radiation Doseanalysis.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

22.5 Relation to Other Profiles
Several synergies and interactions of the Radiation Exposure Monitoring Profile with otherprofiles are specifically called out here.
4905

22.5.1

Radiology Profiles

22.5.1.1 Portable Data for Imaging (PDI)The Dose objects from this profile may be included on PDI media, either along with the rest of
the study data to provide a “complete package”, or on their own as a way of conveying Doseobjects to a patient, another organization or a dose registry.
4910

22.5.1.2 Patient Identification Reconciliation (PIR)An Image Manager/Archive which also implements the Patient Identification Reconciliation
Profile is expected to reconcile the Dose objects along with the rest of the DICOM objects in apatients’ study. This is highly desirable.
22.5.1.3 Teaching Files and Clinical Trials Export (TCE)4915

As DICOM objects, the Dose objects can be referenced in a TCE manifest and processed alongwith other objects from a study. This could allow submitting dose details in clinical trials wheresuch information is relevant, or including dose details in a teaching file, perhaps one specificallyaddressing protocol dose and the effects on image quality.
22.5.24920

ITI Profiles

22.5.2.1 Patient Identity Cross-referencing (PIX)The PIX Profile could clearly be useful if there is a need to collate patient dose records acrossmultiple Patient ID Domains. It could also be useful if a single Dose Information Reporter isquerying multiple Image Manager/Archives in different Patient ID Domains.
22.5.2.2 Cross-Enterprise Document Sharing (XD*)

4925

Since Dose objects are normal DICOM SR objects, the collection of XDS Profiles (XDS, XDS-I,
XDR, XDM, etc.) can be used to distribute or access dose records across multiple sites.
22.5.2.3 Consistent Time (CT)Consistent Time is particularly useful if a gantry and reader are trying to compose a Dose object
by synchronizing study details based on timestamps.

4930

22.5.2.4 Audit Trail and Node Authentication (ATNA)
Audit events relevant to the transactions of the REM Profile are identified in RAD TF-3: Table
5.1-2 in the Radiology Audit Trail Option.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

23 Mammography Acquisition Workflow (MAWF)
4935

This section intentionally, temporarily left blank.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

24 MR Diffusion Imaging (DIFF)
This section intentionally, temporarily left blank.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

4940

25 CT/MR Perfusion Imaging with Contrast (PERF)
This section intentionally, temporarily left blank.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

26 Basic Image Review (BIR)
This section intentionally, temporarily left blank.
4945______________________________________________________________________________
234
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

27 Chest X-Ray CAD Display (CXCAD)This section intentionally, temporarily left blank.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

28 Imaging Object Change Management (IOCM)
4950

4955

4960

The Imaging Object Change Management Integration Profile (IOCM) specifies how one actor
communicates local changes applied on existing imaging objects to other actors that manage
copies of the modified imaging objects in their own local systems. The supported changes
include (1) object rejection due to quality or patient safety reasons, (2) correction of incorrect
modality worklist entry selection, and (3) expiration of objects due to data retention
requirements. It defines how changes are captured and how to communicate these changes.
IHE Scheduled Workflow Profile defines an PPS Exception Management Option (RAD TF1:3.3.4 and RAD TF-2:4.7.4.1.3.1) which specifies how to correct the incorrectly selected
worklist entry after the Modality Performed Procedure Step In Progress transaction has been
issued but before the Modality Performed Procedure Step Completed transaction is issued. This
Imaging Object Change Management Profile addresses the use case in which the incorrect
modality worklist selection is detected after the Modality Performed Procedure Step Completed
transaction is issued.
The required workflow steps for the DSS/OF and the actors grouped with Change Requester are
specified in the Scheduled Workflow Profile.

28.1 Actors/ Transactions
4965

Figures 28.1-1 shows the actors directly involved in the Imaging Object Change Management
Integration Profile and the relevant transactions between them. Other actors that may be
indirectly involved due to their participation in Scheduled Workflow, Consistent Presentation of
Images, etc. are not necessarily shown.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

ChangeRequester↓ Rejection Note Stored [RAD-66]↓ Replacement Instances Stored [RAD-74]

 Query Images [RAD-14]
 Retrieve Images [RAD-16]
 Query Key Image Notes [RAD-30]
 Retrieve Key Image Notes [RAD-31]
Image
Manager

Image
Archive

Image Display

4970
Figure 28.1-1: Imaging Object Change Management Actor Diagram related to SWF

4975

4980

Table 28.1-1 lists the transactions for each actor directly involved in the Imaging Object ChangeManagement Profile. In order to claim support of this Integration Profile, an implementationmust perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A
complete list of options defined by this Integration Profile and that implementations may choose
to support is listed in Section 28.2.
Table 28.1-1: Imaging Object Change Management Integration Profile - Actors andTransactions
Actors

Optionality

Section in
Vol. 2/3

Rejection Note Stored

R

4.66

Replacement Instances Stored

R

4.74

Image Manager / Archive

Rejection Note Stored

R

4.66

Replacement Instances Stored

R

4.74

Image Display

Query Images

R

4.14

Change Requester

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsTransactions

Optionality

Section in
Vol. 2/3

Retrieve Images

R

4.16

Query Key Image Notes

R

4.30

Retrieve Key Image Notes

R

4.31

28.2 Imaging Object Change Management Integration Profile Options
Options that may be selected for this Integration Profile are listed in the Table 28.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
4985

Table 28.2-1: Imaging Object Change Management - Actors and Options
Actor

OptionsVol. & Section

Change Requester

No option defined-

Image Manager / Archive

No option defined-

Image Display

No option defined-

28.3 Imaging Object Change Management Integration Profile Actor
Groupings and Profile Interactions

4990

Imaging Object Change Management builds upon the underlying Actor transactions defined inother Profiles. For this reason, certain IOCM Profile actors shall be grouped with actors fromother Profiles as defined in Table 28.3-1.
Table 28.3-1: Imaging Object Change Management Integration Profile - Actors andTransactions
Integration
ProfileActor

Imaging Object
ChangeManagement

Change Requester(see note 1)

Grouped With
ProfileComments

Actor

Scheduled
Workflow

Acquisition
Modality

Scheduled
Workflow

Evidence Creator

Scheduled
Workflow

Image Manager/
Image Archive

Supportcommunication ofprocedure steps andstorage commitment
when Change
Requester is groupedwith Acquisition
Modality, ImageManager/Image
Archive or Evidence
Creator.
Defines how ImageManager/Image
Archive can obtainscheduled worklist inorder to correct themodality worklist
selection of theacquired instances.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Integration
ProfileActor

ProfileComments

Actor

Image Manager/
Image Archive

Scheduled
Workflow

Image Manager/
Image Archive

Support ImageManager to ImageManager change
management if
Multiple Patient
Identity Resolution
Option is supported.

Image Display

Scheduled
Workflow

Image Display

SWF defines message
semantics for queryretrieval

Change Requester(see note 1)

Patient
InformatioRecon
ciliation

Acquisition
Modality

Patient
Information
Reconciliation

Image Manager/
Image Archive

Patient
Information
Reconciliation

Image Manager/
Image Archive

PIR defines the patient
information
reconciliation
mechanisms that shallbe supported by these
actors. IOCM shallnot be used as analternative mechanism
for handling patient
information
reconciliation use
cases.

Image Manager/
Image Archive

4995

Grouped With

Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to section 18.4 for additional
requirements on the Imaging Document Consumer.

28.4 Imaging Object Change Management Process Flow
Imaging Object Change Management covers the following use cases:

5000

5005

•

Data Retention Expiration•

Correction or Rejection of imaging instances for Quality Reasons•

Correction or Rejection of imaging instances for Patient Safety Reasons•

Correction of Modality Worklist Selection

The following use cases generally apply to all imaging objects as well as non-imaging objects
including Grayscale Softcopy Presentation State (GSPS), Key Object Selection Document(KOS), Structured Report (SR), etc. although the examples may focus on the images themselves
for simplicity.
The start and completion of creating Rejection Notes, and Replacement Instances if necessary,
are reported as Procedure Steps In-Progress/Completed by the relevant IHE workflow actor thathas been grouped with the Change Requester (either an Acquisition Modality or an Evidence
Creator).

5010

The Procedure Step transactions, Storage Commitment transaction, Query Modality Worklist
transaction and the Query/ Retrieve Images transactions in the following diagrams are part ofRadiology Scheduled Workflow as an example IHE Workflow Profile. They are not part of the______________________________________________________________________________
239
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Imaging Object Change Management Profile and are only included in the diagrams forillustration.
5015

Note:

There are existing profiles defined in the IHE Technical Framework that are also designed to manage changes indifferent aspects of imaging objects (e.g., Patient Information Reconciliation, Import Reconciliation Workflow,etc.) Vendors should continue to follow those integration profiles for their respective use cases.

28.4.1 Use Case: Data Retention Expiration
Instances may be deleted to comply with data retention policies.
5020

5025

•

A local Image Manager / Archive, supporting the Multiple Identity Resolution Option in
IHE Scheduled Workflow Profile, stores instances to a centralized Image Manager /Archive for long term storage (IHE Radiology Supplement MIMA [RAD-70]).

•

Later, according to the data retention policy of the local Image Manager / Archive,
selected studies are deleted internally.

•

The local Image Manager / Archive has implemented the Change Requester Actor of the
IOCM Profile to communicate these changes to the centralized Image Manager / Archive.

•

The local Image Manager / Archive, as an IOCM Change Requester, creates a Key
Object Selection (KOS) instance with a Selection Document Title of “Data Retention
Policy Expired” that lists the deleted instances, and sends this to the centralized ImageManager / Archive using the [RAD-66] transaction, followed by Storage Commitment[RAD-71].

•

The centralized Image Manager / Archive receives the deletion requests and deletes thereferenced studies accordingly.

5030

5035

The healthcare provider is responsible for drafting and implementing appropriate data retention
policies (see 28.4).

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Local ImageManager / Archive /Change Requester

Centralized Archive/ Image Manager /Archive
Image Manager Instances Stored [RAD-70]

Select expired
images to bedeletedRejection Note Stored [RAD-66]
Image Manager Storage Commitment [RAD-71](for KOS)

5040

Delete rejected
imagesFigure 28.4.1-1: Process Flow for handling expired studies

28.4.2 Use Case: Image Rejection for Quality Reasons

5045

5050

5055

Instances may be deleted for quality reasons. The Change Requester may be grouped with an
Acquisition Modality Actor, an Evidence Creator Actor, or an Image Manager / Archive Actor,
depending on whether such QA happens on the modality, a separate workstation, or an image
manager.
Clinical aspect: The Technologist or Radiologist decides that certain images are not useful forclinical use, e.g., due to patient motion. While correcting image acquisition context data on a
Modality application, e.g., during quality control, the Technologist wants to mark these images
as "rejected" so that other systems correctly handle the rejected images according to local
policies. The procedure step has already been completed, and all images, including the rejected
images, have been stored to the Image Manager / Archive.
Site policies may determine if rejected images will be presented to users on later retrieval or not,as they may be of clinical relevance or for quality control monitoring. The Image Manager /Archive gets all images as well as change information, and then applies internal rules to fulfillsite policies.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Display/
Evidence Creator/
Change Requester
Selectimages to
be rejected

DSS / OFCreator PS In Progress [RAD-20](step: reject images)
Creator PS Completed [RAD-21](step: reject images)

Image Manager/
Image Archive

Creator PS In Progress [RAD-20](step: reject images)
Creator PS Completed [RAD-21](step: reject images)

Rejection Note Stored [RAD-66]

Provide or hide
rejected images
as configured

Storage Commitment [RAD-10](for the KOS)

Figure 28.4.2-1: Process Flow for handling rejected images

5060

5065

5070

Technical aspect: A user marks certain images of insufficient quality as "Rejected for Quality
Reasons" and selects a reason. The Evidence Creator, as a Change Requester, creates a Key
Object Selection (KOS) instance that references the rejected images with a Selection Document
Title of “Rejected for Quality Reasons” and the reason. It creates a Creator PPS (RAD-20), sets
it COMPLETED (including a reference to this KOS) and sends it to the DSS/OF (RAD-21). It
also stores the KOS to the Image Manager / Archive (RAD-66), and then uses the Storage
Commitment (RAD-10) transaction.
The Image Manager / Archive can be configured to provide such rejected images or to hide themfrom subsequent query/ retrieve responses. An Image Display, when receiving a "Rejected for
Quality Reasons" KOS, will display the images and / or KOS, or will hide both (RAD-16, perconfiguration).
Variant: Instead of an Evidence Creator being the Change Requester, an Image Manager is the
Change Requester. The only difference will be that the Image Manager acting as the Change
Requester does not have to create an MPPS referencing the Rejection Note or an MPPS
referencing the corrected images.

5075

28.4.3 Use Case: Image Correction for Patient Safety Reasons
Instances may be corrected (deleted and replaced) for patient safety reasons. The Change
Requester may be grouped with an Acquisition Modality Actor, an Evidence Creator Actor, or an
Image Manager/Archive, depending on whether such QA happens on the modality, a separate
workstation, or an image manager.

5080

Clinical aspect: The Technologist takes a left breast cranial caudal view (LCC), and didn’t
realize that the defaults were set for a right breast (RCC) view, thus the view is labeled
incorrectly. The acquisition has been set completed and images were sent to the PACS.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5085

5090

The Technologist wants to correct this view information at the Acquisition Modality or at the
nearby Quality Control Workstation (e.g., view code, view description, patient orientation,
laterality) and "update" the images in the PACS. For correct interpretation and diagnosis, theRadiologist depends on a correct view labeling. Incorrectly labeled views may confuse CAD
processing, and may also disturb proper display and navigation of images at a workstation. Thisis a patient safety issue; the incorrect image does not provide additional clinical information but
may be harmful, so it is not to be used any more.
The RIS may be notified about such changes, e.g., for logging or informing a user.
Acquisition
Modality /Change Requester
Acquireimages of
LCC view

Image Manager/
Image Archive

DSS/ OF

Modality Images Stored [RAD-8]

Correct
LCC to RCC
view/ image

MPPS Completed [RAD-7]

MPPS Completed [RAD-7]

MPPS In Progress [RAD-6](step: correct image)

MPPS In Progress [RAD-6](step: correct image)

Rejection Note Stored [RAD-66](marks incorrect For Processing/ Presentation images)
Replacement Instances Stored [RAD-74](correct RCC image)
Storage Commitment [RAD-10](correct RCC image and KOS)MPPS Completed [RAD-7](step: correct image)

MPPS Completed [RAD-7](step: correct image)

Detect correction
and hide the LCC
image

Figure 28.4.3-1: Process Flow for correction of image labeling

5095

5100

Technical aspect: The Acquisition Modality, as a Change Requester, creates and stores a Key
Object Selection (KOS) with a Selection Document Title of “Rejected for Patient Safety
Reasons” that lists the incorrect instances and sends this using Rejection Note Stored (RAD-66).
It creates corrected images and stores them (RAD-74). It also creates a Modality PS (RAD-6),
sets it COMPLETED (including references to both the corrected images and this KOS), andsends it to the DSS/OF (RAD-7).
The Image Manager/Archive, as a consequence of receiving the KOS, hides the incorrect images
from subsequent query/retrieve. An Image Display, when receiving a KOS with a Selection______________________________________________________________________________
243
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Document Title of “Rejected for Patient Safety Reasons”, does not display the KOS and its
referenced images (RAD-16).
5105

Variant: Instead of an Acquisition Modality being the Change Requester, an Image Manager isthe Change Requester. The only difference will be that the Image Manager acting as the Change
Requester does not have to create an MPPS referencing the Rejection Note or an MPPS
referencing the corrected images.
28.4.4 Use Case: Object Correction due to Modality Worklist Selection Error

5110

Clinical aspect: A patient arrives at the hospital for a scheduled procedure. The Technologist
selects a modality worklist entry for the procedure to be performed but mistakenly selects thewrong entry. The Technologist completes the acquisition step.
DSS/OF

Image Manager/
Image Archive

Acquisition Modality /Change Requester

Query Modality Worklist [RAD-5]
Select (wrong)
MWL Entry (SPS)
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6]

Modality Images
Stored [RAD-8]

Perform Acquisition(for wrong MWL entry)

Initiated as
Acquisition
Modality

Modality
Presentation StateStored [RAD-9]

Modality Procedure Step
Completed [RAD-7]
Completed (withwrong MWL entry)

Modality Procedure Step
Completed [RAD-7]
Completed (withwrong MWL entry)

Continue in next diagram

5115

Figure 28.4.4-1: Exception Management Workflow (Incorrect Worklist Entry Selected)
Note: Storage Commitment (RAD-10) is not shown in the diagrams above only for simplification of the diagrams.

Later, the Technologist or Radiologist identifies that patient or order information is incorrect for
the whole study. At this point there are two alternative scenarios that can follow:______________________________________________________________________________
244
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
5120

1. The originally acquired images are relevant to the originally scheduled procedure for thecorrect patient.
2. The originally acquired images are not relevant to the originally scheduled procedure forthe correct patient.

5125

5130

Regardless of which scenario occurs, if additional images need to be acquired for the actual
scheduled procedure for the correct patient, then acquisition of the new images shall be
performed according to Scheduled Workflow.
The first scenario is illustrated in Figure 28.4.4-2; the Technologist determines that the acquired
images are relevant to the actual scheduled procedure for the correct patient. In this case theTechnologist matches the originally acquired images against the originally scheduled procedure
for the correct patient using Quality Control tools provided by the Modality.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Manager/
Image Archive

DSS/OF

Acquisition Modality /Change Requester

Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6](For KOS)(For KOS)

Detect that wrong
MWL entry has been
selected. Begin
preparation of
Rejection Note.

Rejection Notes
Stored [RAD-66]
Modality Procedure Step
Completed [RAD-7](For KOS)

Modality Procedure Step
Completed [RAD-7](For KOS)

Query Modality Worklist [RAD-5]
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6](For repl. inst.)(For repl. inst.)

Select (right) MWL
Entry (SPS)

Update instances(for right MWL entry)

Initiated as
ChangeRequester

Replacement
Instances Stored[RAD-74](new study)
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7](For repl. inst.)(For repl. inst.)

Figure 28.4.4-2: Acquired Images are Relevant to Correct Procedure
Note: Storage Commitment (RAD-10) is not shown in the diagrams above only for simplification of the diagrams.

5135
The alternative scenario is that the Technologist determines that the originally acquired images
are not relevant to the actual scheduled procedure for the correct patient. This could be handled
in two different ways:
1. The originally acquired images are handled by the Technologist as an unscheduled case.
5140

2. A new procedure is scheduled for the correct patient on the DSS/OF and the originallyacquired images are updated to correspond to the new scheduled procedure obtained from
the Modality Worklist.
______________________________________________________________________________
246
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Figure 28.4.4-3 illustrates the correction of the images as an unscheduled case.
5145

The alternative approach of scheduling a new procedure on the DSS/OF is not illustrated here. It
would follow the normal Scheduled Workflow sequencing with the exception that rather thanacquiring new images, the originally acquired images would be updated to correspond to the newscheduled procedure obtained from the Modality Worklist.
DSS/OF

Image Manager/
Image Archive

Acquisition Modality /Change Requester

Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6](For KOS)(For KOS)

Detect that wrong
MWL entry has been
selected. Begin
preparation of
Rejection Note.

Rejection Notes
Stored [RAD-66]
Modality Procedure Step
Completed [RAD-7](For KOS)

Modality Procedure Step
Completed [RAD-7](For KOS)

Created SOP
Instances are not
relevant to thecorrect MWL entry
Modality Procedure Step Modality Procedure Step
In Progress [RAD-6]
In Progress [RAD-6](For repl. inst.)(For repl. inst.)

Initiated as
ChangeRequesterUpdate instances

Replacement
Instances Stored[RAD-74](new study)
Modality Procedure Step Modality Procedure Step
Completed [RAD-7]
Completed [RAD-7](For repl. inst.)

5150(For repl. inst.)

Figure 28.4.4-3: Acquired Images are Not Relevant to Correct Procedure and are Handled
as an Unscheduled Case
Note: Storage Commitment (RAD-10) is not shown in the diagrams above only for simplification of the diagrams.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5155

5160

5165

5170

5175

5180

5185

5190

Technical aspect: The Acquisition Modality creates the originally acquired images with theirheaders set to the information from the incorrectly selected modality worklist entry. It creates acorresponding MPPS (RAD-6), completes and sends it (RAD-7), and stores the images to the
Image Archive (RAD-8) (see Figure 28.4.4-1).
Later, the Technologist or the Radiologist detects the mistakes (see Figure 28.4.4-2). The
Acquisition Modality, as a Change Requester, sends a Rejection Note (RAD-66) KOS whichcontains references to the rejected SOP instances, the originally acquired images, to the ImageManager. It also creates a MPPS (RAD-6) referencing this Rejection Note, completes the MPPS
with the reference to the KOS and sends it to the Image Manager / Archive and DSS/OF (RAD7). The Image Manager receives the Rejection Note and makes all the referenced SOP instances
unavailable.
The technical aspects then vary depending upon whether or not the originally acquired images
are relevant to the actual scheduled procedure for the correct patient.
If it is determined that the originally acquired images are relevant to the actual scheduled
procedure for the correct patient then the Acquisition Modality selects the correct modality
worklist entry (RAD-5) and updates the originally acquired images (while the study is stillavailable at the Acquisition Modality without re-acquisition) with the correct information. The
corrected images are assigned new SOP Instance UIDs so that they can be distinguished from theoriginally acquired images which have already been exported. If the correct modality worklist
entry is not readily available, the Acquisition Modality queries the DSS/OF again, as illustrated
in Figure 28.4.4-2. In order to communicate the corrected images to other systems, theAcquisition Modality, as a Change Requester, creates a new MPPS with the correct informationfrom the modality worklist (RAD-5). It then stores the new set of corrected images to the ImageManager (RAD-74), and completes the MPPS and sends it (RAD-7).
Alternatively, if it is determined that the originally acquired images are not relevant to the actual
scheduled procedure for the correct patient then the Acquisition Modality either handles theimages as if they belong to an unscheduled procedure, or a new procedure for the acquired
images is entered on the DSS/OF. If treated as an unscheduled case as shown in Figure 28.4.4-3,
then there is no modality worklist entry to associate the originally acquired images with. The
images would thus require manual correction on the Acquisition Modality. The corrected images
are assigned new SOP Instance UIDs so that they can be distinguished from the originallyacquired images which have already been exported. In order to communicate the corrected
images to other systems, the Acquisition Modality, as a Change Requester, creates a new MPPS.
It then stores the new set of corrected images with manually corrected headers to the ImageManager (RAD-74), completes the MPPS and sends it (RAD-7).
Instead of being handled as an unscheduled case, a new procedure could be scheduled on the
DSS/OF. In this case the technical aspects would follow the normal Scheduled Workflow
sequencing with the exception that, rather than acquiring new images, the originally acquired
images would be updated to correspond to the new scheduled procedure obtained from theModality Worklist.
Note:

IHE Scheduled Workflow Profile defines an PPS Exception Management Option (RAD TF-1:3.3.4 and RAD TF2:4.7.4.1.3.1) which specifies how to correct the incorrectly selected worklist entry after the Modality Performed______________________________________________________________________________
248
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
5195

5200

5205

5210

Procedure Step In Progress transaction has been issued but before the Modality Performed Procedure Step
Completed transaction is issued. Notice that there is no external component involved in this situation since theacquired images usually have not been shared prior to MPPS complete or discontinued.

Variant: Instead of an Acquisition Modality being the Change Requester, an Image Manager isthe Change Requester. In this case, the Image Manager uses the received procedure informationfrom Procedure Scheduled (RAD-4) and Procedure Updated (RAD-13) to choose the correct
modality worklist, updates the images and creates a new set as described above. The ImageManager does not have to create an MPPS referencing the Rejection Note or an MPPS
referencing the corrected images.
Variant: Instead of selecting an incorrect modality worklist entry, the Technologist forgets tocomplete the previous worklist entry before starting the new acquisition. The acquired images
are incorrectly appended to an existing study of a different patient for a different procedure. As aresult, the resulting study becomes partially incorrect. Only the incorrect images and/or
presentation states are required to be corrected.

28.5 Imaging Object Change Management Security Considerations
The section describes the policies for reducing risks after correction or rejection at the Change
Requester.

5215

5220

Images that are marked as "rejected" for quality reasons (see 28.4.2) may or may not containclinically relevant information. They may be useful in certain situations. Sites may decide toprovide them regularly as part of a Study or may hide them at the Archive or at Workstations.
IHE supports such policies by defining configurable behavior at the Image Manager/ Image
Archive for storage and at the Image Display for presentation.
Incorrectly labeled images (see 28.4.3), e.g., containing a wrong patient orientation or laterality,
may mislead image interpretation and thus may be harmful to a patient. For patient safety
reasons, they are marked in order to not be used later; an Archive hides such images and does notprovide them in IHE-defined query and retrieve transactions.
IHE defines a Key Object Selection document with a special title code as a specific trigger to the
Image Manager for hiding incorrect instances (different from general Key Image Note use, RAD
TF-1: 8).

5225

5230

Note that a central correction mechanism at the Image Manager/ Image Archive decreases therisk for harmful or misleading use of rejected or incorrect images, such images are not included
in regular query results or retrieve transactions, and their presentation does not depend on local
configuration of individual workstations.
Rarely, race conditions may result from information in archived images that is not yet corrected,
e.g., due to latencies from asynchronous messaging. In this case, Image Displays may receiveand present inconsistent, incomplete or wrong information.
The correction and rejection mechanisms defined for IHE Imaging Object Change Management
Integration Profile will only correctly work in a system environment where each system______________________________________________________________________________
249
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5235

5240

5245

implements the corresponding Actors from this Integration Profile. In addition, the ImageManager/ Archive and Displays need to be configured in a way that meets the department orenterprise policies.
The correction and rejection mechanisms are capable of deleting or changing evidence of aperformed procedure. That means a malicious user or system can use this mechanism to hide a
mistake. Therefore the audit record should include information about who initiates the correction/ rejection as well as the reason of the initiation. Traceability is also available using theReferenced Instance Sequence (see RAD TF-3:4.74.4.1.2) in the header of the replacement
instances.
Since any actor can group with the Change Requester, it is important for the Image Manager /Archive to validate the source and authority of the Change Requester before rejecting any
referenced instances in the KOS. For example, the Image Manager / Archive can restrict
rejection of instances referenced in the received KOS if and only if the KOS is sent from thesame DICOM Application Entity as the original instances.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

29 Cross-Community Access for Imaging (XCA-I)
5250

The Cross-Community Access for Imaging (XCA-I) Integration Profile specifies actors andtransactions to query and retrieve patient-relevant medical imaging data being held by othercommunities.
Within a community, a group of facilities/enterprises shares clinical information via anestablished mechanism such as XDS-I (in which case the community can be referred to as an
XDS Affinity Domain). This profile addresses sharing between such communities.

5255

The XCA-I Profile extends the IT Infrastructure XCA Profile. XCA provides access toDiagnostic reports and Imaging Manifests. XCA-I provides access to the imaging objects
referenced in the Manifests. The reader of XCA-I is expected to have read and understood the
XCA Profile, including the meaning of terms such as Community, homeCommunityId, etc.

29.1 Actors/ Transactions
5260

5265

Figure 29.1-1 shows the actors defined in the Cross-Community Access for Imaging (XCA-I)
Profile and the transactions between them.
The shaded actors are NOT included in this profile but are shown to illustrate the full set ofactors that play a role other endpoint of transactions that ARE part of the profile (e.g., theDocument Registry Actor is an endpoint for the Registry Stored Query Transaction). As a result,the shaded actors are not listed in Table 29.1-1.

5270

5275

5280
______________________________________________________________________________
251
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Initiating Community

5285

XDS.b Document
Repository

XDS.b Document
Registry

XDS.b Document
Registry

XDS.b Document
Repository

 Retrieve
Document Set[ITI-43]

 Registry Stored
Query [ITI-18]

 Registry Stored
Query [ITI-18]

 Retrieve
Document Set[ITI-43]

XDS.b
Document
Consumer

5290

Responding Community

ImagingDocument
Consumer

Registry Stored
Query [ITI-18] 

XCA
Initiating
Gateway
Retrieve
RegistryStored Query
Document
Set[ITI-18] [ITI-43] Initiating
Imaging
Gateway

Cross Gateway
Query [ITI-38]
Cross Gateway
Retrieve [ITI-39] Cross Gateway Retrieve
Imaging Document Set[RAD-75]

XCA
Responding
Gateway
Responding
Imaging
Gateway

Retrieve Imaging Document Set[RAD-69] ↓Retrieve Imaging Document Set[RAD-69]

Imaging Document
Source5295

Figure 29.1-1: Cross-Community Access for Imaging Actor Diagram

5300

5305

Table 29.1-1 lists the transactions for each actor directly involved in the XCA-I Profile. To claim
support of this Profile, an implementation must perform the required transactions (labeled “R”).
Transactions labeled “O” are optional. A complete list of options defined by this Integration
Profile and that implementations may choose to support is listed in Volume 1, Section 29.2.
Table 29.1-1: Cross-Community Access for Imaging Integration Profile - Actors andTransactions
ActorsTransactions

Optionality

TF
Reference

Imaging Document Consumer

Retrieve Imaging Document Set[RAD-69]

R

RAD TF-3: 4.69

Imaging Document Source

Retrieve Imaging Document Set[RAD-69]

R

RAD TF-3: 4.69

Initiating Imaging Gateway

Retrieve Imaging Document Set[RAD-69]

R

RAD TF-3: 4.69

Cross Gateway Retrieve Imaging
Document Set [RAD-75]

R

RAD TF-3: 4.75

Cross Gateway Retrieve Imaging
Document Set [RAD-75]

R

RAD TF-3: 4.75

Responding Imaging Gateway______________________________________________________________________________
252
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
ActorsTransactions

Optionality

Retrieve Imaging Document Set[RAD-69]

R

TF
Reference
RAD TF-3: 4.69

29.1.1 Actor Requirements
The Responding Imaging Gateway shall support the use of Asynchronous Web Services
Methods (see ITI TF-2: Appendix V) for the RAD-75 transaction.
5310

The Initiating Imaging Gateway is required to support Asynchronous Web Services Exchange
for the RAD-69 Transaction.

29.2 XCA-I Profile Options
Options that may be selected for this Integration Profile are listed in the Table 29.2-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
5315

Table 29.2-1: Cross-Community Access for Imaging - Actors and Options
Actor

OptionsVol. & Section

Imaging Document Consumer

Asynchronous Web Services

Vol. 3, sec. 4.69.4.3

Initiating Imaging Gateway

Asynchronous Web Services

Vol. 3, Sec. 4.75.4.2
Vol. 3, sec. 4.69.4.3

Responding Imaging Gateway

No options defined-

Imaging Document Source

Asynchronous Web Services

Vol. 3, sec. 4.69.4.3

29.3 XCA-I Process Flow
The XCA-I Profile addresses sharing image data sets between communities.
29.3.1 Use Case – Image set sharing between communities
5320

Assume a geographically dispersed region, such as Southeast Wisconsin, with several healthcarecommunities (or XDS Affinity Domains). One community provides image sharing services forGreater Milwaukee region and one for Kenosha region.
•

5325
•

In each community, a Health Information Exchange Service Provider (HIE-SP) provides:•

an XDS Infrastructure (an XDS Registry and an XDS Repository) for sharing reports
and image manifests.

•

an Affinity Domain with a common patient identifier and common coded terminology
for managing the sharing of images.

In each community, Diagnostic Imaging Service Providers provide access to locallystored images through transactions defined by the XDS-I.b Integration Profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•
5330

Two communities agree to share patient records for urgent care using transactions
defined in XCA-I.

A patient X, who receives her primary care in Kenosha, frequently travels to the Greater
Milwaukee region for business. While visiting Milwaukee, patient X is admitted to the
Milwaukee University Hospital (MUH) for urgent care. The attending physician places animaging procedure order.
5335

5340

The local PACS, acting as an XDS-I.b Imaging Document Consumer, performs an automatedquery for relevant priors within the Greater Milwaukee region and to the Kenosha region throughan XDS.b Stored Query transaction to the local HIE-SP’s Initiating Gateway.
The Initiating Gateway in Greater Milwaukee queries both the local Document Registry and the
Responding Gateway for Kenosha. Relevant priors are located in Kenosha and in the South
Milwaukee Diagnostic Imaging Center. The South Milwaukee Diagnostic Imaging Center shares
images using XDS-I.b as part of the Greater Milwaukee region.
The MUH PACS, acting as an XDS-I.b Imaging Document Consumer, directly accesses images
from the South Milwaukee Diagnostic Imaging Center via their XDS I.b Imaging Document
Source.

5345

Images from the Kenosha region are retrieved through the Greater Milwaukee HIE-SP’s XCA-I
Initiating Imaging Gateway, retrieving the images from the Kenosha HIE-SP’s XCA-I
Responding Imaging Gateway. The Kenosha HIE-SP XCA-I Responding Imaging Gateway, inturn, retrieves the images from Imaging Document Source imaging repositories in the Kenosha
region.

5350

29.3.2 Detailed Interactions
The following diagram presents a high level view of the interactions between actors when both
initiating and responding communities are XDS-I.b Affinity Domains. Details on eachinteraction follow the diagram.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5355

5360

Figure 29.3.2-1: XCA-I Detailed Interactions

Query across Local Community A and Remote Community: Document Consumer initiatesa Registry Stored Query request by patient id – the Document Consumer initiates the initialtransaction by formatting a Registry Stored Query request by patient identifier. The consumer
uses PDQ, PIX or some other means to identify the Local Affinity Domain patient id, formats
that information plus any other query parameters into a Registry Stored Query request and sends
this request to an Initiating Gateway.
Initiating Gateway processes Registry Stored Query by patient id request – The Initiating
Gateway receives a Registry Stored Query by patient id and must determine

5365a) Which Responding Gateways this request should be sent tob) What patient id to use in the Cross Gateway Queries. Detailed specification of these steps is
not in the intended scope of this profile. Combination of this profile with other existing
profiles (e.g., XCPD, PIX/PDQ), future profiles or configuration mechanisms is possible.
______________________________________________________________________________
255
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5370

Please refer to ITI TF-2x: E.7 XCA and Patient Identification Management for possible useof existing profiles PIX and PDQ.
For each Responding Gateway identified, the Initiating Gateway initiates a Cross Gateway
Query transaction. The Initiating Gateway also initiates a Registry Stored Query to the local
Document Registry.

5375

5380

5385

5390

Responding Gateway processes Cross Gateway Query by patient id – The Responding Gateway
processes the Cross Gateway Query by initiating a Registry Stored Query to the local Document
Registry. The Responding Gateway updates the response from the Document Registry to ensurethat the homeCommunityId is specified on every applicable element. This updated response issent as the response to the Cross Gateway Query.
Initiating Gateway processes Cross Gateway Query by patient id responses – The Initiating
Gateway collects the responses from all Responding Gateways it contacted. For each response it
verifies that the homeCommunityId is present in each appropriate element. Once all responses
are received the Initiating Gateway consolidates all updated response data into one response to
the Document Consumer. The Initiating Gateway returns to the Document Consumer the same
homeCommunityId attribute values that it received from Responding Gateway(s).
Document Consumer receives Registry Stored Query by patient id response – The Document
Consumer receives the results of the query from the Initiating Gateway and must account for two
unique aspects of the response; namely that a) the homeCommunityId attribute will be specified
and b) the Document Consumer may not be able to map the Retrieve Location UID value
directly to a Document Repository located in a remote community. For example, the initiating
and responding community will have common Requested Procedure vocabularies. The Initiating
Gateway will respond to the Document Consumer’s request using the common
coding/vocabulary scheme designated for the initiating community. The Document Consumer
retains the values of the homeCommunityId attribute for future interaction with the Initiating
Gateway.

5395

Retrieve Image Manifest and Reports from local Community A & Remote Community B:

5400

Document Consumer initiates a Retrieve Document Set – If the Document Consumer issued aRegistry Stored Query, the response to the Registry Stored Query by patient id includes a) the
document unique ID b) the Retrieve Location unique ID c) the homeCommunityId attribute. The
Document Consumer shall specify these three parameters in its Retrieve Document Set
transaction to the Initiating Gateway.

5405

Initiating Gateway processes Retrieve Document Set – The Initiating Gateway determines
which Responding Gateway(s) to contact by using the homeCommunityId to obtain the Web
Services endpoint of the Responding Gateway(s). If the homeCommunityId represents the local
community the Initiating Gateway will initiate a Retrieve Document Set to a local Document
Repository. The Retrieve Document Set may contain more than one unique homeCommunityId
so the Initiating Gateway may have to initiate requests to more than one Responding Gateway,
and consolidate the results. The Initiating Gateway specifies the homeCommunityId in the Cross
Gateway Retrieve Imaging Document Set transaction. The homeCommunityId identifies thecommunity associated with the Responding Gateway.
______________________________________________________________________________
256
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
5410

5415

Responding Gateway processes Cross Gateway Retrieve– The Responding Gateway within an
XDS Affinity Domain processes the Cross Gateway Retrieve initiating a Retrieve Document Set
transaction to the Document Repository identified by the repository unique ID within the request.
If the Cross Gateway Retrieve requests multiple documents with different repository unique IDs,
the Responding Gateway will contact multiple Document Repositories and consolidate theresponses.
Retrieve Image Set from Remote Community B

5420

5425

5430

5435

Imaging Document Consumer initiates a Retrieve Imaging Document Set. The response to the
Retrieve Document Set provides the image manifest and includes a) the Retrieve Location UID
identifying the Imaging Document Source, b) the document unique Ids identifying the imaging
documents within the Imaging Document Source c) list of one or more DICOM transfer syntax
UIDs, d) Study Instance UID, e) Series Instance UID f) the homeCommunityId attribute. The
Imaging Document Consumer specifies these parameters in its Retrieve Imaging Document Set
transaction to the Initiating Imaging Gateway.
Initiating Imaging Gateway processes Retrieve Imaging Document Set – The Initiating
Imaging Gateway determines which Responding Imaging Gateways to contact by using thehomeCommunityId to obtain the Web Services endpoint of the Responding Imaging Gateway.
The Retrieve Imaging Document Set may contain more than one unique homeCommunityId so
the Initiating Imaging Gateway may have to initiate requests to more than one Responding
Imaging Gateway, and consolidate the results. The Initiating Imaging Gateway specifies thehomeCommunityId in the Cross Gateway Retrieve Imaging Document Set transaction. The
homeCommunityId identifies the community associated with the Responding Imaging Gateway.
Responding Imaging Gateway processes Cross Gateway Retrieve Imaging Document Set – The
Responding Imaging Gateway within an XDS Affinity Domain processes the Cross Gateway
Retrieve Imaging Document Set initiating a Retrieve Imaging Document Set transaction to the
Imaging Document Source identified by the Retrieve Location UID within the request. If the
Cross Gateway Retrieve Imaging Document Set requests multiple documents with different
Retrieve Location UIDs, the Responding Imaging Gateway will contact multiple Imaging
Document Sources and consolidate the responses.
Retrieve Image Set from Local Community A

5440

5445

Imaging Document Consumer initiates a Retrieve Imaging Document Set – The response to the
Retrieve Document Set provides the image manifest and includes a) the repository unique ID
identifying the Imaging Document Source, b) the document unique Ids identifying the
documents within the Imaging document source c) list of one or more DICOM transfer syntax
UIDs, d) Study Instance UID, e) Series Instance UID f) the homeCommunityId attribute.
Because the homeCommunityId represents the local community, the Imaging Document
Consumer will initiate a Retrieve Imaging Document Set to the local Imaging Document Source.
29.3.3 Actor Grouping Considerations
XCA-I presumes the community uses the XDS-I.b and XDS.b integration profiles for enabling
Imaging Document Set behavior. XCA-I defines no required grouping with any actor. The______________________________________________________________________________
257
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
5450

5455

implementer may consider grouping actors as needed. For example, an Image Document Source
may choose to group with an IRWF Importer for importing images. The XCA-I Profile does not
explicitly group the XCA-I Initiating Imaging Gateway and XCA Initiating Gateway pair and the
XCA-I Responding Imaging Gateway and XCA Responding Gateway pair.
The XCA-I Profile requires that the Initiating and Responding Imaging Gateways that are used inconjunction with the XCA Initiating and Responding Gateways and will be part of XDS
communities that support XDS.b.

29.4 XCA-I Security Considerations
29.4.1 XCA Risk Assessment
5460

The risk analysis for XCA enumerates assets, threats, and mitigations. The complete risk data isstored and maintained in a central location. The complete risk data is stored and available from
IHE 1.
The risks associated with the data content and protocols of RAD-69 and RAD-75 are a subset of
those identified for the transactions in XCA.
29.4.2 Requirements/Recommendations

5465

The following mitigations shall be implemented by all XCA-I actors. These mitigations
moderate all high impact risks.
M1: All actors in XCA-I shall be grouped with an ATNA Secure Node or Secure Application
Actor and a CT Time Client Actor.

5470

5475

5480

M2: An Imaging Document Source shall include a SHA1 hash of the image document content in
the Document metadata of the “RAD-1x” response. The Imaging Document Consumer shallhave the ability to verify the SHA1 hash of the image document with the SHA1 hash in themetadata.
M3: Imaging Document Consumer implementations shall handle overloading through excessive
volume of response data by discontinuing the read on the socket and closing it. The Initiating andResponding Imaging Gateways shall respond to disconnection by discontinuing processing of
responses.
M6: The Responding Imaging Gateway shall return either zero documents with no further
information or XDSUnknownPatientId in response to queries of unknown patient identifiers,
depending on local policy. This applies to patient identifiers that are properly formatted or
improperly formatted. By not using an error code indicating that the identifier is ill formatted,
you are able to reduce the ability of applications to fish for data.

1

The risk analysis data may be found at: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr5-20072008/Technical_Cmte/Profile_Work/XC/XCARiskAnalysis.xls______________________________________________________________________________
258
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
The following mitigations address the risk of a document being maliciously changed. This
mitigation is optional.
5485

M5: Documents may be digitally signed using the DSG Profile
The following mitigations are transferred to the vendors, XDS Affinity Domains, andenterprises.

5490

T1: Backup systems for registry metadata, repository documents, and gateway configuration arerecommended.
T2: All implementations are recommended to ensure that all received data is propagatedappropriately (i.e., without corruption and complete results) or an error is presented.
T3: Network protection services are recommended to be sufficient to guard against denial ofservice attacks on all service interfaces.

5495

T4: A process that reviews audit records and acts on inappropriate actions is recommended.
T5: It is recommended that service interfaces be implemented with a good design to guard
against corruption and denial of service attacks
29.4.3 Policy Choices

5500

Security and privacy policy choices will not be addressed by this profile. Each community may
have different security and privacy policies. The profile has been designed with this fact in mind
and an understanding of enough variety of policies so that any reasonable policy can be
implemented without violating the profile.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5505

Appendix A: Clarification of Accession Number and Requested
Procedure ID
The purpose of this appendix is to clarify the entity relationships in the Model of Real World
adopted by IHE and role of the entity identifiers, such as Accession Number and the Requested
Procedure ID, that are used to maintain data consistency between those entities.

A.1 Structure of an Order for Imaging Service
5510

5515

5520

5525

5530

5535

5540

There are multiple information systems involved in the fulfillment of the request directed to theimaging department, such as a Radiology Information System (RIS) and a Picture Archiving andCommunication System (PACS).
The order for the imaging service is communicated between the Order Placer (such as an Order
Entry system) and the Order Filler (such as an RIS). In the imaging department environment, theOrder Filler also identifies the set of procedures and sub-procedures (procedure steps) that haveto be performed in the process of fulfilling the order. Each procedure step is performed using asingle device (modality, workstation). In the process of scheduling the order fulfillment, theOrder Filler identifies the type of device and either a specific device or group of devices (forexample, by geographic location) one of which is to be used in performing the procedure step.
An Order Filler accepts from an Order Placer a single Order that it equates to a Filler Order(which is concept commonly used in HL7) or Imaging Service Request (Concept commonlyused in DICOM). Correspondingly, it will assign a Filler Order Number associated with theorder. For the same order to be treated as Imaging Service Request, it will also assign a unique
Accession Number. The Accession Number is critical for associating performed procedure steps
to the corresponding scheduled procedure steps: therefore IHE recommends that the Accession
Number rather contains no value than an unreliable value, in order to give a human user theopportunity to timely correct this missing value (see also the Tables in RAD TF-2, Appendix A).
Each Filler Order may contain one or more Requested Procedures. Each Requested Procedure is
identified by a Requested Procedure ID that needs to be unique only within the scope of theFiller Order Number/Accession Number.
A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance ofa Requested Procedure includes all of the items of information that are specified by an instanceof a Procedure Plan that is selected for the Requested Procedure by the imaging service provider.
This Procedure Plan is defined by the imaging service provider on the basis of the Procedure
Plan templates associated with the considered Procedure Type. A single Requested Procedure of
one Procedure Type is the highest hierarchical unit of work level that may give rise to thecreation of a report. Each report is one of the results produced to satisfy the order. For example,
in a case of the order for an X-ray examination of a patient daily at 8 am for the next three days,
each of the daily examinations will require a separate diagnostic report; hence each of them willbe treated as a separate Requested Procedure. In order to support DICOM Query/Retrieve
mechanism and easy collation of all results pertaining to a single procedure Order Filler also
generates the Study Instance UID, a globally unique identifier for each Requested Procedure.
______________________________________________________________________________
260
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
This identifier will be used to identify all generated images and other DICOM objects related tothis Requested Procedure.
5545

5550

5555

Performance of one instance of a Requested Procedure is specified by exactly one Procedure
Plan. Each Requested Procedure may contain one or more Scheduled Procedure Steps that are tobe performed according to the Protocols specified by a Procedure Plan. Type and number of
Scheduled Procedure Steps in a Requested Procedure is based on the timing and equipment
requirements. Each step is identified with the Scheduled Procedure Step ID. A single Procedure
Step may only be performed on a single type and instance of equipment. Thus, while theRequested Procedure may identify multi-modality examination (such as ones common in
Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on asingle modality.
The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled
Procedure Step is depicted in a Figure A.1-1. Names of entities are represented by names inbolded text, and their identifiers are represented by names in square brackets.

Order[Placer Order Number] [Filler Order Number]
Imaging Service Request[Accession Number]
Requested Procedure 1[Requested Procedure ID][Study Instance UID]

Requested Procedure 2[Requested Procedure ID][Study Instance UID]

Scheduled Procedure
Step 1[Scheduled Procedure
Step ID]

Scheduled Procedure
Step 1[Scheduled Procedure
Step ID]

Requested Procedure 3[Requested Procedure ID][Study Instance UID]
Scheduled
Procedure
Step 1[Scheduled
Procedure
Step ID]

Scheduled
Procedure
Step 2[Scheduled
Procedure
Step ID]

A.1-1: Hierarchy of Components of an Order5560______________________________________________________________________________
261
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix B: Topics for Standards Corrections or Supplements
B.1 HL7 Topics
B.1.1 Version 2.5
5565

5570

The IHE Radiology Technical Framework is primarily based on the version 2.3.1 of the HL7
standard (See RAD TF-2: 2.4.4 for discussion of HL7 Versioning). The definitions provided in
the Technical Framework will specify the base version of HL7 used. For example, theAppointment Notification, Transaction RAD-48 uses the SIU^S12 message first defined in HL7
Version 2.4 in order to take advantage of the additional scheduling information not available inprevious versions.

5575

Likewise, IHE has had to provide temporary solutions in custom segments where definitions
have not existed. An example is the definition of Transactions RAD-4 and RAD-13 which
include a ZDS Segment as a temporary solution for handling Study Instance UID. A definition
for the Study Instance UID did not exist until HL7 version 2.5 when definitions were added to
the OMI (Imaging Order) message.
B.1.2 HL7 Conformance5580

HL7 in its version 2.5 defines the concepts of HL7 conformance and HL7 profiles that provide
standardized mechanism for HL7 specifications. IHE intends to document its definitions of HL7based transactions using such mechanism. Note that HL7 conformance profiles are not related to
IHE Integration Profiles and will be used only for purpose of better documentation of IHE
requirements

B.2 DICOM Topics
Implementers are expected to keep up with CP's in DICOM as well as in IHE. DICOM CPs may
be found here: http://www.dclunie.com/dicom-status/status.html
5585______________________________________________________________________________
262
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix C: Overview of the Information Exchange between
Department System Scheduler/Order Filler and Image Manager

5590

Information exchange between the Department System Scheduler/Order Filler and the ImageManager is performed on the intra-departmental level. Each actor manages a distinct domain of
information within a department: patient, order and procedure performance information for the
Department System Scheduler/Order Filler; image acquisition, storage and interpretation for the
Image Manager. Each system, however, requires valid and current information from both
domains.

C.1 Exchange of Patient Information
5595

5600

The Department System Scheduler/Order Filler is a source of patient information for the ImageManager within the context of a department. The Image Manager does not receive information
for a particular patient until the first order for a patient has been submitted to the department andcorresponding procedures have been scheduled. At this point, the Department System
Scheduler/Order Filler will communicate patient information to the Image Manager within
Transaction RAD-4: Procedure Scheduled.

5605

Subsequent updates of patient information are communicated by the Department System
Scheduler/Order Filler to the Image Manager via Transaction RAD-12: Patient Update. Thesechanges will be reflected on the Image Manager and in the images, Grayscale Softcopy
Presentation State and Key Image Note objects retrieved from the Image Archive. The ImageManager shall not initiate patient information changes.

C.2 Exchange of Visit and Order Information

5610

5615

5620

The Department System Scheduler/Order Filler is a source of visit and order information for the
Image Manager. The Image Manager does not receive information for a particular patient’s visit
until the first order for a patient originated within such a visit has been submitted to thedepartment and corresponding procedures have been scheduled. At this point, the Department
System Scheduler/Order Filler will communicate visit and order information to the ImageManager within Transaction RAD-4: Procedure Scheduled.
Subsequent updates of visit information are communicated by the Department System
Scheduler/Order Filler to the Image Manager via Transaction RAD-12: Patient Update. Thesechanges will be reflected on the Image Manager and in the images, Grayscale Softcopy
Presentation State and Key Image Note objects retrieved from the Image Archive. The ImageManager shall not initiate visit information changes.
Because the IHE Technical Framework requires that the order information change will be
performed through cancellation of the order in question and re-order, updates of orderinformation are communicated by the Department System Scheduler/Order Filler to the ImageManager via a sequence of two transactions - Transaction RAD-13: Procedure Update(conveying order cancel) and Transaction RAD-4: Procedure Scheduled (conveying new orderinformation). The Image Manager shall not initiate order information changes.
______________________________________________________________________________
263
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

C.3 Exchange of Procedure Information
5625

The Department System Scheduler/Order Filler is a source of Requested Procedure information
for the Image Manager. The Image Manager does not receive information for a particular
procedure until it has been scheduled. At this point, the Department System Scheduler/Order
Filler will communicate visit and order information to the Image Manager within Transaction
RAD-4: Procedure Scheduled.

5630

Subsequent updates of procedure information (re-scheduling, change of procedure code, etc.) arecommunicated by the DSS/Order Filler to the Image Manager via Transaction RAD-13:
Procedure Update. The Image Manager shall not initiate Requested Procedure information
changes.

5635

5640

In the Scheduled Workflow Group Case (RAD TF-2: 4.6.4.1.2.3.4) and Import Reconciliation
Workflow Scheduled Import (RAD TF-2: Table A.5-1), certain imaging information submitted
to the Image Manager from the Acquisition Modality or the Importer will differ from thatprovided by the Department System Scheduler/Order Filler. This information can include theStudy Instance UID and the Performed Procedure, Performed Procedure Step and Performed
Protocol. For these defined cases this imaging information shall not be subject to change byeither the Department System Scheduler/Order Filler or the Image Manager.
The behavior for handling the case where the imaging information differs because theAcquisition Modality does not conform to Scheduled Workflow is not defined.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix D: IHE Integration Statements
5645

IHE Integration Statements are documents prepared and published by vendors to describe theintended conformance of their products with the IHE Technical Framework. They identify the
specific IHE capabilities a given product is designed to support in terms of the key concepts of
IHE: Actors and Integration Profiles (described in Volume 1, section 2 of the Technical
Framework).

5650

Users familiar with these concepts can use Integration Statements as an aid to determine whatlevel of integration a vendor asserts a product supports with complementary systems and whatclinical and operational benefits such integration might provide. Integration Statements areintended to be used in conjunction with statements of conformance to specific standards (e.g.,
HL7, DICOM, W3C, etc.).

5655

IHE provides a process for vendors to test their implementation of IHE Actors and Integration
Profiles. The IHE testing process, culminating in a multi-party interactive testing event called theConnect-a-thon, provides vendors with valuable feedback and provides a baseline indication of
the conformance of their implementations. The process is not, however, intended toindependently evaluate, or ensure, product compliance. In publishing the results of the Connecta-thon, and facilitating access to vendors’ IHE Integration Statements, IHE and its sponsoringorganizations are in no way attesting to the accuracy or validity of any vendor’s IHE Integration
Statements or any other claims by vendors regarding their products.

5660

5665

5670

IMPORTANT -- PLEASE NOTE: Vendors have sole responsibility for the accuracy andvalidity of their IHE Integration Statements. Vendors’ Integration Statements are made available
through IHE simply for consideration by parties seeking information about the integration
capabilities of particular products. IHE and its sponsoring organizations have not evaluated orapproved any IHE Integration Statement or any related product, and IHE and its sponsoringorganizations shall have no liability or responsibility to any party for any claims or damages,
whether direct, indirect, incidental or consequential, including but not limited to businessinterruption and loss of revenue, arising from any use of, or reliance upon, any IHE Integration
Statement.

D.1 Structure and Content of an IHE Integration Statement
An IHE Integration Statement for a product shall include:
1. The Vendor Name
5675

2. The Product Name (as used in the commercial context) to which the IHE Integration
Statement applies.
3. The Product Version to which the IHE Integration Statement applies.
4. A publication date.
5. The following statement:______________________________________________________________________________
265
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
5680

5685

“This product is intended to implement all transactions required in the IHE Technical
Framework to support the IHE Integration Profiles, Actors and Options listed below:”
6. A list of IHE Integration Profiles supported by the product and, for each Integration
Profile, a list of IHE Actors supported. For each integration profile/actor combination one
or more of the options defined in the IHE Technical Framework may also be stated.
Profiles, Actors and Options shall use the names defined by the IHE Technical
Framework Volume 1.
Note: The vendor may also elect to indicate the version number of the Technical Framework referenced for eachIntegration Profile.

5690

Note that implementation of the integration profile presumes implementation of all required
transactions for an actor; options include optional transactions or optional functions for required
transactions.
The statement shall also include references and/or internet links to the following information:
1. The specific internet address (or universal resource locator [URL]) where the vendor’sIntegration Statements are posted

5695

2. The specific URL where the vendor’s standards conformance statements (e.g., HL7,
DICOM, etc.) relevant to the IHE transactions implemented by the product are posted.
3. The URL of the IHE Initiative’s web page for general information on IHE(www.rsna.org/IHE).

5700

An IHE Integration Statement is not intended to promote or advertise aspects of a product notdirectly related to its implementation of IHE capabilities.

D.2 Format of an IHE Integration Statement
Each Integration Statement shall follow the format shown below. Vendors may add a cover page
and any necessary additional information in accordance with their product documentation
policies.
5705

5710

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________5715
IHE Integration Statement
VendorDate

Product Name

Any Medical Systems Co.

12 Oct 2002

VersionIntegrateRAD

V2.3

This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles,
Actors and Options listed below:

Integration
ProfilesImplemented
Scheduled
Workflow

Simple Image andNumeric Report

Actors Implemented

Options
Implemented

Image Manager/Image Archive

None

Image Display

None

Evidence Creator

Creator Performed
Procedure Step

Order Filler

PPS Exception
Management

Report Creator

None

Internet address for vendor’s IHE information:www.anymedicalsystemsco.com/ihe

Links to Standards Conformance Statements for the Implementation
HL7
DICOM

www.anymedicalsystemsco.com/hl7
www.anymedicalsystemsco.com/dicom/integrateRAD.pdf

Links to general information on IHE
In North America: www.ihe.net

In Europe: www.ihe-europe.org

In Japan: www.jira-net.or.jp/ihe-j______________________________________________________________________________
267
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix E: Nuclear Medicine
5720

Note that the NM Image Profile is undergoing revision, and vendors considering implementation
are advised to include the modifications contained in the trial implementation version “NMImage Profile with Cardiac Option”. For additional information please contact the IHE
Radiology Technical Committee at IHE-Rad-Tech@googlegroups.com.

E.1 Introduction
5725

5730

This Appendix provides a description of relevant aspects of Nuclear Medicine in the context of
the IHE Radiology Technical Framework. This includes descriptions of some typical Nuclear
Medicine workflows and how they can be supported within the framework of the current
Scheduled Workflow and Post-Processing Workflow Integration Profiles. Characteristics oftypical NM Images are presented and examples of typical displays of NM Images are provided.
This Appendix is informative, not normative. The mapping of workflows to the IHE Model, andother details of NM practice are sufficiently complex and/or misunderstood that this Appendix
has been included to clarify such issues and provide examples of some sensible approaches. The
examples and details here are not intended to be exhaustive. The mappings to the workflow
model of IHE shown here are valid but do not represent the only valid mappings.

E.2 NM Workflow Overview
5735

5740

5745

First it should be said that the normal scheduled workflow of:•registering a patient•placing an order•scheduling an acquisition•

retrieving a worklist at the modality•

performing an acquisition•

generating images•

storing images to the archive•

retrieving images for review•

generating a report… is certainly applicable to NM studies.
That being said, it is perhaps most instructive to proceed to describe the ways in which NM
workflow can differ from typical radiology workflow and what assumptions may not be valid or
may require special consideration for NM.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.2.1 Injection Steps
5750

5755

5760

All nuclear medicine studies depend on the injection of radio-pharmaceutical tracers (although agiven series may be imaging a radio-pharmaceutical injected hours or days earlier). Note that
although this document refers to injection of the radio-pharmaceutical, it may also be given
orally or by some other route.
The required dose of radio-pharmaceutical must be ordered from the pharmacy and delivery
arranged to coincide with the scheduled patient procedure. Other aspects include updates forchanged or cancelled orders, tracking the radioactive materials, performing QA and confirming
the count levels of the delivered dose, etc.
The injection procedure step itself is also generally scheduled and it’s execution logged andtracked both because time from injection factors in to most protocols and because the drug
administration should go into the patient record.
As will be discussed in the following section on NM Worklist Guidelines, most of these tasks
would fall in the scope of yet-to-be-developed profiles relating to Pharmacy and Enterprise
Scheduling but the injection step may fall in the scope of Scheduled Workflow.
E.2.2 Time Separated Acquisitions

5765

5770

Standard NM clinical practice includes protocols which require the patient to leave theacquisition equipment between acquisition steps.
Some imaging procedures include multiple acquisition steps separated by some time interval.
This time interval can be anywhere from 1 or 2 hours, up to as much as a few days. This meansthat the patient leaves the imaging system in between parts of the procedure. When the patient
returns, it is possible that the new acquisitions may be done on a different system based on
availability. Therefore, there can be no assumption that the same acquisition system is involved
in all steps of a given procedure.
On the other hand, some protocols may involve several acquisition steps done at-once, back-toback.

5775

E.2.3 Reconstruction as a Separate Operation
NM differs from other modalities in the relationship between acquisition and reconstruction
processes.
In most modalities the raw acquisition data has little clinical use. Reconstruction is generally
performed on the modality and only the reconstructed images are exported from the modality.

5780

5785

For NM studies, the raw projection images are clinically useful images, and are often exported
and viewed using the NM IOD.
When these projection images are tomographic (i.e., Image Type = TOMO or GATED TOMO)
they can also be reconstructed into volume images similar to CT or MR images, i.e., a stack ofslices. Although this reconstruction process can be done on the acquisition system as is done inmost modalities, due to the availability of exported tomographic images, it may also be done on______________________________________________________________________________
269
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
other workstations depending on site preferences for particular vendors reconstruction
algorithms, processing loads, and other workflow issues.
E.2.4 Acquisition Post-Processing
5790

5795

In addition to reconstruction, there are a number of other acquisition related processing steps
performed on the acquired images. This includes:•

Uniformity Correction - to correct for non-uniformities in the detector hardware•

Decay Correction - to correct for radioactive decay of the injected tracer over time•

Scatter Correction - to remove photons scattered by tissue rather than emitted by thetracer•Attenuation Correction - to compensate for photons absorbed within the body•Patient Motion Correction - to compensate for patient motion during the scan•Center of Rotation Correction - to compensate for offsets in the axis of rotation

Other possible corrections include deadtime, energy and linearity.
5800

5805

Some of these corrections, especially those that are hardware dependent or are specific to an
acquisition system, must be performed on the acquisition modality if they are performed at all.
To avoid encouraging potentially incomplete attempts to carry out these corrections away fromthe modality, the NM IOD intentionally leaves out attributes for attempting to convey all the
relevant information.
Other steps, although generally performed on the acquisition modality, may, like reconstruction,
be performed on a separate workstation depending on system capabilities and site preferences.
E.2.5 Clinical Post Processing
Finally, due to the metabolic/qualitative nature of NM imaging, it is very common to perform
clinical processing on the images to extract quantitative details prior to final review.

5810

5815

These clinical processing packages too are sometimes available on the acquisition modality but
may also be on a separate workstation. This processing includes things like:•

Re-orientation of volumes•

2D and/or 3D segmentation (automatic and/or manual)•Calculation of region characteristics•

Generation of time-plots•

Computation of functional images•

Generation of Result Screens

These activities are sometimes performed immediately following acquisition or may be left for
batch processing at a later time.
______________________________________________________________________________
270
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.2.6 Display and Reviewing
5820

Unlike other modalities where the raw acquisition data has little clinical use, for NM images, theraw projection images are clinically useful images, and are often reviewed by the reading
radiologist together with processed results.
Also, the color presentation of the images is common in Nuclear Medicine and is a clinicalnecessity for the interpretation of certain images.

5825

E.2.7 Workflow Chaining
Due to the common use of processing workstations and clinical processing before reporting, thework on chained workflows being discussed in the IHE Technical Committee whitepaper on
Departmental Workflow will be of particular interest and relevance to Nuclear Medicine.

E.3 NM Worklists
5830

5835

The following informative text provides guidance on how NM activities would most logically bemapped to IHE Worklists and the concepts of Scheduled and Performed Procedure Steps.
The Scheduled Workflow Profile and Post-Processing Profile are very flexible in allowing
complex procedures to be scheduled as a single procedure step (potentially with multiple
procedure codes) or as multiple procedure steps. There are some situations which can work
equally well with either approach, and ultimately sites will need to have some flexibility in how
the work is scheduled in order to fit their work patterns.
That being said, the following are some basic guidelines which represent a sensible approach thatshould be considered. After the guidelines are a number of examples of how the guidelines
would be applied to cases taken from typical clinical practice.

5840

E.3.1 NM Worklist Guidelines
E.3.1.1 Injections

5845

Scheduling, preparing, tracking and delivering the required dose of radio-pharmaceutical tracer
is the job of the pharmacy and it does not make particular sense to include it in the worklists
currently managed by the Radiology Profiles. It would make sense to address this in future
Pharmacy and Enterprise Scheduling Profiles which would also handle related issues, such aschanging or canceling the order, managing drug interactions, QA and tracking of radioactive
materials, etc.
The injection procedure step itself may also be scheduled and is frequently performed in
proximity to the imaging equipment and in the presence of, or by, the modality operator.

5850

As a practical matter, pending development of the above mentioned profiles, it would be usefuland not unreasonable for the DSS/Order Filler and the Acquisition Modality to allow injection
steps to be placed on the Modality Worklist, either as procedure codes in an acquisition
procedure step or as an independent procedure step.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

5855

5860

Further, the modality could allow the operator to indicate that the injection has been completed
and generate corresponding MPPS details. Supporting codes for injections is not a requirement,
but would be a useful feature. Note that the NM Image IOD already has attributes in the NM
Isotope Module for modality systems that track injection details.
If the injection step is to be performed at the time of an acquisition, then it would be appropriate
for the injection to be included as one Item in the Protocol Code Sequence within the Scheduled
Procedure Step for the acquisition.
Injections that are performed outside of the acquisition room, some time prior to the dataacquisition, are not particularly appropriate for inclusion in a modality worklist and are out of
scope of this discussion.

5865

While charges for radio-pharmaceuticals are generally built into the technical procedure fee, itwould be appropriate and sometimes useful to include details about the radio-pharmaceuticaldose in the Billing and Material Management Option described in RAD TF-2: 4.7. In cases
where the MPPS indicates the procedure was cancelled, if an injection was still performed, itwould be appropriate to include that information in the MPPS.
E.3.1.2 Acquisitions

5870

5875

5880

5885

5890

It is suggested that, in general, each acquisition of image data be scheduled as a separate
procedure step.
Clinical protocols that include having the patient leave the acquisition system between
acquisition steps, must schedule them as separate Scheduled Procedure Steps. However, whenseveral acquisition steps are done at-once, back-to-back, they can either be scheduled as multiple
Scheduled Procedure Steps, or as a single Scheduled Procedure Step with multiple protocol
codes. Scheduling using multiple Scheduled Procedure Steps allows the greatest flexibility in useof available equipment and the greatest detail in status reporting. Of course the acquisitions will
still likely be part of the same Study with the same Study UID.
Note that support of multiple Scheduled Procedure Steps resulting from a single Requested
Procedure is already required in the Scheduled Workflow Profile, but support of multiple
protocol codes is optional. Support for multiple performed protocol codes in the Performed
Procedure Step is recommended.
An issue worth mentioning is that due to studies involving multiple acquisitions, several
acquisition modality systems may participate in the same study. While the Study Instance UID is
obtained from the Worklist by both modalities and will be correctly included, the rest of theStudy level information, such as study date/time, study description, etc., is generally notprovided in the Worklist. This means that each modality will generate their own values andinclude them in the generated images, resulting in Series instances in the same Study which havedifferent Study level information (except the UID). It is assumed that the ImageManager/Archive will manage any issues related to this.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.3.1.3 Reconstruction
It is recommended that the reconstruction of acquired (tomographic) image data be treated as aseparate Performed Procedure Step. That is, the acquisition system should issue a Performed
Procedure Step Complete message when the tomographic acquisition is complete.
5895

Then, whatever system performs the reconstruction of this data, whether it is the originalacquisition system, or some other system, should issue a new Performed Procedure Step for thereconstruction process, related to the same Scheduled Procedure Step. In this way, scheduling of
tomographic acquisitions is consistent with other modalities like CT, but allows thereconstruction to be performed flexibly by any system.

5900

These Reconstruction steps, and other post-processing, may carried out as explicit workflow byplacing them on worklists as outlined in the Post-Processing Workflow Profile, or may be carriedout as implicit workflow by the operator knowing these steps should follow acquisition as
outlined in the Scheduled Workflow Profile.
E.3.1.4 Acquisition Post-Processing

5905

5910

Due to the nature of Acquisition Post-Processing, as described in Section E.2.4, it will almost
always be performed on the acquisition system or on a workstation bundled with the acquisition
system. While it is conceivable that some batch oriented site workflows could benefit from doingthese steps with an explicit worklist, the vast majority of sites will do these steps as implicit
workflow. Further, the acquisition post-processing steps are seldom billable and there is little
need for detailed tracking of these steps.
If the processing is performed on a separate workstation the steps should be considered as
separate procedure steps but there is likely only a need to create Performed Procedure Step
messages when the step creates new images which will be sent to the Image Manager/Archive.

5915

If the processing is performed on the acquisition modality system, which is the most likely, it isacceptable to include the steps as additional protocol codes.
E.3.1.5 Clinical Post-Processing
Clinical Post-Processing, as described in Section E.2.5, may be done at some sites using explicit
workflow, although many sites will handle it with implicit workflow.

5920

5925

If the processing is performed on a separate workstation the steps should be handled as separate
procedure steps, either scheduled as explicit workflow as described in the Post-Processing
Workflow Profile or unscheduled as implicit workflow as described in the Scheduled Workflow
Profile.
If the processing is performed on the acquisition modality system it is acceptable to include thesteps as additional protocol codes, however it is recommended to handle them as separate
procedures steps.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.3.2 NM Worklist Examples
The following are some examples of clinical situations and an example of an appropriate way tohandle them based on the above guidelines.
E.3.2.1 Injection and immediate imaging
5930

Example: Renal scan (Dynamic)
The patient is injected under the camera, and imaging is started immediately.
Use a single SPS which includes protocol codes for the injection and for a single acquisition.
E.3.2.2 Injection and delayed imaging
Example: Bone scan to assess for malignancy (Static or Whole body)5935

The patient is injected somewhere (could be in the imaging department or at the patient bedside),and images are obtained several hours later.
Use a single SPS which includes a single acquisition. The injection details are handled out of
scope.
E.3.2.3 Injection with both immediate and delayed imaging

5940

Example: 3-phase bone scan for infection (Dynamic and Static)
The patient is injected under the camera, and imaging is started immediately. More images are
obtained several hours later, on the same or a different gamma camera.

5945

Use two SPS. The first SPS includes protocol codes for both the injection and the initial dynamic
and static acquisitions. The second SPS is for the second static acquisition. Images acquired fromthe second SPS must be in a different Series from those from the first SPS.
E.3.2.4 Injection and immediate imaging, with possible further imaging
Example: Renal scan to evaluate for obstruction, with possible second diuretic acquisition(Dynamic)

5950

The patient is injected under the camera, and imaging is started immediately. The results will
determine whether more imaging is needed.
Schedule two SPS as in X.3.2.3. The images from the first SPS can be read, and then adetermination can be made as to whether or not the second acquisition is required. If it is notneeded, then the second SPS can be cancelled at the modality by issuing an MPPS aborted
message.

5955

E.3.2.5 Injection and very delayed imaging
Example: I-131 whole body imaging (Whole body)
The patient dose is given, and images obtained days later.
______________________________________________________________________________
274
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Optionally schedule one SPS for the injection if it is performed in the imaging suite. An SPS
would be scheduled for the acquisition.
5960

E.3.2.6 Imaging and no injection
Example: Add-on imaging after therapeutic administration by radiation oncology (Static or
Whole body)
The patient dose is given by someone else in the radiation oncology department for the purposeof therapy. Several days later, imaging is performed for evaluation purposes.

5965

A single SPS is used for the image acquisition.
E.3.2.7 Two isotope examination, with two imaging times
Example: Dual isotope [Thallium-201 “rest” images & Tc-99m Sestamibi “stress” images]
myocardial perfusion study (Gated Tomo)

5970

The first isotope is injected followed by image acquisition. A second isotope (possibly under
different patient conditions) is subsequently injected followed by a second image acquisition(possibly on a different camera).
This protocol uses two SPS. The first contains protocol codes for the first injection and the firstacquisition. The second SPS contains protocol codes for the second injection and acquisition.
Each of these two acquisitions constitutes a separate Series.

5975

It should be noted that these are simply suggestions of one approach that makes sense. Sites willof course be interested in scheduling in ways that make sense to them. It is conceivable that an
ECG or Treadmill might implement Modality Worklist, allowing their activities to be scheduled
and monitored steps, however such actors do not currently exist in the framework and such
implementations are currently unlikely.

5980

E.3.2.8 Two isotope examination, with single imaging time
Example: Dual isotope [In-111 labeled White blood cell “infection” images & Tc-99 sulfur
colloid “bone marrow” images] infection study (Dual Energy Static or Whole body)In this example the first isotope is injected on day one. Then the following day the second
isotope is injected 30 minutes before the acquisition step which images both isotopes.

5985

5990

Consider three SPS. The first SPS (optional) for the first injection, the second SPS for the second
injection, and the third SPS for the actual acquisition.
Note that this case might result in billing for two exams (White Blood Cell study and Bone
Marrow imaging), but most centers would actually only issue a single report, since there wasonly one imaging step. This is sort of like the case where an abdomen and pelvis CT was done asa single acquisition, and then read by the same person, but billed as two "studies" (i.e., the PGP
Profile).
E.3.2.9 Acquisition and Reconstruction on the Acquisition Modality______________________________________________________________________________
275
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Example: Cardiac Tomographic acquisition followed by basic corrections, reconstruction and reorientation to align the volume with the cardiac Short Axis.
5995

A single SPS is created which calls for one cardiac tomographic acquisition. The modality
performs the acquisition and sends an MPPS Complete message, referencing the createdtomographic images.
The modality then does corrections and reconstruction of the tomographic data, appends a new
MPPS and reports it complete, without referencing the intermediate image data.

6000

Finally, the reconstructed data is re-oriented into cardiac Short Axis images and the modality
appends a third MPPS to report the reformatting processing, and referencing the re-oriented
slices.
The initial tomographic images and the final re-oriented slices are stored to the ImageManager/Archive.

6005

6010

This example raises a sometimes overlooked point. MPPS transactions should only include
references to series/images which will be (or have been) sent to the Image Manager/Archive. The
implication of including the references is that they will be sent to the Image Manager/Archive.
Correspondingly, the Image Manager/Archive will be waiting for all referenced images and may
continue to consider the study incomplete until they arrive. Thus, referencing images which will
not be sent can have the effect of derailing the workflow.
E.3.2.10

Re-orientation on an Evidence Creator with Implicit Workflow

Example: Same as the previous case, but all of the processing takes place on a separate Evidence
Creator based on implicit workflow as described in Scheduled Workflow.
6015

A single SPS is created which calls for one cardiac tomographic acquisition. The modality
performs the acquisition and sends an MPPS Complete message.
The modality then does corrections and reconstruction of the tomographic data, appends a new
MPPS and reports it complete.
The initial tomographic images are stored to the Image Manager/Archive and the reconstructedslices are stored to the Evidence Creator workstation.

6020

The workstation re-orients the reconstructed data into cardiac Short Axis images and sends a new
MPPS to the PPS Manager. The SPS and patient references in the created images and MPPS arecopied from the information in the received slice images.
The Evidence Creator stores the final re-oriented slices to the Image Manager/Archive.

6025

E.3.2.11
Re-orientation and Post-Processing on an Evidence Creator with
Explicit Workflow
Example: Same as the previous case, but the work is placed on a Post-Processing Worklist andthe Evidence Creator also performs post-processing that produces some Result Screens.
A single SPS is created on the Post-Processing Worklist with codes for Re-orientation andClinical Result Processing.
______________________________________________________________________________
276
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6030

When the task is selected and the inputs are available on the Evidence Creator, the re-orientationis performed followed by Clinical Result Processing. The Evidence Creator sends an MPPS
Complete for the two codes.
The re-oriented slice images and result screens are stored to the Image Manager/Archive.

6035

6040

6045

The timing of placing the SPS on the Post-Processing Worklist is not discussed here as that is the
topic of an IHE Technical Committee whitepaper on Departmental Workflow and is still underdiscussion.
In the above two cases, data was considered to be pushed from the Acquisition Modality to the
Evidence Creator. This is a typical practice, but it should be noted that the mechanism for this is
not specified by IHE. The processing system may retrieve the images from the acquisition
modality, the acquisition modality may push them to the processing system, or the ImageManager/Archive could be used as a common storage and retrieval point.
Also, applications that perform clinical post-processing often need to identify specific relatedseries to use as inputs for processing (for example the corresponding stress and rest series for a
cardiac study). The software should look to the DICOM fields to determine the patient state andtype of Image. The information in the fields may be utilized automatically by the software or
may be presented to the user for manual selection.

E.4 NM Data
The NM Image IOD (refer to DICOM 2011 PS 3.3 C.8.4) supports several NM Image Types as
indicated by the code contained in Value 3 of the Image Type (0008,0008) attribute.
6050

The currently allowed Image Types are:
STATIC - Simple projection image containing one or more frames (e.g., individual views of thelungs).
WHOLE BODY - Projection image where each frame spans the length of the body (e.g., ananterior and/or posterior view of the body).

6055

DYNAMIC - Projection image containing a series of frames typically showing the sameanatomy over time (e.g., a view of renal isotope uptake and washout).
GATED - Similar to DYNAMIC, except the frames are composed to span phases of a gatedinterval (e.g., a beating view of the heart).

6060

TOMO - Projection image with frames take from various angles as the detector rotates about thepatient. Generally used to reconstruct volume slices.
RECON TOMO - Reconstructed image with frames corresponding to cross-sectional slices
covering a volume. Created by reconstructing TOMO image frames.
GATED TOMO - Similar to TOMO, except each angle has multiple frames representing thephases over a gated interval. Generally used to reconstruct gated volume slices.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6065

6070

6075

RECON GATED TOMO - Reconstructed image with frames corresponding to cross-sectionalslices covering a volume at each phase of a gated interval (e.g., a beating heart volume, createdby reconstructing GATED TOMO image frames).
In the NM IOD the information about the orientation and position of the acquired image (frame)is placed in the description of the acquiring detector. So if the same physical detector acquires
data at several locations, there will be separate detector description for each position. Because ofthis, the detector description in the NM IOD is that of a logical detector. Most NM acquisition
modalities have 1, 2, or maybe 3 physical detectors. But an NM object created by thesemodalities may contain considerably more logical detectors in cases where the acquisition
system is moved or rotated about the patient.
E.4.1 Study UIDs and Series UIDs
The basic guidelines for creating Study, Series and SOP UIDs are provided in RAD TF-2:
4.8.4.1.1.1.

6080

While the decision as to what constitutes a new Series is traditionally left to the modality, it canbe said that a series contains images that represent the output of a single procedure step on asingle piece of equipment with a single patient positioning. In practice, the series has frequently
been used to collect a group of single-frame IODs such as the CT slices making up a volume.
In multi-frame IODs such as NM, this is not necessary, as related frames are generally alreadygrouped together in the multi-frame IOD. Therefore, it is strongly recommended that eachseparate acquisition should become a new Series.

6085

6090

Stress and rest cardiac exams separated by a time delay, potentially of hours, should be separate
Series since they may be scheduled separately, could be performed on different acquisition
systems, and may not be able to position the patient identically.
Similarly, reconstruction or post-processing steps must be different Series if they are done ondifferent workstations. For consistency, it is required here that they always be placed in different
Series.
It is also recommended that when new results are produced by doing the same processing on thesame data (for example, to reprocess with slightly different parameters), then each repetition of
the processing step should result in images that are part of a new Series.

6095

6100

Processing functions that produce multiple Images from a single processing step (for example,
several static SC Images, multiple reconstructed views, etc.) should use the same Series for all of
the Images.
It is recommended that object creators fill the Series Description attribute with a value thatwould indicate to users the nature of the contents of the object. In particular the value should
help in differentiating Series in the same Study. The Series Description is reasonably well
supported by PACS systems, while image level fields are less widely supported.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.4.2 NM Image IOD: Multi-Frames and Vectors

6105

It is important to understand that although single-frame DICOM images are most common incurrent use in other modalities, the DICOM Nuclear Medicine Image IOD is a multi-frame
image. This means typically an Image will contain multiple 2-D pixel arrays called Frames.
Refer to DICOM 2011 PS 3.3 C.8.4.8 for details.
The object becomes more complex due to the fact that each frame is indexed according to anumber of acquisition “dimensions” such as Energy Window, Detector, Angle and Phase. Eachframe is indexed in each dimension by a “Frame Pointer” vector.

6110

An example of the Frame Increment Pointer vectors for a Dynamic Image is shown here (takenfrom DICOM 2011 PS 3.3 C.8.4.8.1):
The Pixel Data (7FE0,0010) would contain the frames in the following order:
Frame

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Energy Window #

1

1

1

1

1

1

1

1

1

1

1

1

1

1

Detector #

1

1

1

1

1

1

1

2

2

2

2

2

2

2

Phase #

1

1

1

1

1

2

2

1

1

1

1

1

2

2

Time Slice #

1

2

3

4

5

1

2

1

2

3

4

5

1

2

and the four vectors would be defined as:
Energy Window Vector = 1,1,1,1,1,1,1,1,1,1,1,1,1,1
Detector Vector = 1,1,1,1,1,1,1,2,2,2,2,2,2,26115

Phase Vector = 1,1,1,1,1,2,2,1,1,1,1,1,2,2
Time Slice Vector = 1,2,3,4,5,1,2,1,2,3,4,5,1,2

6120

Each vector attribute has a matching “Number Of” attribute indicating how many values are
enumerated in the corresponding vector. In the above example the Number of Energy Windows= 1 indicating that only one energy window was used so all the entries in the Energy Window
Vector will contain the same value.
For each NM Image Type, the DICOM standard specifies the frame increment pointers whichmust be present and the order in which the pointer vectors are stored. Typically the last vector
will vary most rapidly, although exceptions exist. The NM Image Type is stored in Value 3 ofthe Image Type attribute (0008,0008).

6125

E.4.3 Typical NM Data Dimensions
Typical sizes of NM Image frames and NM Image vectors are provided in the following table.
Table E.4-1: NM Image Characteristics
Image Type

TypicalMatrixSize

Frame
Increment Pointer[i.e., vectors]

Typical#STATIC

128 x 128

Energy Window (0054,0010)

1-2______________________________________________________________________________
279
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Image Type

TypicalMatrix
Size
256 x 256

WHOLE BODYDYNAMIC

GATED

TOMO

1024 x2561024 x
512
64 x 64
128 x 128

64 x 64
128 x 128

64 x 64
128 x 128

Frame
Increment Pointer[i.e., vectors]
Detector (0054,0020)

1 - 2*[Total Frames]

1 - 12*

Energy Window (0054,0010)

1-2

Detector (0054,0020)

1-2[Total Frames]

1-4

Energy Window (0054,0010)

1-2

Detector (0054,0020)

1-2

Phase (0054,0100)

1-3Time Slice (0054,0030)

1 - 120[Total Frames]

1 - 1440

Energy Window (0054,0010)

1

Detector (0054,0020)

1

R-R Interval (0054,0060)

1

Time Slot (0054,0070)

8 - 32[Total Frames]

8 - 32

Energy Window (0054,0010)

1

Detector (0054,0020)

1

Rotation (0054,0050)

GATED TOMO

64 x 64
128 x 1281

Angular View (0054,0090)

30 - 128[Total Frames]

30 - 128

Energy Window (0054,0010)

1

Detector (0054,0020)

1

Rotation (0054,0050)

1

R-R Interval (0054,0060)

1

Time Slot (0054,0070)

8 - 16

Angular View (0054,0090)

30 - 128[Total Frames]

240 - 2048

RECON TOMO

64 x 64
128 x 128

Slice(0054,0080)

12 - 128GATED RECON
TOMO

64 x 64
128 x 128

R-R Interval (0054,0060)

1

Time Slot (0054,0070)

8 - 16

Slice (0054,0080)

12 - 24[Total Frames]

6130

Typical#96 - 384* Note that although the number of physical detectors is generally 1 or 2, the object may potentially contain a separate
logical detector for each frame in the image as described in the last paragraph of section E.4 above.

E.5 NM Display______________________________________________________________________________
280
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
E.5.1 NM Intensity and Color Mapping

6135

The control of display intensities in Nuclear Medicine is different than that used for CT or MR
images due to inherent differences in the modality imaging process and the resulting image
characteristics.
In CT images are characterized by the fact that the pixel values represent Hounsfield units. Boneis represented by a well-known value plus or minus a typical range. Soft tissues are represented
by another well-known value plus or minus a range. In this space it makes sense to provide
controls for selecting a Window Center and a Window Width.

6140

6145

6150

In NM images, the pixel values typically represent radioactivity “counts”. Due to differences inradiopharmaceutical type, dose, time between injection and imaging, length of scan, overlying
tissue density, metabolic processes and many other things, the pixel values cannot be considered
strictly quantitative. Further, the image is often characterized by very high intensity “hot spots”
where a very high concentration of tracer may have accumulated; and by a low level ofbackground activity (“noise”) from non-specific uptake and scatter. For such images, it isappropriate to provide a control that would allow setting a threshold level to cut out the low levelbackground, and another threshold to cut off the high level hot spots which might otherwise
obscure mid-range intensities.
Control of NM display intensities is therefore based on Upper and Lower Window Levels. These
are different than Window Width and Center but the two are readily interchangeable by a simple
linear mathematical transform.
Window Upper = Window Center + ½ Window Width
Window Lower = Window Center - ½ Window Width
Or conversely,

6155

Window Width = Window Upper - Window Lower
Window Center = (Window Upper + Window Lower) / 2
NM pixel values can generally be represented in 16 bits of data. The Window Upper and Lower
Levels indicate the current range of pixel values of interest. It is recommended that the upper andlower window values be displayed in the interface.

6160

6165

Some NM datasets may contain very high pixel values. To display the images, it is generally
necessary to map the NM Image pixel values into the range of grey levels which can bedisplayed by the hardware (most displays have much fewer discernible grey levels than there are
pixel values in the dataset).
Generally the display should be able to map pixel values to at least 128 display intensity levels.
If the display supports more display intensity levels, the ability to map to more levels ispreferred, if the display is only capable of fewer display intensity levels, it is acceptable to map
to fewer levels. Mapping to 64 display intensity levels is also acceptable if it is necessary todisplay multiple color scales (see below) at the same time.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6170

6175

If the mapping is done only once when the image is first loaded then the presence of a small
number of very high pixel values will result in most of the available display levels being“wasted” on a small number of pixels, leaving very little contrast in the rest of the image.
To make effective use of the available display intensity contrast, it is useful to do rescaling after
each Window Level adjustment, or to provide a way to control the maximum pixel value used
for mapping. A similar problem (and solution) occurs when switching between examining boneand soft tissue windows in a CT image.
If presentation state information is available with the images, it is generally preferred to use it for
the initial display. Note that the Window Center and Window Width attributes in the presentation
state object will also map to Upper and Lower Window values as described above.

6180

6185

In the absence of presentation state information, it would make sense to display the framesets
initially with the Upper and Lower Window Levels set based on the algorithm above and thevalues stored in the Window Center (0028,1050) and Window Width (0028,1051) attributes of
the image data.
In the absence of Window Center and Width values, a possibly viable setting may be the Lower
Window level set to zero and the Upper Window Level set to the maximum pixel value of theframeset.
Typical Nuclear Medicine clinical practice also differs from CT and MR in the prevalence ofapplying pseudo-color lookup tables or “color-scales” to the grayscale data during review. Thisis done to enhance particular features of the data in certain ways.

6190

Different sites, and sometimes different radiologists within each site, will generally have strong
preferences about which color-scales they use for various pathologies in various types of NM
studies. It is not unusual for NM review stations to have dozens of color-scales available.

6195

The ability for users to edit and/or create new pseudo-color lookup tables on the Image Display
is occasionally useful but not required. Far more useful is the ability to install a preferredcollection of color-scales on the system. The Society of Nuclear Medicine (SNM) has plans to
act as a repository for a collection of common and popular color-scales.

6200

Since exported Result Screens in NM almost always contain image data, many users will want tobe able to able to apply a pseudo-color lookup table and the ability to adjust Upper and Lower
Window Levels of monochrome Secondary Capture and Multi-Frame Secondary Capture Images
which have a modality type of NM. It may be unavoidable and would generally be acceptablethat this could change the display values for any included graphics and annotations.
E.5.2 NM Image Resizing

6205

NM Images typically range in size from 64x64 to 512x1024 with the majority of the frames atthe smaller end of the spectrum. Such small images must be enlarged on the display to beclinically useful, adding unnecessary steps to the reading radiologists’ workflow. A common
mistake of general purpose display systems is to initially display these 64x64 frames at “fullresolution” which results in a screen of “postage stamps”.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Correspondingly, Whole body Image frames should generally not be scaled down for initialdisplay, unless such scaling is needed to fit the whole body frame onto the screen.
6210

The following table provides some guidelines on appropriate default zoom factors for various
frame sizes. These are intended to simply provide a starting point for systems withoutsophisticated layout algorithms.
Table E.5-1: Frame Zoom Guidelines
Actual Frame Size

Default Display Size

Default Cine Size

32x32 to 63x63

Display at 4x

Cine at 4x64x64 to 100x100

Display at 3x if 12 or fewer frames
Display at 2x if greater than 12 frames

Cine at 4x

101x101 to 200x200

Display at 2x if 12 or fewer frames
Display at 1x if greater than 12 frames

Cine at 3x

201x201 to size of display area

Display at 1x

Cine at 2x (if display area permits)
Cine at 1x otherwise

Greater than display area

Shrink to fit in display area

Shrink to fit in display area

6215

Note that while NM images are generally square, they are not required to be so, and it would beappropriate to use just the larger of the x and y dimensions when deciding the zoom factor.

6220

Obviously there is interplay between the number of frames to display, frame size, zoom factor,
and display layout. For example, increasing the zoom from 2X to 3X will result in fewer rows
and columns of frames available for display at a given time. Image Displays are encouraged tomake intelligent use of display space. Note that horizontal scrolling is preferable to scrollingboth vertically and horizontally.

6225

6230

With the above table as a starting point, most users will want to have a way of selecting thedisplay size for the frames. A simple selection of 2X, 3X or 4X zoom may be sufficient.
Alternatively, selecting a display format (such as 2x2, 8x8, 4x1, etc.) is also acceptable, though amuch wider range of such formats may be needed for NM images than for other modalities,
given the small NM image size. Some systems have an option for image magnification, where
the size of the displayed area on the screen remains unchanged, but as magnification is increased,
less and less of the image is shown, but the portion that is shown is displayed in greater detail.
For example, on a femur bone x-ray, one might magnify a portion of the screen to just see the hip
portion of the femoral bone, in order to see it at greater resolution. Such magnification is rarely
used in nuclear medicine, with the possible exception of the Whole Body images. Such Whole
Body images are typically 1024 pixels in height, and may not fit on the screen if a larger zoom is
employed. In such cases, it may be necessary to magnify the contents of the frame instead, andallow the user to designate in some manner the portion of the frame he wants to center on as themagnification is increased.
______________________________________________________________________________
283
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6235

E.5.3 NM Display Examples
E.5.3.1 Example Layouts
The following are example layouts illustrating the different Display Formats identified in RAD
TF-2: 4.16.4.2.2.3.2. These are only intended as illustrative examples.
Grid Display

6240
A1

A2

A3

A4

A5

A6

A7

A8

A9

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

A32
…

Comparison Display (2 Framesets)

6245

A1

A2

A3

A4

A5

A6

A7

A8

B1

B2

B3

B4

B5

B6

B7

B8

or alternatively,
A1

A2

A3

A4

A5

A6

A7

A8

A9

…

…

…

…

…

…

A16

B1

B2

B3

B4

B5

B6

B7

B8

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

B9

…

…

…

…

…

…

B16

Whole body Display (2 Framesets, 2 Frames each)

A1

6250

A2

B1

B2

Fit Display (3 images, from 3 series with two frames each)

A1

A2

C1

C1

B1

B2

MPR Display (one transaxial volume, with a supplied or generated MIP cine display)

Transaxial

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

CoronalMIP(cine)

6255

Note that the MIP is not strictly part of the MPR display, but since it is frequently useful, some
vendors provide it.
or alternatively,
CoronalCoronalCoronal

y-1

y

y+1

Axial

Axial

Axial

z-1

z

z+1

Sagittal

Sagittal

Sagittal

n-1

n

n+1

Cine Display (three images from 3 series, each cycling synchronously)
6260
A1-32

B1-32

C1-32

E.5.3.2 Clinical Examples
This section provides examples and clarifications on typical patterns of display for NM Images.
6265This section should not be considered as an attempt to address hanging protocols. This is acomplex topic which DICOM is working on. Once that work is complete, NM and Radiology in______________________________________________________________________________
286
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
general would benefit from that work being included in the IHE Framework. This section is notintended to supplant that.
See RAD TF-2: 4.16.4.2.2.3 for a description of some of the display related capabilities referred
to in these examples.
6270

Example 1: Cardiac Study
The user selects a Tomo stress series, several static result screens (secondary captures), anotherTomo rest series, and a dynamic result screen (multi-frame secondary capture).
The user would like to see both Tomo images together in a Row Display and be able to view
them synchronously in Cine display, preferably with a method for adjusting the cine speed.

6275

6280

Next the user would like to step forward and backward through each of the secondary capture
result screens (which may be stored in a set of Secondary Capture images or in a single MultiFrame Secondary Capture image without a cine module).
The user would also like to review the dynamic result screen in cine mode. It is useful to be able
to adjust the cine speed. Systems unable to cine the result screen at 8 frames/sec or faster would
have limited clinical usefulness.
Example 2: Lung Perfusion Study
The user selects 4 Static series containing a total of 8 frames. The user would like to see all 8
frames in a Fit Display (preferably with the frames resized to 256x256)
Example 3: Ventilation-Perfusion Study

6285

The user selects the (several) series corresponding to lung perfusion imaging, and the (several)
series corresponding to a lung ventilation imaging. The user expects to be able to review theventilation and perfusion frames together in a Fit Display. The user may wish to adjust eachseries’ intensities and the zoom factor.
It may be useful to select several series and adjust the intensities together.

6290

Example 4: Gastro-intestinal Bleed Study
The user selects 2 dynamic images containing anterior and posterior frames from a two-phase 90
minute gastro-intestinal bleeding exam, with a grand total of 300 frames. The user expects to beable to page through the frames (showing them all at once would make the frames too small) in a
Grid Display.

6295

The user would also expect to select one or other view, or one of the phases and view theframeset in a Grid Display.
Finally the user would view a cine (perhaps two cines, one anterior frameset and one posterior
frameset, or a single cine that allows the user to cine one view or the other independently).
Example 5: Renal Study

6300

The user selects a dynamic study. The user expects to see a Grid Display to page through theframes and to be able to cine the time vector.
______________________________________________________________________________
287
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6305

When more than one phase is present, it is useful to be able to control the upper and lower levelsof the phases separately. A user may wish to select a frame set corresponding to the first phase ofa Dynamic Image, which represents the flow portion of the exam, and lower the Upper Window
Level to increase the visibility of these “low-count” frames. The second phase frame set, whichcontains images which are inherently much brighter, should be left unadjusted.
In general, typical display formats for each of the NM Image Types would be as follows:

6310

STATIC: Simple display. Typically several images displayed at once (for example in a Fit
display). While the default order of frames in the object is sorted by Energy Window thenDetector, it is generally more useful to present them in Detector/Energy Window order or sorted
by acquisition time. Example: 12 view static
WHOLE BODY: Side by side display of two rectangular images (i.e., the Whole body display).

6315

DYNAMIC: Cine through all frames of all phases from one detector and one energy window, inorder. It is also useful to display in a Grid or Row display. Generally a different window levelapplies to each phase. Processing (not required by the NM Profile) includes plotting time activity
through user selected areas of the image.
GATED: Cine through the frames from one detector/energy window, in time order. Processing(not required by the NM Profile) can include time activity curves, heart wall edge detection andmotion tracking, etc. Typically several images displayed at once.

6320

6325

6330

TOMO: Cine all frames from one (logical) detector in rotational angle order. Recommend ability
to cine back and forth (i.e., frames 1 to n, followed by frames n to 1), in addition to the standard
forward cine.
RECON TOMO: Display all slices in spatial order. Typical display actions can include
reorientation to other viewing planes (MPR). Processing (not required by the NM Profile) can
include oblique reorientation to cardiac relative views, creation of MIP images, etc. Example:
Stress-Rest in a Row Layout display, or a single dataset in an MPR Display.
GATED TOMO: Cine all frames (angular views) from one energy window, one (logical)
detector, one rotation, one R-R interval, and one Time Slot, or all Time Slots from one energy
window, detector, rotation, R-R interval, and Angular View. Some users do not review theseimages unless data acquisition problems are suspected.
GATED RECON TOMO: Cine all frames from one R-R Interval and one Time Slot. Typical
processing includes all functions done to RECON TOMO images, plus special cardiac
processing such as bull’s-eye plot creation.

6335

Examples of simultaneous cine: three TOMO images (used for quality control of cardiac raw
projections); three GATED planar exams (RVGs); or 2 detectors from a dynamic image.
Note that in the U.S., ACR accreditation requires the ability to label displayed images with thepatient name, patient age (or date of birth), patient identification number, date of exam,
institution name, and some means of identifying the technologist who performed the study.

6340

The Nuclear Medicine Accreditation Committee of the ACR has further required that laterality
and orientation information also be provided.
______________________________________________________________________________
288
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix F: Security Environment Considerations

6345

IHE compliant systems usually process private healthcare information. This is subject to national
privacy regulations, and possibly other state and contractual requirements. The IHE profiles do
not fully define the security mechanisms necessary to protect this information. The ITI Audit
Trail and Node Authentication (ATNA) Profile (ITI TF-1: 9) provides one component of thissolution.
IHE assumes that actors will be installed on nodes with the following characteristics:

6350

•

Each node has a security policy and procedure that applies to its operation.
This is assumed to be part of the healthcare enterprise security policy.

•

Any user (human, or application process) external to the node boundaries is submitted toan access control procedure in which the user/application will be authenticated.

•

All required audit trail events are captured and recorded.

The profiles in this framework assume the following environment:•

Physical Security Environment•

The equipment is assumed to be located in a physically protected and actively
monitored area. This is normally the case with modality equipment because of other
patient safety, privacy, and operational concerns. Similarly, the HIS systems andvarious archives are normally protected. Equipment like PACS workstations are
sometimes placed in unprotected areas, but it is usually located where hospital staff
monitors and limit access. It assumes that the threat of equipment modification isprotected against by means of the physical security mechanisms.

•

The network equipment that connects the computers is also assumed to be physicallyprotected against unauthorized connections and unauthorized modifications. In thetreatment areas of most hospitals the network equipment is in ceilings, cableways,
locked cabinets, and other protected areas. There is usually staff present to monitor
that no unauthorized activity is taking place.

•

Local procedures and operations will be in place to ensure that the physical security
assumptions are valid for other areas of the hospital, such as administrative offices,that may be at greater risk.

6370

•

Remote locations, especially home offices, are not physically protected. Other means
will be used to provide equivalent protection. This may include the use of technology
such as VPN connections or HTTPS encryption. Use of encryption or VPN is not acomplete replacement for physical security but may be part of an overall protection
system.

6375•

The home computer that is used for both personal and professional purposes isdifficult to protect. It will be protected from inadvertent modification by malicious
software or its use will be prohibited.

6355

6360

6365

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

Network Security Environment•

6380

In addition to the physical security of the network, there will be protection against
network access by unsupervised systems. This is typically provided by mechanisms
such as firewalls and VPNs.

The threat profile is assumed to be:•

Accidental and inadvertent misuse•

Individual abuse for personal gain, malice, revenge, or curiosity. The abusers are
assumed to have only limited access to the underlying systems and software. They are notexpert at the internal structure of the systems.

•

Random untargeted abuse, such as from an Internet hacker.

6385

The threat profile also assumes that the following threats are either not present or otherwise
protected.
6390•

Individual abuse by a system administrator, system developer, or other expert.

•

Military or hostile government action•

Organized criminal attack

6395

IHE addresses only those security requirements related to IT systems within the scope of IHE
healthcare applications. It does not address security requirements for defending against network
attacks, virus infection, etc.

6400

IHE does not mandate the use of encryption because the performance impact of current
encryption algorithms is excessive. Most hospital networks provide adequate security throughphysical and procedural mechanisms. The additional performance penalty for encryption is notjustified for these networks. The profiles permit the use of encryption so that it can be used aspart of an overall security plan.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix G: Patient Information Reconciliation for XDS-I.b(INFORMATIVE)
6405

6410

Patient Information Reconciliation (PIR) workflow within a local domain is well understood andaddressed within the IHE PIR Integration Profile. However, within an XDS affinity domain,
there is the added complexity of managing patient information within the XDS Registry andsynchronizing data between the document sources, repository and registry.
The XDS Profile does not address the challenges of PIR. The reason for this is scope
management (at the time of writing the initial XDS Profile) as well as a lack of content profiles
to stress the PIR issue. It is the intent of the ITI Technical Committee to address the issue of PIR
within XDS in due course.
Given that PIR will be addressed within the XDS Profile, this Appendix is consideredinformative and serves to demonstrate that imaging information content does not introduce any
new or imaging information content specific PIR issues.

6415

G.1 Context and Assumptions
G.1.1 XDS Affinity Domain Assumptions•

The Document Registry assumes that all documents have a normalized patient ID
pertaining to the XDS Affinity Domain. Therefore:•

The XDS Affinity Domain must have a Patient Identification Domain in order torealize normalized patient IDs.

•

The XDS Affinity Domain must have a Patient Identity Source Actor•

To simplify description in this section, the nomenclature for the XDS Affinity
Domain will be “XAD”.

6420

•

A Document Source is responsible for obtaining the XAD patient ID for registering the
document within the registry. The XAD patient ID that is obtained is only used for thispurpose and is not used to update any patient ID’s within the document. Patient ID’s
within the document shall remain unchanged by the registration process•

A Document Consumer is expected to query the Document Registry using the XAD
patient ID•

The Registry can only accept a document if the document has a valid XAD patient ID•

The Registry must check to see if the XAD patient ID is valid. This can be done in two
ways:

6425

6430

•

Query the XAD Patient Identity Source to see if the XAD patient ID exists – notsupported at this time______________________________________________________________________________
291
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
•

6435

•

Maintain all XAD patient IDs in the registry irrespective of whether there are
documents for that patient i.e., keep in synch with the XAD Patient Identity Source –this is the expected model

The Registry cannot accept a document with an OID that is already registered•

If a document is submitted that has the OID of a document already registered, theRegistry will reject the submission•

If a document is re-submitted and, thereby, is identical to a document alreadysubmitted, the Registry will reject the submission

6440

G.1.2 Metadata in the Registry•

The XAD patient ID is the only piece of metadata that can be reliably used to query for apatient•

The Registry maintains supporting patient information such as Name, Sex, DoB, etc. but
is NOT obligated to ensure the referential integrity of this data. Therefore:

6445

6450
•

•

This information is NOT used for query matching (but is only used for audits andpotential verification of Document Consumers)•

There is no requirement for the XDS Document Registry to verify that the meta-datain the Registry corresponds to the patient information in the document itself

The Registry does track the local domain source patient ID, but this is not used for querymatching

G.1.3 Patient Identity Management in the XDS Registry
6455

6460

•

The Registry keeps a list of known XAD patient IDs•

The Registry associates documents with the patient IDs•

The Registry receives patient “merge” notifications from the XAD Patient Identity
Source•The Registry is responsible for updating XAD patient IDs associated with documents•

The Registry does not update metadata nor document content•

If the clinical content of a document has changed, the Document Source is responsible for
updating the Repository and Registry

G.1.4 Expected Implementation Models for Patient Identity Management
In a cross enterprise scenario, we assume that there are multiple patient identity domains
6465•

Local patient identity domains that support one or more enterprises. These pertain toDocument Sources and Document Consumers•

Affinity Domain patient identity domain______________________________________________________________________________
292
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Each patient identity domain has a Patient Identity Source. In the case of local domains, this is
likely to be an ADT system. For the Affinity Domain, this is yet another patient registry.
6470

6475

6480

6485

A participating enterprise may deploy a Patient Identifier Cross-Referencing (PIX) Manager tocross-map Patient ID in the local domain to Patient ID in XAD domain. In such cases, the Cross
Reference Manager will interact with the Affinity Domain Patient Identity Source.
Document sources and consumers are required to obtain a normalized XAD patient ID. The
mechanism for achieving this is dependent on the implementation of patient identity feeds andpatient identity cross-reference manages within the Affinity Domain. For example, where local
domains have Patient Identity X-ref managers, the document sources and consumers obtain thenormalized XAD patient ID from the Affinity Domain patient identity source via the X-refmanagers. The document sources and consumers can also obtain the XAD patient ID using othermethods such as IHE PDQ or non- IHE approaches.
For the sake of discussion, no assumptions are made on how document sources and consumers
interact with the XAD patient identity domain – it could be directly or through a local domain Xref manager.
Further information on integrating Source and Consumer actors in XDS and XDS-I.b with other
IT-Infrastructure actors for exchanging patient identifying data across identity domains can befound in ITI TF-1: E.3, E.4, E.5.

G.2 Patient Information Reconciliation (PIR) in an Affinity Domain

6490

PIR workflow within a local domain is well understood and addressed within the IHE PIR
Integration Profile. However, within an XDS affinity domain, there is the added complexity ofmanaging patient information within the XDS Registry and synchronizing data between the
document sources, repository and registry.
G.2.1 Patient Merge within XAD Patient Identity Domain

6495

•

XAD patient identity domain merges two patients•

Document sources are unaware of the merge transaction within XAD patient identity
domainIn this situation:•

XDS Registry receives a merge notification from the XAD patient identity source andapplies merge logic to the registry•

Document consumers have continued access to documents pertaining to the patient sinceconsumers are expected to obtain the XAD patient ID for the patient at the time ofquerying the Registry•

Document sources are unaware of the merge transaction that occurred in the XDS
registry and do not need to be made aware of this merge. The reasons for this are:

6500

•

Consumers have continued access to the document______________________________________________________________________________
293
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•The document source must query for the XAD patient ID before attempting tointeract with the repository and registry. As such, the document source will have an
updated XAD patient ID at the time of interacting with the registry.

•

When a document source wishes to submit a change to the document:•

The document source must query for the XAD patient ID before registering the new
document•

The document source must register the new document with a request to deprecate theold document. From the document source’s perspective, the old document is still
associated with the original XAD patient ID. By virtue of obtaining a new XAD
patient ID for the patient, the document source must assume that a patient merge hastaken place and use the new XAD patient ID to deprecate the old document

6505

6510

6515

The process flow is described in more detail as follows:
Scenario:•

Key identifier for a patient within the XAD patient identity domain changes, such as
health number•

The XAD patient identity source merges two patients

6520
Process Steps:
1. The XAD patient identity source sends a “merge” notification to the XDS Registry
2. XDS Registry applies merge logic to the patients within the merge notification•
6525

The metadata in the registry will be accurate with the exception of the source patientID

G.2.2 Local Domain Patient Update - XAD Domain Patient ID does not change

6530

•

Demographics for the patient change•

Local domain patient ID does NOT change•

XAD patient ID does NOT change

In this scenario:

6535

•

XDS Registry does nothing since the XAD patient ID has not changed•

If a document source changes the patient demographics content of a document and a new
document is created then this document should be registered with the XDS
repository/registry as a replacement to the old document______________________________________________________________________________
294
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________The process flow is described in more detail as follows:
Scenario:•
6540

Patient first name is corrected from “Jamie” to “James” in the local domain patient
identity source

Process Steps:
1. Update information flows from the local domain patient identity source (i.e., ADT) to the
document source: image manager/archive.
6545•

Document source updates its database to correct demographics•

Either: Document source does not change the document
•

•

6550

The Document Source does not update the repository/registry. In this scenario, thepatient demographics: Name, Dob, Sex, etc.; in the Document Source do notmatch those in the XDS Registry. This is acceptable in the XDS framework

Or: Document source changes the document•

The Document Source updates the repository/registry with an addendum

2. The Registry takes no action as the XAD patient ID has not changed

6555

G.2.3 Local Domain Patient Update - XAD Domain Patient Merge•

Demographics for the patient change•

Local domain patient ID does NOT change•

XAD patient ID does change and triggers a merge within XAD domain•

Document sources are unaware of the merge transaction within XAD patient identity
domain6560

In this scenario:•
6565

See G.2.1 Patient Merge within XAD Patient Identity Domain

The process flow is described in more detail as follows:
Scenario:•

Patient last name is corrected from “Alfonsp” to “Alfonso” within local domain patient
identity source______________________________________________________________________________
295
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•
6570

XAD domain patient identity source merges “Alfonsp: XAD-Pp” into “Alfonso: XADPa” – patient “Alfonso” was already registered within the XAD domain with patient ID
XAD-PaProcess Steps:
•

6575

6580

6585

See G.2.1 Patient Merge within XAD Patient Identity Domain

G.2.4 Local Domain Patient Merge – XAD Domain Patient ID does not change•

Demographics for the patient changes•

Local domain patient identity source merges patient A with patient B•

XAD patient ID for patient A and patient B are the same

In this scenario:•

XDS Registry does nothing since the XAD patient ID for patient A and patient B is thesame•Document sources apply merge logic to the documents within their database i.e.,
documents are now associated with a new local domain patient ID•

Document sources must now query XAD patient identity source to obtain the XAD
patient ID for the merged patient•

The XAD patient ID is the same as already associated with the document:

6590

•

If the document source does not change the document content, the document source
does not need to interact with XDS Repository/Registry – status quo•

If the document source changes the patient demographics content of a document anda new document is created, then this document should be registered with the XDS
repository/registry as a replacement to the existing document.

The process flow is described in more detail as follows:
Scenario:
6595

6600

•

Patient last name is corrected from “Smythe” to “Smyth”•

ADT already has an entry for “Smyth”•“Smythe” with local domain patient ID D-123 is merged with Smyth with local domain
patient ID D-456•

XAD Patient Identity Source already recognized “Smythe: D-123” and “Smyth: D-456”
as the same patient and, therefore, assigned each with the same XAD patient ID: XAD-Px______________________________________________________________________________
296
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
Process Steps:
1. Update information flows from the local domain patient identity source (i.e., ADT) to the
document source: image manager/archive.
•

6605

Document source applies merge logic to the database: documents for the merged
patient are associated with the new patient ID

2. Document source queries the XAD patient identity domain to determine whether the
XAD patient ID has changed for the merged documents. In this case the XAD patient ID
does not change
6610

3. Document source updates the demographics of the document•

Either: Document source makes no changes to the document – demographics are in
the database
•

6615
•

The Document Source need not update the repository/registry. In this scenario,
the patient demographics in the Document Source do not match those in the XDS
Registry. This is acceptable in the XDS framework

Or: Document source changes the document•

The Document Source updates the repository/registry with an addendum

4. The Registry takes no action as the XAD patient ID has not changed

6620

G.2.5 Local Domain Patient Merge – XAD Domain Patient Merge•

Demographics for the patient changes•

Local domain patient identity source merges patient A with patient B•

XAD patient IDs for patient A and patient B are different•

Patient A is merged with patient B in the XAD domain patient identity source

6625
There are three situations that can occur:
1. XDS Registry merge prior to Document Source merge

6630

•

XDS Registry receives a merge notification from the XAD patient identity source andapplies merge logic to the registry•

Document sources are unaware of the merge transaction that occurred in the XDS
registry and do not need to know about this transaction (see G.2.1)•

Document consumers have continued access to documents pertaining to the patient
since consumers are expected to obtain the XAD patient ID for the patient at the timeof querying the Registry______________________________________________________________________________
297
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6635

6640

•

Document sources apply merge logic to the documents within their database i.e.,
documents are now associated with a new local domain patient ID•

Document sources must now query XAD patient identity source to obtain the XAD
patient ID for the merged patient•

The XAD patient ID for the documents has changed:•

The document source changes the XAD patient ID associated with the documents – itcan assume that the Registry has made this change as well•If the document source does not change the document content, the document source
does not need to interact with XDS Repository/Registry – status quo•

If the document source changes the patient demographics content of a document anda new document is created then this document should be registered with the XDS
repository/registry – the existing document is deprecated.

6645

2. Document Source merge prior to XDS Registry merge•

Document sources apply merge logic to the documents within their database i.e.,
documents are now associated with a new local domain patient ID•

Document sources must now query XAD patient identity source to obtain the XAD
patient ID for the merged patient•

The XAD patient ID is the same as already associated with the document:

6650

•

If the document source does not change the document content, the document
source does not need to interact with XDS Repository/Registry – status quo•

If the document source changes the patient demographics content of a document
and a new document is created, then this document should be registered with the
XDS repository/registry as a replacement to the old document

6655

•

XDS Registry receives a merge notification from the XAD patient identity source andapplies merge logic to the registry•

Document sources are unaware of the merge transaction that occurred in the XDS
registry and do not need to know about this transaction•

Document consumers have continued access to documents pertaining to the patient sinceconsumers are expected to obtain the XAD patient ID for the patient at the time ofquerying the Registry

6660

6665

3. Document Source merge at same time as XDS Registry merge•

Document sources apply merge logic to the documents within their database i.e.,
documents are now associated with a new local domain patient ID______________________________________________________________________________
298
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________•

6670

Document sources must now query XAD patient identity source to obtain the XAD
patient ID for the merged patient•

6675

The XAD patient ID is the same as already associated with the document•

XDS Registry receives a merge notification from the XAD patient identity source andapplies merge logic to the registry•

Document source chooses to change the patient demographics content of a document
and a new document is created. This document is registered with the XDS
repository/registry:

6680

•

The XAD patient ID for this document has now been merged in the XDS Registry
and, therefore, is no longer valid•

The Registry will reject the document registration transaction as the XAD patient
ID used in the transaction is no longer valid.

•

Document sources must now query XAD patient identity source to obtain the
XAD patient ID for the merged patient and re-register the document with the
XDS repository/registry

6685
Scenario:

6690•

Patient last name is corrected from “Smythe” to “Smyth”•

ADT already has an entry for “Smyth”•

Smythe: patient ID D-123 is merged with Smyth: patient ID D-456•

XAD Patient Identity Source has separate entries for both “Smythe: XAD-Pc” and“Smyth: XAD-Pf”. As such, it merges these two patients in to “Smyth: XAD-Pf”.

Process Steps:
6695

The process flow is a combination of the previous scenario process flows and, thereby, notrepeated here.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

Appendix H: Security considerations for XDS-I.b (informative)

6700

This IHE profile does not specify all the details of the security environment for exchanging
radiology information. The IHE includes several security profiles that apply to the XDS/ XDSI.b use. The use of these security profiles in the first trial implementation for XDS-I.b will likely
be optional. The security profiles make assumptions about the overall security environment andare configurable to adapt to different security requirements.

6705

Figure H-1 shows typical transactions for XDS-I.b. Each transaction goes through security andprivacy controls. This figure illustrates use of firewall access points and TLS controls for all
XDS-I.b participants, including the Imaging Document Source. The firewalls may have simple
easy to implement rules or more complex rules depending upon local policies. The flows shownin Figure H-1 are described in more detail below:
Flow #1, The Store Images, etc. transactions:a) Internal firewall rules I:

6710- Simple rules: “outgoing HTTP is OK”- Complex rules: examine source IP, destination IP, HTTP headers to decide whether topermit the connection.
b) TLS within each actor:- IM/IA: Is this really the authorized Image Document Source that was requested?

6715- Repository: Is this really an authorized IM/IA?
c) Once the TLS connection is established there is further processing, generation of audit
records, etc.
Flow #2, The Provide and Register Imaging Document Set transaction:

6720a) does not cross a firewallb, c) TLS, authorization, auditing as above.
Flow #3, The Register transactiona) External firewall rules II:

6725- Simple: Outgoing HTTP is OK- Complex: examine source IP, destination IP, HTTP headers to decide whether to permit theconnection.
b, c) TLS, authorization, auditing as above.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6730

Flow #4, Query Documents transaction:a) External firewall access rules II:- Simple: Incoming HTTP to the DMZ is OK- Complex: very tricky given many different uses for HTTP incoming by different web
applications.

6735b, c) TLS, authorization, auditing as above.
Flow #5, Retrieve Images, etc. transactions:a) External firewall access rules III:
- Simple: Incoming DICOM is only permitted from authorized affinity domain IP blocks.

6740- Complex: Examine the DICOM retrieve connection initiator and the targeting acceptor IP
addresses, and permit only connections between a priori authorized pairs of initiator andacceptor.
b, c) TLS, authorization, auditing as above.

6745

This example shows access for both HTTP and DICOM traffic. It is easier to get multi-layer
protection for the DICOM traffic because it is easily differentiated from the many diverse uses of
HTTP for web applications and services. Then the TLS security, actor authorization rules, andauditing are applied to all traffic regardless of type.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6750

Figure H-1: Security Environment

IHE assumes that there will be some form of external control point. This usually involves
technologies like VPNs, firewalls, routers, etc. IHE does not specify what is necessary here, andthe IHE profiles will operate and provide a good level of security even when the external control
point is missing.
6755

6760

The purpose of having an external control point is:•

To control the low level network access between the Internet and the Imaging Document
Source and Document Repository. The precision of this control is up to the sites
involved. One common configuration is to merely restrict the list of IP Ports that are
permitted access. This simplifies the security requirements on the server.

•

Log and monitor all traffic for indications of hostile or abusive activity. This is usually a
combination of logging and intrusion detection (IDS) activity that is oriented towards theoverall IT organization requirements.

This kind of protection is useful and complements the encryption and access controls defined aspart of IHE’s Audit Trail and Node Authentication (ATNA) Profile and its Radiology Option.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
6765

The internal network is probably divided into two or more zones that are isolated by internal
control points. These internal control points are similar to the external control point, but usually
are much more permissive in terms of the traffic that they allow. They exist both to detectproblems and to provide a means of rapidly isolating portions of the network in the event of asecurity breach.

6770

The Imaging Document Source is assumed to be located in the zone labeled the “Affinity
Domain Zone”. This might also be part of a general DMZ (De-Militarized Zone) for theorganization or it might be a special zone reserved exclusively for Affinity Domain activities.
There are cost and functionality tradeoffs involved in making that decision and the IHE profiles
support both approaches.

6775

IHE will specify the minimum-security requirements for the Imaging Document Source. It will
be expected to comply with the IHE ITI ATNA (Audit Trail and Node Authentication)
Integration Profile. There may be multiple Imaging Document Sources in the Affinity Domain
Zone and they will all be expected to comply with the ATNA Profile. This profile mandates:
•

6780

6785

All connections that might transfer protected health information (PHI) must utilize TLS
configured to:•Authenticate both machines involved•

Ensure that all traffic is encrypted, either directly by TLS or by means of equivalent
protection such as VPN.

•

Enforce access control to the system•

Provide a detailed security audit trail for all PHI related activity and information transfers

The TLS protocol is also widely known as HTTPS. The ATNA Profile mandates this protection
for any DICOM, HL7, HTTP or other protocols.

6790

There may be special auditing requirements for an XDS-I.b actor. For example, in the US there
are HIPAA requirements for disclosure logs. Only the sites themselves can determine what
belongs in a disclosure log. The ATNA logs were not directly intended for this purpose.

6795

The Imaging Document Source may be a system that is complete with its own image archive, or
it may be a proxy machine that relays information to another machine, perhaps located in a
private zone. This is considered an internal design issue by IHE. The IHE XDS-I.b Profile
specifies that the Imaging Document Source must support the XDS-I.b transactions, and does not
specify the internal design.
There are several important design considerations for securing XDS-I.b networks that must be
made by the affinity domain and its members. These are:
1. What kind of external control points are used? IHE recommends that they be present, butdoes not profile them.

6800

2. How to subdivide the enterprise network and whether to establish a dedicated Affinity
Domain Zone. There is an advantage to creating an Affinity Domain Zone with just a
few servers located in it:______________________________________________________________________________
303
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
a. The log analysis is easierb. The certificate and TLS management for node authentication is easier6805

c. The preparation of disclosure logs and the equivalent is easier.
d. The internal control point reduces the risks from a breach of the Affinity Domain
Zone.

6810

6815

3. Whether User Authentication is needed. IHE provides both the Enterprise User
Authentication (EUA) and Cross Enterprise User Authentication (XUA) Profiles. Use ofuser authentication permits additional information to be captured in the audit logs (e.g.,
the identity of the user) and permits additional access control in some situations. The
issues that the affinity domain and sites must address are:a. What to do about automated processes, such as pre-fetch and email. These can be
identified using node authentication via TLS as specified in ATNA, by using simple
identity assertions.
b. How to handle delegation. Often it is clerks, nurses, etc. that are actually operating
the computer to obtain the records for a patient, and it is someone else that will
actually be examining the records. So the user authentication might not provide any
further useful information.

6820

The IHE profiles do not determine these choices. Some reasonable selections include:
1. Not using user authentication. The ATNA ensures that the enterprise and themachine are authenticated. These machines are already authenticated and trusted
to protect PHI information. It may be impractical to track and coordinate thepersonnel activities across all the different organizations.

6825

6830

6835

6840

2. Though not specifically designed for this purpose, it is also possible that the XDSI.b Profile is being used internally within a centrally controlled large organization,
where the Kerberos based identity management of EUA is available. EUA can beused in such an intra-enterprise environment. EUA supports simple identity
assertions. These are based on trusting the authenticated node to provide thecorrect identity of its user.
3. The use of XUA is optional. Where a human user is involved, XUA can be
employed for cross-enterprise user identity assertion. If only machines are
involved, the node authentication provided by ATNA should be sufficient. The
use of XUA requires that the affinity domain establish the authentication policies,
procedures, and have a supporting infrastructure of servers, etc. (Thisinfrastructure may be provided by the local government or might need to beprovided by the affinity domain.)Note: In order to use the IHE XUA Integration Profile, the underlying application protocol must be able to carry a user
identity assertion in its payload. While such a mechanism has been established in HL7 and HTTP/S, themechanism to provide this for DICOM messages is still under development. Thus, XUA Profile cannot (yet) be
employed when retrieving DICOM SOP Instances referenced in the manifest document.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
The affinity domain and individual site policies will determine the choices made. There are IHE
profiles defined to address these alternatives.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6845

Appendix I: Appendix I – Deployment of Dose Registries
The Radiation Exposure Management Profile is intended to facilitate Dose Registry projects.
Participating sites that have implemented the REM Profile can be depended on to provide datawith known contents in a known format and will all support a common transport mechanism. See
the Submit Dose Information transaction for details (RAD TF-3: 4.63).

6850

This appendix includes discussions of logistical issues related to the deployment of dose
registries. This is not part of the normative text of the REM Profile, but the discussions here may
be helpful when deploying and using the REM Profile.

I.1 Dose Registry Deployment Issues
I.1.1
6855

6860

6865

Code Set Management

Although the REM Profile does manage to provide consistent dose data, for a Dose Registry toanalyze dose objects and prepare summary statistics for a specific exam type, anatomy orpathology/indication, it will need to select/group dose objects based on exam type, anatomy orpathology/indication.
If the different sites submitting data used consistent code sets for coding such details, this might
be easy, but unfortunately, for technical and organizational reasons, such code set consistency isunlikely. Due to similar issues, consistency within an organization may even be challenging.
Dose Registries should be prepared to deal with such non-uniformity. For example, they may
need to manage lookup tables to map codes from each submitting organization to a set ofstandard codes or categories. This may involve reverse engineering the codes from CodeDescription fields, when available, or it may involve requesting code sets from participatingsites.
Dose Registries should also be prepared for a lack of detail e.g., there may be a procedure codefor “stent placement” but no indication if it was one stent, three stents, or more.
I.1.2

6870

Configuration of Secure FTP (Submit Dose Information Transaction – RAD63)

The REM Profile requires Dose Information Reporters support the Submit Dose Information
Transaction for the purpose of submitting dose data to Dose Registries.
The Submit Dose Information Transaction specifies the use of FTP over TLS.
When setting up the FTP server the dose registry project should consider useful features such as:
6875•

Setting up individual login accounts for each participating site•

Directing files from clients into specific folders based on their login account id•

Preventing clients from looking at other folders

I.1.3

Alternative Transport Mechanisms______________________________________________________________________________
306
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6880

6885

The Secure FTP Transport defined in the Submit Dose Transaction is intended to provide abaseline transport mechanism. It is not intended to prohibit Dose Registry projects from using
other transport mechanisms.
Having a built-in baseline method available at participating hospitals should make it easier fordose registry projects to get off the ground. However, if a dose registry project feels there isenough benefit, they may choose to define an alternative transport mechanism and find a way to
get it implemented at each of their participating hospitals.
Some alternative transport mechanisms to consider include sending the objects via:
— CD using the IHE Portable Data for Imaging (PDI) Profile— Email using the DICOM Email Media Profile and SMTP
— Network using DICOM C-Move over TLS to a controlled public DICOM server

6890

o Note the need to get each site’s firewalls to allow outgoing DICOM connections.
Some DICOM servers can be configured to accept connections from any source
which would reduce the amount of configuration work at the Registry.
— Network using the IHE Cross-Domain Document Sharing for Imaging (XDS-I) Profileo Note the need to establish an Affinity Domain covering all contributing sites andto fill in the XDS metadata which may be complicated by de-identification.

6895— Network using the IHE Cross-Domain Document Reliable Interchange (XDR) Profileo This might be attractive if XDR features such as multi-file bundles, and“replacing” documents would be useful.
o Note again the need to fill in the XDS metadata.
6900

I.1.4

Encapsulated Dose Registry Submission

Another approach to addressing submission issues and facilitating site is for the organization thatis setting up a dose registry project to develop and distribute a client application to eachparticipating site.
6905

6910

The client includes an implementation of a Dose Information Consumer or Dose Information
Reporter which allows it to gather dose objects from the Image Archive. The client would also
incorporate a proprietary upload mechanism to get the dose objects up to the dose registry.
Note that while this approach has the potential to simplify some technical issues, it introduces a
number of security issues. Some sites may need to review and approve such a client before
allowing foreign software on their network, particularly if it is capable of sending patient data
outside the organization.
Imagine:•the XYZ Dose Registry Client implements the Dose Information Consumer to get dose
objects, and some email or web services protocol to send them to the Dose Registry______________________________________________________________________________
307
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________XYZ Registry
Dose
RegistryXYZ Client
Dose Info
Consumer

Proprietary
Mechanism↓ [RAD-64] Query Dose Information↓ [RAD-65] Retrieve Dose Information

PACS
Image Mgr/
Archive↑ [RAD-62] Store Dose Information↑ [RAD-10] Storage Commitment

Acquisition
Modality
6915

I.2 Real-World Projects
A number of organizations have established or are in the process of establishing Dose Registry
projects.
Project:
6920

6925

ACR Registry - USA

ACR is forming a national Dose Index Registry (DIR). The initial pilot program will compare
CT dose indices across 10-12 facilities to identify areas that may require changes to CT dose
protocols. At the completion of the pilot program, the DIR will launch nationwide.
Their ultimate goal is minimizing dose to the patient population and they are interested in Use
Cases including: Population Dose and Dose Indicators, Dose Reference Levels andBenchmarking. They are specifically not interested in the Patient Dose History Use Case as they
have no plans to become a national personal dose record.
Website: nrdr.acr.org
Project:

French Ministry of Health Registry______________________________________________________________________________
308
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6930

French regulations mandate the submission of Dose Reference Level data to a federal dose
registry managed by the Institut de Radioprotection et de Sûreté Nucléaire / Institute for
Radiation Protection and Nuclear Safety (IRSN).
Every year each specialist must submit dosimetric information (at least 20 patients) for each of atleast two examination types (generally the most frequent and most irradiating examination
types).

6935

The ministry is interested in Use Cases including: Population Dose and Dose Indicators, andDose Reference Levels. Data collection spans Radiography, Fluoroscopy, Mammography,
Computed Tomography and Nuclear Medicine. The data is further broken down by patient age
category, and body part.
Website: www.irsn.org/en

6940

I.3 Dose Monitoring Regulations
Several groups interested in regulatory issues (IEC, FDA, AAPM, etc.) drove original definitionof the DICOM Dose SR objects.

6945

The following sections contain some contributed summaries of different regulatory initiatives.
These are only intended to provide a sense of the type of activities. Readers should refer to theregulations themselves for accurate information.
European Regulatory

6950

European regulation is based on European Directive Euratom 1997/43/EC. The application of thedirective is mandatory in all EU countries (27 today) since 2000. All European national
regulations have to be compatible with the directive. Different countries have varied in theirreactions/actions to Euratom.
Euratom specifies a follow up for each patient and statistical analysis at the population level.
Euratom: http://ec.europa.eu/energy/nuclear/radioprotection/legislation_en.htm
Diagnostic Reference Levels (DRLs) in Europe:
http://www.eu-alara.net/index.php?option=com_content&task=view&id=156&Itemid=536955

French Regulatory
Today two regulations specify the dosimetric information that a user of ionising radiation must
provide in France.

6960— One text, published in March 2004, concerns Dose Reference Levels (DRL) (Arrêté du12 février 2004 relatif aux niveaux de référence diagnostiques en radiologie et enmédecine nucléaire – Journal Officiel de la République Française du 16 mars 2004).
— Another text, published in September 2006, concerns dosimetric information that must bepresent in the medical record of the diagnostic examination (Arrêté du 22 septembre 2006
relatif aux informations dosimétriques devant figurer dans un compte rendu d'acte______________________________________________________________________________
309
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6965

utilisant les rayonnements ionisants - Journal Officiel de la République Française du 29
septembre 2006).
For each medical procedure using ionising radiation, the medical record must include
information allowing estimation of the dose received by the patient.
German & Dutch Regulatory

6970

In Germany and the Netherlands, dose information is not conveyed above the Hospital level.
Dose information is required and must be auditable.
Germany is working on additions to the DICOM Basic Diagnostic Imaging Report to include
Radiation Regulation related details such as:— Pregnancy Status— Indications for Procedure

6975— Physician Responsible for Indication— Performing Person (who administered)— Radioactive Substance Administered— Radiation Exposure (text description of "the exposure")— Performing Person’s Organization Name

6980
Spanish Regulatory
In Spain, dose information is not conveyed above the Hospital level.

6985

Dose information is required in order to audit the use of diagnostic equipment (comparing with
Dose Reference Levels) and must be auditable by the responsible health authority. Also the
responsible health authority and the Nuclear Security Council will guarantee that the distributionof the estimations of resulting individual doses is determined, for the population and thesignificant groups of reference of the population, whose results will be sent to the Ministry of
Health and Consumption.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

6990

6995

7000

7005

7010

7015

7020

7025

GLOSSARY
Terms Specific to this Document
Accession Number: A user-friendly identifier created by the Departmental System, which
identifies an instance of a filler order or imaging service request. It may group one or morerequested procedures.
Actor: An entity within a use case diagram that can perform an action within a use case diagram.
Possible actions are creation or consumption of a message
Dose Object: A persistent DICOM object (See DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation
Dose SR IOD) for recording details related to Irradiation Events. DICOM has defined Dose
Objects for CT and Projection X-ray procedures.
Dose Registry: A system that collects dose information from multiple sites, generally to perform
analysis of Population Dose and Dose Indicators.
DVD: A trademark of the DVD Forum that is not an abbreviation
Evidence Documents: Evidence Documents represent the uninterpreted information that is
primarily managed and used inside the imaging department, although distribution outside theimaging department is not precluded. Evidence documents are non-image information andinclude things such as measurements, CAD results, procedure logs, etc. and are to be encoded as
DICOM SR documents.
Evidence Objects: All objects generated as a result of performing procedure steps on systems in
an imaging department. These objects are used by the reading physician in the process ofcreating a diagnostic report and are managed inside the imaging Department. Examples ofevidence objects include: Images, Presentation States, Key Image Notes and Evidence
Documents.
Expected Actions: Actions which should occur as the result of a trigger event
Foreign Key (FK): A database key that is used as a reference to relate one entity to anotherentity. It may be a unique value, or used in conjunction with another Foreign Key to create aunique value.
Hardcopy Import: The process of importing non-digital data into the Enterprise as DICOM
Objects. The original data may be Films or Documents that are scanned and stored as DICOM
Objects.
Images Available: A transaction or transactions used to determine that images have been stored
in an image archive and may be retrieved.
Interaction Diagram: A diagram which depicts data flow and sequencing of events
Interchange Media: A piece of data-bearing physical media, such as a CD or DVD. The term,
which is used in the DICOM standard, is synonymous with “portable media” or “transfer media”.
Irradiation Event: An irradiation event is one continuous occurrence of irradiation being
applied to a patient. A pulsed fluoro X-Ray acquisition, or a multi-slice helical CT scan are
examples of single events; while a CT scanogram and the helical scan, or two different presses of______________________________________________________________________________
311
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________

7030

7035

7040

7045

7050

7055

7060

the fluoro pedal, or simultaneous irradiation from two X-ray tubes are examples of separate
events. See RAD TF-3: 4.62.4.1.1 in Store Dose Information for a more detailed description
Pre-fetch: The activity of fetching images or other information objects from previously
completed procedures to near-term storage for review of those data.
Process Flow Diagram: A graphical illustration of the flow of processes and interactions among
the actors involved in a particular example
Role: The actions of an actor in a use case.
Scope: A brief description of the transaction.
Trigger Event: An event such as the reception of a message or completion of a process, whichcauses another action to occur.
Use Case: A graphical depiction of the actors and operation of a system.
W3C: A trademark of the World Wide Web Consortium that is not an abbreviation
Web-Viewable: Browsable using a web browser (e.g., XHTML files and JPEG images)
XDS Imaging Document: An XDS Imaging Document is the smallest unit of imaging related
information that may be provided to a Document Repository and registered in a Document
Registry. An XDS Imaging Document may contain a manifest of images (e.g., DICOM Key
Object Selection document) or a radiology report provided either as a PDF document or as
structured and vocabulary coded clinical information (e.g., CDA Release 2).

DICOM Terms
Basic Color Print Management Meta SOP Class: See DICOM PS 3.4
Basic Grayscale Print Management Meta SOP Class: See DICOM PS 3.4
Basic Text SR Storage SOP Class: See DICOM Supplement 23
DICOM Model of the Real World: See DICOM PS 3.3
Enhanced SR Storage SOP Class: See DICOM Supplement 23
Grayscale Softcopy Presentation State Storage SOP Class: See DICOM PS 3.4
Grayscale Standard Display Function: DICOM PS 3.14
Imaging Service Request: See DICOM PS 3.3
Modality: See DICOM PS 3.3
Modality Worklist SOP Class: See DICOM PS 3.4
Modality Performed Procedure Step: See DICOM PS 3.3
Modality Performed Procedure Step Information Module: See DICOM PS 3.3
Modality Performed Procedure Step Relationship Module: See DICOM PS 3.3
Modality Performed Procedure Step SOP Class: See DICOM PS 3.4
Patient: See DICOM PS 3.3
Patient Identification Module: See DICOM PS 3.3
Print Presentation LUT SOP Class: See DICOM PS 3.4______________________________________________________________________________
312
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
7065

7070

7075

Procedure Plan: See DICOM PS 3.3
Procedure Type: See DICOM PS 3.3
Protocol Code: See DICOM PS 3.3
Requested Procedure: See DICOM PS 3.3
Requested Procedure Module: See DICOM PS 3.3
Requested Procedure ID: See DICOM PS 3.3
Results Information Object Definition: See DICOM PS 3.3
Scheduled Procedure Step: See DICOM PS 3.3
Scheduled Procedure Step Module: See DICOM PS 3.3
Storage Commitment SOP Class: See DICOM PS 3.4
Stored Print SOP Class: See DICOM PS 3.4
Structured Reporting Information Object Definitions: See DICOM PS 3.3
Structured Reporting SOP Classes: See DICOM PS 3.4
Structured Reporting Templates: See DICOM PS 3.16
Unique Identifier (UID): See DICOM PS 3.5

7080

7085

7090

7095

HL7 Terms
ADT: See HL7 version 2.3.1
Battery: See HL7 version 2.3.1
Filler: See HL7 version 2.3.1
Observation: See HL7 version 2.3.1
Placer: See HL7 version 2.3.1
Universal Service ID: See HL7 version 2.3.1

Acronyms and Abbreviations
ACR: American College of Radiology
CD: Compact Disk
DAP: Dose Area Product
DLP: Dose Length Product
FDA: Food and Drug Administration (USA)FFDM: Full Field Digital Mammography
FSC: File-Set Creator
FSR: File-Set Reader
GSPS: Grayscale Softcopy Presentation StateHIMSS: Healthcare Information and Management Systems Society______________________________________________________________________________
313
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
7100

7105

7110

7115

7120

7125

HIS: Hospital Information System
HTML: Hyper Text Markup Language
ICRU: International Commission on Radiological Units
IEC: International Electrotechnical Commission
IHE: Integrating the Healthcare Enterprise
IOD: Information Object Definitions
IT: Information Technology
JPEG: Joint Photographic Experts Group
LUT: Look Up Table
MPI: Master Patient Index
MPPS: Modality Performed Procedure StepMQSA: Mammography Quality Standards Act of 1992
MWL: Modality Worklist
NEMA: National Electrical Manufacturers Association
PACS: Picture Archive and Communication System
PHI: Protected Healthcare Information
PPS: Performed Procedure Step
PSD: Peak Skin Dose
QA: Quality Assurance
RIS: Radiology Information System
RSNA: Radiological Society of North America
SCU: Service Class User
SCP: Service Class Provider
SR: Structured Report
UID: Unique Identifier
XHTML: eXtensible Hypertext Markup Language
References[1] American College of Radiology White Paper on Radiation Dose in Medicine, E. Stephen
Amis, et al, Journal of American College of Radiology, 2007, Vol. 4, pp. 272-284

7130[2] Quality Improvement Guidelines for Recording Patient Radiation Dose in the Medical
Record, Donald Miller, Stephen Balter, et al, Journal of Vascular Interventional Radiology,
2004, Vol. 15, pp. 423-429[3] ICRU. Report 74: Patient Dosimetry for X-Rays Used in Medical Imaging. JICRU 5;
2005.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 1 (RAD TF-1): Integration Profiles______________________________________________________________________________
7135[4] IEC. IEC 60601. (2000). Medical electrical equipment - Part 2-43: Particularrequirements for the safety of X-ray equipment for interventional procedures. Geneva; 2000.
[5] IEC. PAS 61910-1 Radiation Dose Documentation Part 1: Equipment for radiography
and radioscopy. Geneva; 2007.

7140[6] FDA. Federal performance standard for diagnostic x-ray systems and their major
components-- FDA. Final rule. Fed Regist 70: 33998 - 34042; 2005.
[7] Capturing Patient Doses from Fluoroscopically Based Diagnostic and Interventional
Systems, Stephen Balter, NCRP Annual Meeting-07; 2008______________________________________________________________________________
315
Rev. 13.0 – Final Text 2014-07-30

Copyright © 2014: IHE International, Inc.