IHE RAD TF Rev17 0 Vol1 FT 2018 07 27

Transcript

1 Integrating the Healthcare Enterprise IHE Radiology (RAD) 5 Technical Framework Volume 1 10 IHE RAD TF -1 Integration Profiles 15 Revision 1 7.0 – Final Text 20 July 27, 2018 Please verify you have the most recent version of this document, which is published here . 25 Copyright © 2018: IHE International, Inc.

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

3 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Chest X -Ray CAD Display (CXCAD) ... 30 2.1.25 Imaging Object Change Management (IOCM) 30 ... 2.1.26 Cross -Community Access for Imaging (XCA -I) ... 2.1.27 31 Post Acquisition Workflow (PAWF) ... 31 2.1.28 Cross 2.1.29 – Imaging (XDR -I) ... 31 75 -Enterprise Reliable Document Interchange 2.1.30 Stereotactic Mammography Image (SMI) ... 31 ... 31 2.1.31 Management of Radiology Report Templates (MRRT) Scheduled Workflow.b (SWF.b) ... 2.1.32 31 2.1.33 Invoke Image Display (IID) ... 31 ... 80 2.1.34 Intentionally Left Blank 31 2.1.35 ... 31 Digital Breast Tomosynthesis (DBT) 2.1.36 Web -based Image Capture (WIC) ... 32 2.1.37 Clinical Decision Support – Order Accountable Tracking (CDS -OAT) ... 32 2.1.38 Radiation Exposure Monitoring – Nuclear Medicine (REM -NM) ... 32 Cross 2.1.39 -WD) -Enterprise Remote Read Workflow Definition (XRR ... 32 85 2.1.40 ... 32 Intentionally Left Blank 2.1.41 Standardized Operational Log Events (SOLE) ... 32 2.1.42 Management of Acquisition Protocols (MAP) ... 32 2.1.43 Results Distribution (RD) ... 32 90 2.2 Options to other Domains’ Profiles ... 32 32 ... Audit Trail and Node Authentication ITI- 2.2.1 2.3 33 Actor Descriptions ... ... 36 2.4 Transaction Descriptions Product Implementations ... 40 2.5 Scheduled Workflow (SWF) ... 44 95 3 ... Actors/Transactions 45 3.1 3.2 ... 47 Scheduled Workflow Integration Profile Options 3.2.1 HL7 v2.5.1 Option ... 49 3.3 Scheduled Workflow Process Flow ... 49 3.3.1 Administrative and Procedure Performance Process Flow ... 49 100 3.3.2 Patient Update Flow ... 52 ... 55 3.3.3 Order Change Flow 3.3.4 ... 59 Exception Management Workflow 3.3.5 Implicit Post- Processing ... 64 3.3.6 Departmental Appointment Booking ... 69 105 3.4 Data Model for Scheduled Workflow ... 70 70 3.4.1 Model of the Real World ... 3.4.2 ... 73 Scheduled Workflow Concepts in Practice 3.4.3 Scheduled Workflow Information Model ... 77 4 Patient Information Reconciliation (PIR) ... 80 110 4.1 Actors/Transactions ... 81 Patient Information Reconciliation Integration Profile Options ... 83 4.2 84 ... 4.2.1 HL7 v2.5.1 Option 4.3 84 ... Unidentified Patient Image Acquisition and Reconciliation ____________________________________________________________________________ 3 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

4 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient Information Reconciliation during Image Acquisition ... 85 115 4.3.1 4.4 Use Cases ... 86 4.4.1 Case 1: Unidentified Patient Registered at ADT and Ordered at the Order Placer ... 86 4.4.2 Case 2: Unidentified Patient Registered at ADT and Ordered at Department System Scheduler/Order Filler ... 88 4.4.3 120 Case 3: Unidentified Patient Registered at ADT but Completed at Modality Prior to ... Order 89 4.4.4 Case 4: Unidentified Patient Assigned Temporary Departmental ID and Scheduled at DSS/Order Filler ... 91 4.4.5 Case 5: Image Acquisition Completed Without Scheduling at Department System Scheduler/Order Filler ... 92 125 4.4.6 95 ... Case 6: Patient Information Reconciliation During Image Acquisition 5 ... 97 Consistent Presentation of Images (CPI) 5.1 Actors/Transactions ... 97 5.2 Consistent Presentation of Images Integration Profile Options ... 99 5.3 Consistent Presentation of Images Process Flow ... 100 130 Presentation of Grouped Procedures (PGP) 6 ... 103 6.1 ... 103 Actors/Transactions 6.2 Presentation of Grouped Procedures Integration Profile Options ... 104 6.3 Presentation of Group Procedures Process Flow ... 105 7 Access to Radiology Information (ARI) ... 108 135 ... 108 7.1 Actors/Transactions ... Access to Radiology Information Integration Profile Options 7.2 109 7.3 110 Multiple Sources Option ... ... 110 7.3.1 Requirements for the Multiple Sources Option Key Image Note (KIN) ... 112 140 8 Actors/Transactions ... 112 8.1 8.2 Key Image Notes Integration Profile Options ... 113 8.3 Key Image Note Pattern ... 114 9 Simple Image and Numeric Report (SINR) ... 115 9.1 Actors/Transactions ... 115 145 9.2 Simple Image and Numeric Report Integration Profile Options ... 116 117 9.3 Diagnostic Report Process Flow ... 9.4 ... 119 Diagnostic Reporting Use Cases 9.4.1 Simple Image Report ... 119 9.4.2 Simple Image and Numeric Report ... 120 150 9.4.3 Observation Context ... 121 Basic Security (SEC) - 10 ... DEPRECATED 122 11 ... 123 Charge Posting (CHG) 11.1 Actors/Transactions ... 124 11.2 Charge Posting Integration Profile Options ... 125 155 11.3 Charge Posting Process Flow ... 127 128 11.3.1 Use Cases ... 11.3.2 128 ... Billing Technical ____________________________________________________________________________ 4 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

5 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Professional Billing ... 128 11.3.3 Data Model for Charge Posting 129 160 ... 11.4 Model of the Real World ... 129 11.4.1 Post -Processing Workflow (PWF) ... 131 12 Actors/Transactions 12.1 131 ... 12.2 Post -Processing Workflow Integration Profile Options ... 133 165 ... 134 12.3 Implementation Issues ... 12.3.1 134 Actor Grouping Clarification 12.3.2 Input Availability ... 135 ... 12.3.3 136 Evidence Creators in Scheduled Workflow vs. Post -Processing Workflow 12.4 -Processing Process Flow ... 136 Post 12.4.1 Computer Aided Detection Use Case ... 136 170 12.4.2 3D Reconstruction Use Case ... 137 12.4.3 Post -Processing Process Flow Diagrams ... 137 13 Reporting Workflow (RWF) ... 141 13.1 Actors/Transactions ... 141 13.1.1 Actor Grouping Clarification ... 143 175 13.1.2 Input Availability ... 144 Reporting Workflow Integration Profile Options ... 144 13.2 ... 145 13.2.1 HL7 v2.5.1 Option Reporting Tasks 13.3 145 ... 13.4 149 180 Diagnostic Reporting Use Cases ... Use case 1: Predefined Report ... 149 13.4.1 Use case 2: Workitem Deferred ... 150 13.4.2 Use case 3: Direct Report Creation ... 151 13.4.3 ... Use case 4: Interpretation and Dictation 152 13.4.4 13.4.5 Use case 5: Transcription ... 154 185 13.4.6 Use case 6: Partial completion ... 155 13.4.7 Use case 7: Verification ... 156 Use case 8: Double reading ... 157 13.4.8 13.4.9 Use case 9: Comparison ... 158 159 190 13.4.10 Use case 10: Review ... 159 Use case 11: Over Read ... 13.4.11 ... 160 14 Evidence Documents (ED) Actors/Transactions ... 160 14.1 Evidence Documents Integration Profile Options ... 161 14.2 14.3 Evidence Document Process Flow ... 162 195 Portable Data for Imaging Integration Profile (PDI) ... 165 15 15.1 ... 165 Actors/ Transactions 15.2 Portable Data for Imaging Integration Profile Options ... 167 15.3 Portable Data for Imaging Process Flow ... 167 15.3.1 Use Cases ... 168 200 ... 169 15.3.2 Process Flow Description 15.4 172 ... Media Content ____________________________________________________________________________ 5 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

6 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ DICOM Content ... 172 15.4.1 Web Content Option ... 172 15.4.2 15.4.3 ... 172 205 Other Content 15.4.4 Media Type (CD, DVD and USB) ... 173 15.5 Security and Privacy Aspects ... 173 16 Profile ... 175 NM Image Integration Actors/ Transactions ... 175 16.1 16.2 NM Image Integration Profile Options ... 177 210 16.3 NM Image Process Flow ... 178 179 ... 17 Teaching File and Clinical Trial Export (TCE) 17.1 ... 179 Actors/Transactions 17.2 Teaching File and Clinical Trial Export Integration Profile Options ... 180 17.2.1 De -identify Pixel Data Option ... 181 215 17.2.2 Remap Identifiers Option ... 181 182 17.2.3 Additional Teaching File Information Option ... 17.2.4 ... 182 Delay for Reason Option 17.3 Implementation Issues ... 182 17.4 Teaching File and Clinical Trial Export Integration Profile Process Flow ... 183 220 Teaching File Use Cases ... 185 17.4.1 Clinical Trial Use Cases ... 189 17.4.2 ... 190 17.4.3 Research Collection Use Cases 190 ... Publication Authoring Use Cases 17.4.4 18 -I.b) Integration Profile ... 191 225 -Enterprise Document Sharing for Imaging (XDS Cross Actors/ Transactions ... 192 18.1 Integration Profile Options ... 194 18.2 Set of DICOM Instances Option ... 195 18.2.1 PDF Report Option 195 ... 18.2.2 18.2.3 CDA Wrapped Text Report Option ... 195 230 CDA Imaging Report with Structured Headings Option ... 195 18.2.4 Image Information Sharing Process Flow ... 195 18.3 18.3.1 Overview of Imaging Information Sharing Use Cases ... 195 18.3.2 Assumptions ... 196 18.3.3 235 197 Use cases ... 18.3.4 ... 206 Queries 18.4 Consumer Processing ... 206 18.4.1 Consumer Processing – Set of DICOM Instances ... 206 18.5 Patient Information Reconciliation ... 206 Security considerations 18.6 ... 207 240 19 ... 208 Mammography Image Integration Profile 19.1 Actors/ Transactions ... 208 19.2 Mammography Image Integration Profile Options ... 210 19.3 Mammography Image Profile Process Flow ... 211 212 245 20 Image Fusion (FUS) ... 213 ... Import Reconciliation Workflow (IRWF) 21 ____________________________________________________________________________ 6 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

7 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Actors/Transactions ... 213 21.1 Import Reconciliation Workflow Integration Profile Options 215 ... 21.2 Scheduled Import Option ... 216 21.2.1 Unscheduled Import Option ... 216 250 21.2.2 21.3 ... 216 Integration Workflow Process Flow 21.3.1 Import Process Flow ... 217 ... 222 21.3.2 Import Exception Management Workflow Radiation Exposure Monitoring (REM) Integration Profile 22 223 ... 22.1 Actors/ Transactions ... 224 255 226 22.2 Radiation Exposure Monitoring Integration Profile Options ... 22.3 Radiation Exposure Monitoring Process Flow ... 226 227 ... 22.3.1 General Case -World Use Cases ... 228 22.3.2 Real Example REM Profile Deployments ... 231 260 22.3.3 22.4 Radiation Exposure Monitoring Profile Security Considerations ... 232 22.5 Relation to Other Profiles ... 233 22.5.1 Radiology Profiles ... 233 22.5.2 ITI Profiles ... 233 23 ... 234 265 Mammography Acquisition Workflow (MAWF) 24 MR Diffusion Imaging (DIFF) ... 234 25 CT/MR Perfusion Imaging with Contrast (PERF) ... 234 234 26 Basic Image Review (BIR) ... 234 ... -Ray CAD Display (CXCAD) Chest X 27 28 235 270 Imaging Object Change Management (IOCM) ... Actors/ Transactions ... 235 28.1 Imaging Object Change Management Integration Profile Options ... 237 28.2 Imaging Object Change Management Integration Profile Actor Groupings and Profile 28.3 Interactions ... 237 28.4 Imaging Object Change Management Process Flow ... 238 275 28.4.1 Use Case: Data Retention Expiration ... 239 28.4.2 Use Case: Image Rejection for Quality Reasons ... 240 28.4.3 Use Case: Image Correction for Patient Safety Reasons ... 241 28.4.4 Use Case: Object Correction due to Modality Worklist Selection Error ... 243 ... 248 28.5 Imaging Object Change Management Security Considerations 280 -Community Access for Imaging (XCA -I) ... 250 Cross 29 Actors/ Transactions ... 250 29.1 29.1.1 Actor Requirements ... 252 29.2 XCA- I Profile Options ... 252 XCA- 29.3 I Process Flow ... 252 285 Use Case – Image set sharing between communities ... 252 29.3.1 29.3.2 Detailed Interactions ... 253 29.3.3 Actor Grouping Considerations ... 256 257 29.4 XCA- I Security Considerations ... XCA Risk Assessment 29.4.1 290 257 ... ____________________________________________________________________________ 7 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

8 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Requirements/Recommendations ... 257 29.4.2 Policy Choices 29.4.3 258 ... 30 Post Acquisition Workflow (PAWF) ... 258 31 Cross -Enterprise Reliable Document Interchange – Imaging (XDR -I) ... 258 32 Stereotactic Mammography Image (SMI) ... 258 295 33 Management of Radiology Report Templates (MRRT) ... 258 34 Scheduled Workflow.b (SWF.b) ... 258 259 ... Invoke Image Display (IID) 35 Temporarily left blank ... 259 36 260 Digital Breast Tomosynthesis (DBT) ... 300 37 37.1 DBT Actors, Transactions, and Content Modules ... 260 37.1.1 Actor Descriptions and Actor Profile Requirements ... 262 37.2 DBT Actor Options ... 263 ... 263 37.2.1 Key Images Option 37.2.2 Partial View Option 264 305 ... 37.2.3 For Presentation Breast Projection X -Ray Images Option ... 264 37.2.4 For Processing Breast Projection X ... -Ray Images Option 264 37.2.5 User Annotation Option ... 264 37.2.6 Media Creation Option ... 265 310 37.3 DBT Required Actor Groupings ... 265 37.4 DBT Overview ... 266 37.4.1 Concepts 266 ... 266 ... 37.4.2 Use Cases 37.5 DBT Security Considerations 274 ... 37.6 DBT Cross Profile Considerations ... 274 315 Web -based Image Capture (WIC) ... 275 38 Clinical Decision Support – Order Accountable Tracking (CDS -OAT) ... 275 39 -NM) Radiation Exposure Monitoring – Nuclear Medicine (REM 275 ... 40 41 Cross -Enterprise Remove Reading Workflow Definition - (XRR -WD) ... 275 42 Intentionally Left Blank ... 275 320 43 Standardized Operational Log Events (SOLE) ... 275 44 Management of Acquisition Protocols (MAP) ... 275 45 275 ... Results Distribution (RD) Appendix A: ... 277 Clarification of Accession Number and Requested Procedure ID A.1 Structure of an Order for Imaging Service ... 277 325 Appendix B: Topics for Standards Corrections or Supplements ... 279 B.1 HL7 Topics ... 279 B.1.1 Versio n 2.5 ... 279 B.1.2 HL7 Conformance ... 279 B.2 DICOM Topics ... 279 330 Appendix C: Overview of the Information Exchange between Department System Scheduler/Order Filler and Image Manager ... 280 280 ... C.1 Exchange of Patient Information 280 ... Exchange of Visit and Order Information C.2 ____________________________________________________________________________ 8 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

9 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Exchange of Procedure Information ... 281 335 C.3 Appendix D: IHE Integration Statements ... 282 D.1 ... 282 Structure and Content of an IHE Integration Statement D.2 Format of an IHE Integration Statement ... 283 Appendix E: Nuclear Medicine ... 285 E.1 Introduction ... 285 340 E.2 NM Workflow Overview ... 285 E.2.1 Injection Steps ... 286 Time Separated Acquisitions ... 286 E.2.2 ... 286 E.2.3 Reconstruction as a Separate Operation E.2.4 -Processing ... 287 345 Acquisition Post E.2.5 Clinical Post Processing ... 287 E.2.6 Display and Reviewing ... 288 E.2.7 Workflow Chaining ... 288 NM Worklists ... 288 E.3 E.3.1 NM Worklist Guidelines ... 288 350 E.3.2 ... 291 NM Worklist Examples E.4 NM Data ... 294 E.4.1 Study UIDs and Series UIDs ... 295 E.4.2 NM Image IOD: Multi- Frames and Vectors ... 296 355 296 E.4.3 Typical NM Data Dimensions ... 298 ... NM Display E.5 E.5.1 ... 298 NM Intensity and Color Mapping NM Image Resizing ... 299 E.5.2 NM Display Examples ... 301 E.5.3 Security Environment Considerations ... 306 360 Appendix F: -I.b (INFORMATIVE) Patient Information Reconciliation for XDS 308 ... Appendix G: G.1 ... 308 Context and Assumptions G.1.1 XDS Affinity Domain Assumptions ... 308 G.1.2 Metadata in the Document Registry ... 309 G.1.3 Patient Identity Management in the XDS Registry ... 309 365 G.1.4 Expected Implementation Models for Patient Identity Management ... 309 Patient Information Reconciliation (PIR) in an Affinity Domain G.2 310 ... G.2.1 ... 310 Patient Merge within XAD Patient Identity Domain G.2.2 Local Domain Patient Update - XAD Domain Patient ID does not change ... 311 G.2.3 Local Domain Patient Update - XAD Domain Patient Merge ... 312 370 G.2.4 Local Domain Patient Merge – XAD Domain Patient ID does not change ... 313 Local Domain Patient Merge – XAD Domain Patient Merge G.2.5 ... 314 Appendix H: Security considerations for XDS -I.b (informative) ... 317 Appendix I: Appendix I – Deployment of Dose Registries ... 323 375 I.1 Dose Registry Deployment Issues ... 323 I.1.1 Code Set Management ... 323 -63) . 323 I.1.2 Configuration of Secure FTP (Submit Dose Information Transaction – RAD Alternative Transport Mechanisms I.1.3 324 ... ____________________________________________________________________________ 9 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

10 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 324 ... Encapsulated Dose Registry Submission I.1.4 I.2 380 325 ... -World Projects Real Dose Monitoring Regulations ... I.3 326 ... 328 GLOSSARY ____________________________________________________________________________ 10 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

11 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 385 Introduction 1 Integrating the Healthcare Enterprise (IHE) is an initiative promoting the use of standards to achieve interoperability of health information technology (HIT) systems and effective use of electronic health records (EHRs). IHE provides a forum for volunteer committees of care everal clinical and operational domains to providers, HIT experts and other stakeholders in s 390 -based solutions to critical interoperability issues. IHE publishes the reach consensus on standards implementation guides they produce (called IHE profiles ), first to gather public comment and then for trial imple mentation 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 -world care settings, it is 395 ficient successful testing and deployment in real undergone suf incorporated 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 -based solutions to address common interoperability issues systems: a set of proven, standards and support the convenient and secure use of EHRs. 400 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 can publish conformance statements (called IHE Integration Statements) in the IHE Product Registry -registry.ihe.net). (http://product cal Framework documents are available at The current versions of this and all IHE Techni http://www.ihe.net/Technical_Frameworks / 405 . 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 the activities of this domain, including its committee rosters and how to participate, is available at 410 . http://wiki.ihe.net/index.php?title=Domains General information about IHE, including its governance structure, sponsorship, member ww.ihe.net . organizations and work process, is available at w Overview of Technical Framework 1.1 This document, the IHE Radiology Technical Framework, defines specific implementations of 415 established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The latest version of the document is always available via the Internet at . http://www.ihe.net/Technical_Frameworks Technical Framework identifies a subset of the functional components of the The IH 420 E Radiology healthcare enterprise, called IHE actors , and specifies their interactions in terms of a set of -based transactions. It describes this body of tra coordinated, standards nsactions in progressively ____________________________________________________________________________ 11 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

12 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ greater depth. The present volume provides a high -level view of IHE functionality, showing the transactions organized into functional units called Integration Profiles that highlight their 425 eds. The subsequent volumes, 2 and 3, provide detailed capacity to address specific clinical ne technical descriptions of each IHE transaction. The other domains within the IHE initiative also produce Technical Frameworks within their respective areas that together form the IHE Technical Framewor k. All published IHE Technical http://www.ihe.net/Technical_Frameworks Frameworks are available at . 430 Where applicable, references are made to other technical frameworks. For the conventions on refere ncing other frameworks, see Section 1.6.4 within this volume. 1.2 Overview of Volume 1 1 further describes the general nature, purpose and function of the The remainder of Section s that make up Technical Framework. Section 2 introduces the concept of IHE Integration Profile 435 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 and es. transactions it compris The appendices following the main body of the document provide detailed discussion of specific issues related to the integration profiles and a glossary of terms and acronyms used. 440 Audience 1.3 The intended audience of this document is: • Technical staff of vendors participating in the IHE initiative • IT departments of healthcare institutions 445 • Experts involved in standards development Anyone interested in the technical aspects of integrating healthcare information systems • 1.4 Relationship to Standards The IHE Tech nical Framework identifies functional components of a distributed healthcare ctors), solely from the point of view of their interactions in the environment (referred to as IHE a healthcare enterprise. At its current level of development, it defines a coordi nated set of 450 ®2 ®1 standards. As the scope of the IHE initiative and DICOM transactions based on the HL7 expands, transactions based on other standards will be included as required. 1 HL7 is the registered trademark of Health Level Seven International. 2 DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards lications relating to digital communications of medical information. pub ____________________________________________________________________________ 12 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

13 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ these standards; In some cases, IHE recommends selection of specific options supported by however, IHE does not introduce technical choices that contradict conformance to these 455 . If errors in or extensions to existing standards are identified, IHE’s policy is to report standards ution within their conformance and standards them to the appropriate standards bodies for resol evolution strategy. IHE is therefore an implementation framework, not a standard. Referencing IHE as a standard is inappropriate. Conformance claims by product must still be made in direct reference to specific standards . In addition, vendors who have implemented IHE integration capabilities shall use an 460 IHE Integration Statement to describe the conformance of their product to the specifications in . The purpose of an IHE Integration St atement is to communicate the IHE Technical Framework . to the users of the corresponding product the IHE capabilities it has been designed to support . By Vendors publishing IHE Integration Statements accept full responsibility for their content 465 comparing the IHE Integration Statements from different implementations, a user familiar with ntegration profiles should be able to determine whether and to ctors and i the IHE concepts of a . See Appendix D for the what extent communications might be supported between products Integration Statements. IHE encourages implementers to ensure that products format of such IHE implemented in accordance with the IHE Technical Framework also meet the full requirements of the standards underlying IHE, allowing the products to interact, although possibly at a lower 470 level of integration, with products that have been implemented in conformance with those standards, but not in full accordance with the IHE Technical Framework. 1.5 Relationship to Real -world Architectures he IHE Technical Framework are abstractions of The IHE actors and transactions described in t -world healthcare information system environment. While some of the transactions are the real 475 HIS, Electronic Patient Record, RIS, e.g., traditionally performed by specific product categories ( formation Systems or imaging modalities), the IHE Technical Framework PACS, Clinical In 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 the 480 complete definition of any product that might implement it, nor should the framework itself be taken to comprehensively describe the architecture of a healthcare informa tion 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 485 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 -encompassing information system versus one based on environment bas ed on a single, all multiple systems that together achieve the same end. To illustrate most dramatically the possibilities of the IHE Technical Framework, however, the IHE demonstrations emphasize the 490 int egration of multiple vendors’ systems based on the IHE Technical Framework. ____________________________________________________________________________ 13 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

14 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Conventions 1.6 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 be applied. 495 Actor and Transaction Diagrams and Tables 1.6.1 -world capability that is supported by a set of Each integration profile is a representation of a real actors that interact through transactions. Actors are information systems or components of information systems that produce, manage, or act on categories of information required by operational activities in the enterprise. Transactions are interactions between actors that transfer 500 -based messages. the required information through standards tables of actors and transactions indicate which transactions each actor in a given profile The 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 the destination. In some cases, a profile is dependent on a pre 505 -requisite profile in order to function properly and . For example, Presentation of Grouped Procedures depends on both Scheduled be useful -requisites Workflow and Consistent Presentation of Images being implemented as pre . These dependencies can be found by locating the desired profile in Table 2- 1 and seeing which profiles are listed as required pre- requisites. 510 -requisite profiles in addition to An actor must implement all required transactions in the pre those in the desired profile . In some cases, the pre -requisite is that the actor selects any one of a -processing depends on any given set of profiles to satisfy the pre . For example, Post -requisite one of the content profiles being supported. Process Flow Diagrams 1.6.2 The descriptions of integration profiles that follow include Process Flow Diagrams that illustrate 515 how the profile functions as a sequence of transactions between relevant actors. These diagrams are intended to provide a “big picture” so the transactions can be seen in the . Certain transactions and activities not defined in detail by IHE context of the overall workflow are shown in these diagrams in to provide additional context on where the relevant IHE italics transactions fit into the broader scheme of healthcare information systems. 520 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. 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 525 the transaction to the destination. from the initiator of ____________________________________________________________________________ 14 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

15 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1.6.3 Normative versus informative contents of the Technical Framework Most parts of the Technical Framework describe required or optional characteristics of integration profile For a better understanding of s, Actors and Transactions: these are normative. the text, there also exist illustrating parts in the Technical Framework that are informative and 530 non- normative. According to IETF RFC2119, certain words indicate whether a specific content of the Technical “must”, “required”, “shall”) or optional ( tive: either required ( e.g., e.g., Framework is norma “may”, “recommended”) . Informative content does not contain these key words. Technical Framework Referencing 1.6.4 535 ork volume, a section When references are made to a section within the same Technical Framew 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: -:

, where TF 540 is a short designator for the IHE domain (ITI = IT Infrastructure, RAD = Radiology) is the applicable volume within the given Technical Framework (e.g., 1, 2, 3), and
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 545 Technical Framework, RAD TF -3: 4.33 refers to Section 4.33 in volume 3 of the IHE Radiology Technical Framework. owing format is When references are made to specific transactions (transaction numbers) the foll used: 550 - For example RAD -4 refers to transaction number 4 (Procedure Scheduled) in the Radiology Technical Framework. 201 Scope Additions for 7 – 2018 1.7 This document refers to Year 20 of the IHE initiative in the Radiology Domain. This year’s 555 update incorporates Final Text Change Proposals. 1.8 Comments HIMSS and RSNA w elcome comments on this document and the IHE initiative. They should be or to: submitted at http://www.ihe.net/Radiology_Public_Comments Chris Carr 560 IHE Radiology Secretary 820 Jorie Boulevard ____________________________________________________________________________ 15 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

16 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Oak Brook, IL 60523 Email: [email protected] 1.9 Copyright Permission Health Level Seven, Inc. 565 has granted permission to the IHE to reproduce tables from the HL7 standard . All rights . The HL7 tables in this document are copyrighted by Health Level Seven, Inc reserved. The National Electrical Manufacturers Association (NEMA) has granted permission to the IHE to incorporate portions of the DICOM standard. 570 Material drawn from these documents is credited where used. 1.10 IHE Radiology Technical Framework Development and Maintenance Process The Technical Framework is being continuously extended and maintained by the IHE Technical s. The Development and Maintenance Process of the Framework follows a number of Committee h vendors and users may rely upon in 575 principles to ensure stability of the specification bot 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 actors. and its claiming conformance to any previously defined integration profile To maintain stability of the IHE Technical Framework, modifications occur in a regular annual 580 cycle ( Figure 1.10 -1) according to one of two controlled paths: 1. New Development – Extending the Existing Technical Framework Each year, new functionality to be developed is identified by the IHE Planning Committee. The Technical Committee performs the necessary analysis and design work 585 and generates new text for the Technical Framework. upplement. The scope of a Generally, new functionality is published in the form of a s supplement is to make one of the following additions to the Technical Framework: A new Integration Profile, usually including the introduction of new a • ctors and transactions. ctors in an existing Integration Profile: These may be either a New a 590 • ctors previously defined elsewhere in the Technical Framework, or new ones not yet defined. Transactions identifying the new actor’s responsi bilities in this profile are identified or defined and may be designated as required or optional. To avoid causing compatibility problems for systems that have already implemented that profile, no ransactions are added for existing a 595 ctors in the profile. new required t New options in an existing Integration Profile: These usually add optional • transactions for existing actors in the profiles, or add optional features within existing transactions. ____________________________________________________________________________ 16 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

17 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • Major conceptual changes: They do not change the behavior of ex isting Integration 600 ransactions in the future. ctors or t Profiles but may imply changes or additions to a The publication process consists of certain phases and is clearly indicated on each document. First, the text is published for Public Comment (with a “P C” 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 605 review the comments. Updated text of s upplements 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 new 610 functionality ( e.g., due to experience from the Connectathon), and the text is considered sufficiently 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 with cu rrent version of the Technical Framework resulting in a new version of the the Technical Framework with an increased version number. 2. 615 Maintenance of existing Technical Framework content ersion of the Despite the best efforts of the Technical Committee, a published current v Technical Framework or Trial Implementation documents may contain text that is incorrect, incomplete or unclear. Such issues are handled as Change Proposals and cover: • interoperability of implementations are Corrections: technical issues causing non- 620 fixed without introducing changes in functionality of a stable Integration Profile. • Clarifications: text that can be misunderstood or is ambiguous is made easier to understand or disambiguated, without introducing any technical changes. The publication process is the same for both Corrections and Clarifications, and addresses both changes to Trial Implementations and changes to a current version of the Technical Framework. 625 A Submitted Change Proposal results from issues raised by users, vendors or Technical Committee 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: 630 the parts of the Technical Framework requested to be changed, 1. 2. a problem description, 3. a rationale why the change is considered necessary, 4. and a solution or approach to the problem. The Technical Committee regularly considers Change Proposals which are then either 635 accepted or rejected. Rejected Change Proposal A is published with a rationale from the Technical Committee explaining why the change is not appropriate. ____________________________________________________________________________ 17 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

18 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ An Accepted Change Proposal is assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or 640 corrections. 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 Technical Committee, and then is to be considered as effe ctive. 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 645 Supplement is not possible. The current version of the Techni cal 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 convenient 650 to prior versions of the Technical Framework or Trial Implementation summaries of differences versions of Supplements. During the annual development and maintenance cycle, it is recommended to use Technical Framework documents for implementations as follows: • Product Implementatio ns 655 Products implemented based on Trial Implementation text are expected to review the subsequent Final Text and update their products as necessary. Further, it is expected that vendors will monitor Final Text Change Proposals and make any corrections relevant to their product in a timely fashion. Connectathon Implementations • 660 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 F inal Text Change Proposals. ____________________________________________________________________________ 18 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

19 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 665 1: The figure shows the process of developing and maintaining the Technical Figure 1.10- Framework during an annual cycle. Dashed arrows indicate the assembly (merging) of text. ____________________________________________________________________________ 19 : IHE International, Inc. Copyright © 2018 – Final Text 201 7.0 Rev. 1 8-07-27

20 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Integration Profiles 2 igure 2 670 -1, offer a common language that healthcare IHE Integration Profiles, depicted in F professionals and vendors may use in communicating requirements for the integration of capabilities of products. Integration Profiles describe real -world scenarios or specific sets of integrated systems . An Integration Profile applies to a specified set of actors and for each actor specifies the transactions necessary to support those capabilities. Integration Profiles provide a convenient way for both users and vendors 675 to reference a subset of the 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 s and transactions defined by the IHE Technical restatement of the details regarding IHE actor Framework. 680 The Profiles can be considered in three classes: Content Profiles which address the management of a particular type of content object; Workflow Profiles which address the management of the workflow process by which content is created; and Infrastructure Profiles which address departmental issues. Figure 2 -1 shows the current set of IHE Integration Profiles organized around these classes. 685 The Content Profiles describe the creation, storage, management, retrieval and general use of a particular type of content object . Current Content Profiles include: Consistent Presentation of Images, Key Image Notes, NM Image, Mammography Image, Evidence Documents, and Simple . Additionally, the handling of image content is described inside the Image and Numeric Reports . The profile addresses . Content Profiles are “workflow neutral” Scheduled Workflow Profile 690 how the object is created, stored, queried and retrieved, but does not address the workflow management process. The Workflow Profiles address managing workflow process, which typically involves providing worklists, and reporting/monitoring the progress and completion of workitems . Within this . context, one or more content objects are generally created according to their content profile Current Workflow Profiles include: Scheduled Workflow (for acquisition), Post 695 -Processing Workflow, Reporting Workflow, Cross -enterprise Document Sharing for Imaging and Import es is an extension of Scheduled Reconciliation Workflow . Presentation of Grouped Procedur . Charge Posting is an extension of all the Workflow Profiles. Workflow The Infrastructure Profiles address general departmental issues like Radiology Audit Trail 700 Option and Access to Radiology Information. ____________________________________________________________________________ 20 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

21 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Scheduled Workflow Charge Posting Admit, order, schedule, C ollect and post timely billable procedure details Reporting Presentation of Post - manage mport I Patient Workflow Grouped Processing worklists, Information Reconciliation track status, Procedures Workflow Reconciliation Workflow perform & Manage Manage Manage individual Reconcile imported Reconcile notify worklists, track worklists, track procedure image worklists, status, data objects acquisition status, perform status, perform subsets from a and data objects for related steps, & notify & notify image multi - procedu re unknown patients diagnostic processing & acquisition for and demographics reporting steps CAD steps viewing & reporting changes Simple Image Mammo NM Image Evidence Key Image Consistent and Numeric Image Documents Notes Presentation Reports of Images Create, store, Create, store, Create, store, Create, store, Create, store, Create, store, manage, manage, manage, manage, retrieve & manage, retrieve create, manage, retrieve retrieve & use retrieve & use retrieve & use use objects for & use objects to store, & use simple Mammo image NM image hardcopy and objects to flag significant manage, diagnostic softcopy grayscale objects objects record study retrieve & images presentation states reports with evidence use optional image images Radiation Teaching File Digital Breast Exposure & Clinical Tomosynthesis Mon itoring Trial Export Create, store, Create, store, Identify, manage, retrieve & manage, retrieve & anon y mize DBT image use & use radiation store objects objects dose SR object for teaching files or clinical trials Imaging Object Change Management changes in an imaging study Consistent mechanism to communication Access to Radiology Information Consistent access to images and reports Portable Data for Imaging Media mages and reports on CD, DVD or USB Consistent access to i Cross Community Access for Imaging - Cross - Enterprise Document Sharing for Imaging Consistent sharing of images and radiology reports across Consistent query and retrieve mechanism for enterprise boundaries imaging information across communities Other Radiology Relevant Profiles: – ton, ITI RID, ITI PIX ITI ATNA Radiology Audit Trail Op Figure 2 -1: IHE Integration Profiles Dependencies among Integration Profiles 705 . Objects that serve as useful In general, IHE Integration Profiles do not operate independently input to one profile may have been produced as a result of implementing another profile. ____________________________________________________________________________ 21 Rev. 1 7.0 – Final Text 201 Copyright © 2018 : IHE International, Inc. 8-07-27

22 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Figure 2 ntegration profiles. -1 (above) provides a graphical view of the dependencies between i -1 defines the required dependencies between the i ntegration profiles in a tabular form. Table 2 In some cases a profile is str ictly dependent on one or more profiles in order to function. For example, Presentation of Grouped Procedures depends directly on the features of Scheduled 710 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, -Processing Workflow and/or Reporting Workflow) being present in order for it to have Post somethin g useful to post . Similarly, each workflow profile is of little value unless at least one 715 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. Th ere are of course other useful synergies that occur when different combinations of profiles are implemented, but those are not described in the table below. 720 Table 2- 1: Integration Profiles Dependencies Depends on Dependency Type Comment s Integration Profile Consistent Presentation of None None - Images Key Image Notes None None - NM Image None None Mammography Image None None None None Evidence Documents - Simple Image and None None - Numeric Report Supporting the image One or more of : Access to Radiology Required for Content related transactions of {Scheduled Workflow Information output Scheduled Workflow Consistent Presentation of Images, ontent counts as a c Evidence Documents, profile Key Image Notes, Simple Image and Numeric Reports} Conditionally Required Patient Information Reconciliation for the Multi Source Option - Scheduled Workflow None None Required for workflow Scheduled Workflow Presentation of Grouped - Procedures Consistent Presentation of Images Required for Content - output -Processing Workflow - Post Scheduled Workflow Required for workflow management Required for Content Supporting the image One or more of : input related transactions of {Scheduled Workflow, Scheduled Workflow Evidence Documents, NM Image} ontent counts as a c profile ____________________________________________________________________________ 22 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

23 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Integration Profile Depends on Dependency Type Comment s mage Supporting the i Required if any output is One or more of : related transactions of produced {Scheduled Workflow Scheduled Workflow Consistent Presentation of Images, counts as a c ontent Evidence Documents, profile Key Image Notes} Required for workflow Scheduled Workflow Reporting Workflow - management Supporting the image Required for Content One or more of : related transactions of input {Scheduled Workflow, Scheduled Workflow Evidence Documents, NM Image} counts as a c ontent profile. Required for Content Simple Image and Numeric Reports - input/output One or More of : Charge Posting - Required for charge trigger input {Scheduled Workflow, Post -Processing Workflow, Reporting Workflow, Import Reconciliation Workflow} Scheduled Workflow Patient Information Required for Patient Information workflow/content to Reconciliation Reconciliation is an manage extension to this profile requiring that the workitems and/or content be updated. Portable Data for Imaging None - None XDS for Imaging (XDS - Document Consumer, XDS.b (ITI) Document content I.b) Document Registry, and types and metadata Document Repository are specialized. actors from ITI XDS.b are needed to support the transactions and defined by workflows -I.b. XDS Required to manage ATNA, incl. Radiology Audit Trail Each XDS -I.b Actor shall be grouped with the Option audit trail of exported Secure Node or Secure PHI, node authentication and Application Actor. transport encryption. Scheduled Workflow Required for Workflow Import Reconciliation Support the workflow Workflow (including Scheduled related transactions of Import Option) Scheduled Workflow. Patient Demographic Patient Demographics Query [ITI] Required for information is Unscheduled Import obtained using Option Patient Demographic Query. Teaching File and Clinical None None - Trial Export ____________________________________________________________________________ 23 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

24 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ s Integration Profile Depends on Dependency Type Comment Radiation Exposure None None - Monitoring Required for access of XDS.b (ITI) Cross -Community Access documents for Imaging (XCA -I) XCA (ITI) Required for cross community access of documents -I Actor shall Each XCA Audit Trail and Node Authentication, Required to manage incl. Radiology Audit Trail Option be grouped with Secure audit trail of exported Node Actor or Secure PHI, node Application authentication and transport encryption. Each XCA -I Actor shall To ensure Consistent Time (ITI) consistency among be grouped with the Time document and Client Actor. submission set dates. Scheduled Workflow Imaging Object Change Defines how Image Required for workflow Management management Manager/Image Archive can obtain scheduled worklist in order to correct the modality worklist selection of the acquired instances. Support communication of procedure steps and storage commitment when Change Requester is grouped with Acquisition Modality, Image Manager/Image Archive or Evidence Creator. Support Image Manager to Image Manager change management if Multiple Patient Identity Resolution Option is supported. Required for Support the patient Patient Information Reconciliation information reconciliation workflow reconciliation mechanisms for the actor that is grouped with the Change Requester. Digital Breast None - None Tomosynthesis ____________________________________________________________________________ 24 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

25 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Vendor products support an Integration Profile by implementing the appropriate actor - transactions as outlined in the Integration Profile in Sections 3- 40. 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 725 -requisite is that the actor selects any one of a . In some cases, the pre those in the desired profile . For example, Post -processing depends on any -requisite given set of profiles to satisfy the pre 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. 730 Transactions (see Section 2.4) are interactions between actors that transfer the required -based messages. information through standards 2.1 Integration Profiles Overview In this document, each IHE Integration Profile is defined by: The IHE • 735 actors involved actor. • The specific set of IHE Transactions required for each IHE 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 to support all the required transactions of each Integration Profile supported. When an Integration 740 Profile depends upon another Integration Profile, all transactions required for the dependent Integration Profile have been included in the table. As mentio ned earlier, there is a class of Profiles that deal primarily with data content. Most types . Currently this means Images, Presentation of content belong to the family of Evidence Objects generated as a result of States, Key Image Notes and Evidence Documents. Evidence Objects are . These objects are used by performing procedure steps on systems in the radiology department 745 the Radiologist in the process of creating a Radiological Diagnostic Report and are managed . Evidence Docu ments represent the uninterpreted information inside the Radiology Department that 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 750 Reports Profile repre sent the interpreted information which is the primary output of the Radiology department and are available for wide distribution. Note that IHE Integration Profiles are not statements of conformance to standards, and IHE is not should continue to request that vendors provide statements of their a certifying body . Users conformance to relevant standards, such as DICOM and HL7. Standards conformance is a 755 prerequisite for vendors adopting IHE Integration Profiles. any successful integration project that IHE cannot Also note that there are critical needs for address. Successfully integrating systems still requires a project plan that minimizes disruptions -safe strategies, specific and mutually understood performance expectations, and describes fail ____________________________________________________________________________ 25 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

26 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ ed user interface requirements, clearly identified systems limitations, detailed cost -defin well objectives, plans for maintenance and support, etc. 760 Scheduled Workflow (SWF) 2.1.1 The Scheduled Workflow Integration Profile establishes the continuity and integrity of basic departmental imaging data acquired in an environment where examinations are generally being ordered. It specifies a number of transactions that maintain the consistency of patient and ordering information as well as defining the scheduling and imaging acquisition procedure steps. 765 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 are available to enable subsequent workflow steps, suc h as reporting. It may also provide central coordination of the completion of processing and reporting steps as well as notification of 770 appointments to the Order Placer. 2.1.2 Patient Information Reconciliation (PIR) Scheduled Workflow The Patient Information Reconciliation Integration Profile extends the by offering the means to match images, diagnostic reports, and other Integration Profile ample, during a evidence objects acquired for a misidentified or unidentified patient (for ex 775 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 registration) before the patient’s identity could be without a prior registration or under a generic determined. Thus images, diagnostic reports and other evidence objects can be acquired and interpreted immediately and later, when the patient’s official registration and order information is entered in 780 to the ADT, Order Placer and Order Filler Systems, this information is matched with the acquired image set, greatly simplifying these exception -handling situations. 2.1.3 Consistent Presentation of Images (CPI) The Consistent Presentation of Images Integration P rofile specifies a number of transactions that maintain the consistency of presentation for grayscale images and their presentation state 785 information (including user annotations, shutters, flip/rotate, display area, and zoom). It also defines a standard co ntrast 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. 2.1.4 Presentation of Grouped Procedures (PGP) 790 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 C T chest, acquisition with each image subset related to a different requested procedure ( e.g., 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 sake cquired image set is produced, but the of acquisition efficiency and patient comfort). A single a 795 combined use of the scheduled workflow transactions and the consistent presentation of images ____________________________________________________________________________ 26 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

27 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ allow separate viewing and interpretation of the image subsets related to each of the requested procedures. 2.1.5 Access to Radio logy Information (ARI) The Access to Radiology Information Integration Profile specifies a number of query 800 transactions providing access to radiology information, including images and related reports, in a h access is useful both to the radiology DICOM format as they were acquired or created . Suc . department and to other departments such as pathology, surgery and oncology Key Image Note (KIN) 2.1.6 The Key Image Note Integration Profile specifies transactions that allow a user to mark one or 805 y as significant by attaching to them a note managed together with the more images in a stud study . This note includes a title stating the purpose of marking the images and a user comment g field . Physicians may attach Key Image Notes to images for a variety of purposes: referrin physician access, teaching files selection, consultation with other departments, and image quality 810 issues, etc. Simple Image and Numeric Report (SINR) 2.1.7 The Simple Image and Numeric Report Integration Profile facilitates the growing use of digital dictatio n, voice recognition, and specialized reporting packages, by separating the functions of reporting into discrete actors for creation, management, storage and viewing . Separating these functions while defining transactions to exchange the reports between them enables a vendor to 815 include one or more of these functions in an actual system. 2.1.8 Basic Security (SEC) - DEPRECATED This profile has been superseded by the ITI Audit Trail and Node Authentication (ATNA) ections 2.2.1 and 10 Integration Profile and the Radiology Audit Trail Option on ATNA. See S . for details on backward compatibility of this option and the Basic Security 820 Profile 2.1.9 Charge Posting (CHG) specifies the exchange of information from the The Charge Posting Integration Profile to the Charge Processor Actor regarding Actor Department System Schedu ler/Order Filler charges associated with particular procedures, as well as communication between the ADT/Patient Registration and Charge Processor Actor s about patient demographics, accounts, 825 . The Charge Posted Transaction contains all of the required procedure rantors insurance, and gua -style data to generate a claim. Currently, these interfaces contain fixed field formatted or HL7 data. The goal of including this transaction in the Radiology is to Technical Framework standardize the Charge Posted Transaction to a Charge Processor, thus reducing system interface 830 . Additionally, the Charge installation time between clinical systems and Charge Processors Posted Transaction reduces the need of the billing system to have knowledge of the radiology . The result is that the Charge Processor will receive more complete, timely and accurate internals data. ____________________________________________________________________________ 27 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

28 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2.1.10 Post -Processing Workflow (PWF) 835 -Processing Workflow Integration Profile addresses the need to schedule, distribute and The Post track the status of typical post -Aided Detection or -processing workflow steps, such as Computer Image Processing . Worklists for each of these tasks are generated and can be queried, workitems e system performing the work to the can be selected and the resulting status returned from th system managing the work . IMPORTANT NOTE : As of June 2012, IHE introduces a new : Post 840 -Acquisition Workflow (PAWF) Trial Implementation Profile . 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 inal Text, the contents of S 10 will be ection by PAWF. When the PAWF Profile becomes F removed ations should be based on PAWF, found at . In the interim, new implement http://ihe.net/Te chnical_Frameworks/#radiology 845 . 2.1.11 Reporting Workflow (RWF) 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 for each of these tasks are generated and can be queried; workitems can be selected and the resulting 850 status returned from the system performing the work to the system managing the work. 2.1.12 Evidence Documents (ED) The Evidence Documents Profile defines interopera ble 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 855 . 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 some cases for selected items in the Evidence Document to be included in the diagnostic report. 2.1.13 Portable Data for Imaging (PDI) 860 Int The Portable Data for Imaging egration Profile specifies actors and transactions that allow users to distribute imaging related information on interchange media. The intent of this profile is or to provide reliable interchange of evidence objects and diagnostic reports for import, display as the print by a receiving actor . The CD format with uncompressed content was chosen 865 , JPEG and JPEG 2000 lossless and baseline. Options for the support of DVD media and USB media are also defined. lossy compression on CD, DVD and USB ) NM Image (NMI 2.1.14 Th e 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 the lso how result screens, basic display capabilities Image Displays are expected to provide, and a 870 ____________________________________________________________________________ 28 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

29 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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. Teaching File and Clinical Trial Export (TCE) 2.1.15 Teaching File and Clinical Trial Export Profile addresses the need to select DICOM The instances, series or studies (which may contain images, key image notes, reports, evidence 875 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 to 880 pseudonymous values, export of additional teaching file information, and delaying export for a variety of reasons. -I.b) -Enterprise Document Sharing for Imaging ( Cross 2.1.16 XDS The Cross -I.b) Integration Profile specifies -Enterprise Document Sharing for Imaging (XDS 885 actors and transactions that allow users to share imaging information across enterprises. This profile depends on t -Enterprise Document Sharing (XDS.b) he IHE IT Infrastructure Cross Profile . Cross -Enterprise Document Sharing for Imaging (XDS -I.b) defines the information to be shared such as sets of DICOM instances (including images, evidence documents, and presentation states), diagnostic imaging reports provided in a ready -for -display format. -I.b Profile depends on and extends the IT Infrastructure XDS.b Profile including Since the XDS 890 the use of terms defined in XDS (e.g., XDS Affinity Domain, submission set, etc.) the reader of -I.b is expected to have read and understood the XDS Profile. XDS Mammography Image (MAMMO) 2.1.17 The Mammography Image Profile specifies how DICOM Mammography images and evidence odalities transfer Full 895 objects are created, exchanged and used. It describes how Acquisition M 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 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) 900 This section intentionally, temporarily left blank. 2.1.19 Import Reconciliation Workflow (IRWF) The Import Reconciliation Workflow Integration Profile (IRWF) specifies how data Importers obtain local demographics, coerce patient and procedure attribute values in the imported data and report progress/status of the importation process. The Profile complements the Scheduled 905 Workflow Profile by using the existing wor kflow mechanisms for notification and storage of ____________________________________________________________________________ 29 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

30 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ As of June 2012, IHE introduces an IMPORTANT NOTE: . imported Evidence Objects updated Import Reconciliation Profile (IRWF.b) for Trial Implementation. In addition to the original use cases, several new use cases are addressed, and the underlying mechanisms are 910 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, the In the interim, new implementations 21 will be removed. ection contents of S should be based on IRWF.b, found at http://www.ihe.net/Technical_Frameworks/#radiology . Radiation Exposure Monitoring (REM) 2.1.20 915 The Radiation Exposure Monitoring Integration Profile specifies communications between systems generating reports of irradiation events (generally acquisition modalities and l dose workstations) and systems which receive, store, or process those reports (generally loca . It defines how information management systems and/or national/regional dose registries) -ray dose objects are created, stored, queried, DICOM SR objects for CT and projection X retrieved, de- identified, and may be processed and displayed. 920 2.1.21 Mammograph y Acquisition Workflow (MAWF) This section intentionally, temporarily left blank. 2.1.22 MR Diffusion Imaging (DIFF) This section intentionally, temporarily left blank. CT/MR Perfusion Imaging with Contrast (PERF) 2.1.23 925 This section intentionally, temporarily left blan k. Basic Image Review (BIR) 2.1.24 This section intentionally, temporarily left blank. 2.1.25 Chest X -Ray CAD Display (CXCAD) 930 This section intentionally, temporarily left blank. Imaging Object Change Management (IOCM) 2.1.26 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 935 ity or patient safety reasons, (2) correction of incorrect include (1) object rejection due to qual 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. ____________________________________________________________________________ 30 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

31 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ for Imaging (XCA -I) -Community Access 2.1.27 Cross The Cross -I) Integration Profile specifies actors and -Community Access for Imaging (XCA transactions to query and retrieve patient 940 -relevant medical imaging data being held by other communities. Within a community, a group of facilitie s/enterprises shares clinical information via an established 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. The XCA -I Profile extends the IT Infra structure XCA Profile . XCA provides access to 945 I provides access to the imaging objects Diagnostic reports and Imaging Manifests . XCA- -I is expected to have read and understood the . The reader of XCA referenced in the Manifests ning of terms such as Community, homeCommunityId, etc. XCA Profile, including the mea Post Acquisition Workflow (PAWF) 2.1.28 950 This section intentionally, temporarily left blank. -I) 2.1.29 Cross -Enterprise Reliable Document Interchange – Imaging (XDR This section intentionally, temporarily left blank. Stereotactic Mammography Image (SMI) 2.1.30 This section intentionally, temporarily left blank. Management of Radiology Report Templates (MRRT) 955 2.1.31 This section intentionally, temporarily left blank. 2.1.32 Scheduled Workflow.b (SWF.b) ly left blank. This section intentionally, temporari 2.1.33 Invoke Image Display (IID) This section intentionally, temporarily left blank. 960 Left Blank 2.1.34 Intentionally This section is intentionally left blank. 2.1.35 Digital Breast Tomosynthesis (DBT) BT) Profile specifies the creation, exchange and use of The Digital Breast Tomosynthesis (D 965 DBT images. It defines basic display capabilities that Image Displays are expected to provide, especially simultaneous review of DBT and conventional 2D mammography images (FFDM). The Digital Breast Tomosynthesis Profile is designed to provide faithful storage and retrieval of DBT images. Furthermore, sufficient display functionality to allow adequate review of current ____________________________________________________________________________ 31 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

32 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ and prior studies consisting of DBT and/or conventional 2D mammography images is de fined. 970 The support for CAD is out of the scope for this profile. -based Image Capture (WIC) Web 2.1.36 This section intentionally, temporarily left blank. 2.1.37 Clinical Decision Support – Order Accountable Tracking (CDS -OAT) This section intentionally, temporarily left blank. 2.1.38 Radiation Exposure Monitoring – Nuclear Medicine (REM -NM) 975 This section intentionally, temporarily left blank. 2.1.39 -Enterprise Remote Read Workflow Definition (XRR -WD) Cross This section intentionally, temporarily left blank. -based Image Access (WIA) Web 2.1.40 980 This section intentionally, temporarily left blank. 2.1.41 Standardized Operational Log Events (SOLE) This section intentionally, temporarily left blank. 2.1.42 ) Management of Acquisition Protocols (MAP This section intentionally, temporarily left blank. 985 2.1.43 Results Distribution (RD) This section intentionally, temporarily left blank. 2.1.44 Intentionally Left Blank This section is intentionally left blank. -based Imaging Workflow (EBIW) 2.1.45 Encounter This section intentionally, temporarily left blank. 990 2.2 Options to other Domains ’ Profiles 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 (ATNA) Profile -ATNA Profile provides security and privacy mechanisms like a . The ITI common audit trail and authentication for distributed applications. Refer to the ATNA Profile 995 (ITI TF -1: 9) for the full definition of this profile. ____________________________________________________________________________ 32 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

33 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The Radiology Audit Trail Option deals largely with the details of the Record Audit Event transaction 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 1000 the ATNA Profile . Actor Descriptions 2.3 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 the actors defined by IHE and referenced throughout the rest of this document. erms used as modifiers for the actor names are not used 1005 It is acknowledged that some of the t consistently (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 wou ld result from renaming many of the existing actors. Therefore the actor names will remain as defined below. A system that acquires and creates medical images while a patient is 1010 Acquisition Modality – present, e.g., Medicine camera. A modality may a Computed Tomography scanner or Nuclear also create other evidence objects such as Grayscale Softcopy Presentation States for the consistent viewing of images or Evidence Documents containing measurements. A modality may s. also create and store Dose SR A system responsible for adding and/or updating patient t Registration – ADT Patien 1015 demographic and encounter information. In particular, it registers a new patient with the Order Placer and Department System. – Receives the posted charges and serves as a component of the financial Charge Processor system . Further definition of this actor is beyond current IHE scope. – A system that communicates changes to an Image Manager / Archive, 1020 Change Requester indicating that certain imaging instances should be deleted. In addition, it may also send new versions of these imaging instances containing corrected information. Department System Sche duler/Order Filler – A department -based information system (for instance, Radiology or Laboratory) that provides functions related to the management of orders 1025 received from external systems or through the department system’s user interface. Upon a defined workflow action, makes procedures available for charge posting . The action/event that actually causes charges to post is defined by the actor. Primary description for this actor can be found in ITI TF -1: Appendix A. The required Display – capabilities for its use within the Radiology Technical Framework add the ability to view "web- viewable" diagnostic and therapeutic imaging information on interchange media. 1030 queries a Document Registry Actor for The Document Consumer Actor Document Consumer – ting certain criteria, and retrieves selected documents from one or more documents mee Actor s. Document Repository The Document Registry Actor -data about each registered maintains meta Document Registry – . This includes a link to the Document Repository where the actual document in a document entry 1035 document is stored. The Document Registry responds to queries from Document Consumer ____________________________________________________________________________ 33 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

34 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ . It also enforces some healthcare specific s about documents meeting specific criteria Actor technical policies at the time of document registration. Document Repository – The Document Repository persistently stores documents . It Actor 1040 assigns and maintains a unique identifier for each document, to allow Document Consumers to retrieve them. l handling of irradiation events, – Responsible for supplementa Dose Information Consumer , display, analysis, or further processing ). e.g. generally on an individual basis ( Dose Information Reporter – Responsible for the aggregation, analysis, reporting and business -identify y include meeting facility obligations to de logic related to irradiation events, which ma 1045 and submit data to various dose registries. – Collates information about irradiation events from a number of facilities, Dose Registry generally to perform analysis. tem that receives Structured Report Export Transactions Enterprise Report Repository – A sys from the Report Manager and stores them. 1050 A system that creates additional evidence objects such as images, Evidence Creator – mits them to an presentation states, Key Image Notes, and/or Evidence Documents and trans Image Archive. It also makes requests for storage commitment to the Image Manager for the data previously transmitted. It may also retrieve worklist entries for post -processing steps from the 1055 Post -Processing Manager and provide notification of completion of the step, allowing the enterprise to track the status of post -processing work. Export Manager – A system that can de- identify and pseudonymize the attributes, and optionally 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 rt, for a specific purpose, with a specific disposition, optionally with the inclusion of 1060 for expo 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. 1065 – A system that provides long term storage of evidence objects such as images, Image Archive presentation states, Key Image Notes , Evidence Documents and Dose SR . A part of a s ystem that can access imaging evidence objects (images, Image Display – Presentation States, Key Image Notes, Evidence Documents) through network query/retrieve or reading interchange media and allow the user to view these objects. unctions related to safe storage and management of A system that provides f 1070 Image Manager – evidence objects. It supplies availability information for those objects to the Department System It also accepts/commits dose data and supports query/retrieve. Scheduler. maging Document Consumer Actor Imaging Document Consumer – parses an imaging The I from the Document manifest document that is retrieved by the Document Consumer Actor 1075 , and retrieves DICOM SOP Instances referenced within that manifest from the Repository Actor Imaging Document Source Actor . ____________________________________________________________________________ 34 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

35 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Imaging Document Source – The Imaging Document Source Actor is the producer and - publisher of imaging documents . It is responsible for providing imaging documents and meta data to the Document Repository Actor , which subsequently registers the imaging doc uments with the Document Registry Actor . It also supports the retrieval services for DICOM SOP 1080 Instances referenced in a published imaging manifest document. Importer – A system that imports evidence objects such as images, presentation states, Key Image N otes or Evidence Documents from hardcopy or digital media. A system that maintains unique enterprise Master Patient Index (MPI) – -wide identifiers for patients 1085 . Note that this is not supported in the current scope of the IHE Technical Framework Order Place r – A hospital or enterprise -wide system that generates orders for various departments and distributes those orders to the correct department. A repository of patient information that can be searched on Patient Demographics Supplier – demographic related f ields . This actor is defined in the ITI Technical Framework. Performed Procedure Step Manager – 1090 -distributes the Modality Performed A system that re Procedure Step information from the Acquisition Modality or Evidence Creator to the Department System Schedu ler/Order Filler, Image Manager and Report Manager. This actor assembles the content of the media and writes it to the Portable Media Creator – physical medium. 1095 Portable Media Importer – This actor reads the DICOM information contained on the media, and a llows the user to select DICOM instances, reconcile key patient and study attributes, and store 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 -processing worklist items worklist management . This involves the ability to schedule post 1100 -processing worklist clients, and (scheduled procedure steps), provide worklist items to post -processing teps as received from post update the status of scheduled and performed procedure s worklist clients. Print Composer – A system that generates DICOM print requests to the Print Server . Print Up Tables requests include presentation state information in the form of Presentation Look- It may also read the DICOM information contained on interchange media. (Presentation LUTs). 1105 A system that accepts and processes DICOM print requests as a DICOM Print Print Server – SCP and performs image rendering on hardcopy media. The system must support pixel rendering according to the DICOM Grayscale Standard Display Function. A system that can receive exported instances over the network, whose behavior is Receiver – 1110 otherwise unspecified unless grouped with other actors. A system that generates and transmits draft (and optionally, final) diagnostic Report Creator – 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 the step, allowing the enterprise to track the status of an awaited report. A system that pr 1115 -term storage of DICOM ovides management and short Report Manager – 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. ____________________________________________________________________________ 35 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

36 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ system that can access reports through network query/retrieve or Report Reader – A part of a reading interchange media and allow the user to view reports presented as DICOM Structured 1120 Reporting Objects. A system that provides long Report Repository – -term storage of diagnostic reports and their retrieval as DICOM Structured Reporting Objects. Initiating Imaging Gateway – The Initiating Imaging Gateway Actor proxies Imaging Set Retrieve requests from an Image Document Consumer to a Responding Imaging Document Gateway with a Cross Gateway Retrieve Imaging Document Set transaction. 1125 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. Transaction Descriptions 2.4 Transactions are interactions between actors that transfer the required information through 1130 standards -based messages. The following are the transactions defined by IHE and referenced throughout the rest of this document. The ADT system registers and/or admits a patient and forwards the Patient Registration – 1. information to other information systems. 1135 – The Order Placer informs the Order Filler of the initiation or 2. Placer Order Management cancellation of an order. The Placer/Filler Order Management transaction will sometimes be Cancel” when an existing -New” when a new order is being initiated, or as “- referred to as “ order is canceled. Filler Order Man agement – The Order Filler informs the Order Placer of the initiation, 3. cancellation, or change in the status of an order. The Placer/Filler Order Management 1140 -New” when a new order is being initiated, or transaction will sometimes be referred to as “ as “- Ca ncel” 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. Query Modality Worklist – iltering) a list of In response to a query (with optional f 5. 1145 Scheduled Procedure Steps with selected demographic and order information is returned. An Acquisition Modality notifies the Performed Modality Procedure Step In Progress – 6. 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. 1150 Modality Procedure Step Completed – An Acquisition Modality notifies the Performed Procedure Step Manager of the completion of a Procedure Step and the PPS Manager the Department System, Image Manager and the Report Manager. informs Modality Images Stored – An Acquisition Modality sends acquired or generated images to 8. the Image Archive. Modality Presentation State Stored – 9. 1155 An Acquisition Modality requests that the Image Arc hive store a Grayscale Softcopy Presentation State (GSPS) for the acquired or generated images. ____________________________________________________________________________ 36 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

37 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Request and receive from an actor which has stored DICOM Storage Commitment – 10. objects (such as images or Evidence Documents) confirmation of receipt and ownership for 1160 the specified objects, generally to allow the requesting actor to safely delete those objects. Images Availability Query – The Department System Scheduler/Order Filler and Report 11. Manager asks the Image Manager if a particular image or image series is available. The ADT Patient Registration System informs the Order Placer and the Patient Update – 12. Department System Scheduler/Order Filler of new information for a particular patient. The 1165 Department System Scheduler may then further inform the Image Mana ger and Report Manager. 13. The Department System Scheduler/Order Filler sends the Image Procedure Update – Manager and Report Manager updated order or procedure information. Query Images – 14. An Image Display queries the Image Archive for a list of entries senting images by patient, study, series, or instance. 1170 repre An Image Display queries the Image Archive for a list of Query Presentation States – 15. entries representing image Grayscale Softcopy Presentation States (GSPS) by patient, study, series, or instance. Retrieve Images – 16. An Image Display or an Imaging Document Consumer requests and 1175 retrieves a particular image or set of images from the Image Archive or an Imaging Document Source, respectively. Document Consumer An Image Display or an Imaging Retrieve Presentation States – 17. requests and retrieves the Grayscale Softcopy Presentation State (GSPS) information for a particular image or image set. – 18. Creator Images Stored An Evidence Creator sends new images to the Image Archive. 1180 An Evidence Creator requests that the Image Archive 19. Creator Presentation State Stored – 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 St ep and the PPS Manager informs the Department System and Image Manager. 1185 Creator Procedure Step Completed – An Evidence Creator notifies the Performed 21. Procedure Step Manager of the completion of a Procedure Step and the PPS Manager stem and Image Manager. informs the Department Sy 22. Intentionally unassigned 23. Print Request with Presentation LUT – A Print Composer sends a print request to the Print 1190 Server specifying Presentation LUT information. 24. ic report to the Report A Report Creator sends a draft or final diagnost Report Submission – Manager. 25. Report Issuing – A Report Manager sends a draft or final diagnostic report to the Report 1195 Repository. Query Reports – A Report Reader provides a set of criteria to select the list of entries 26. y patient, study, series, or instance known by the Report representing diagnostic reports b Repository or External Report Repository Access. A Report Reader or an Imaging Document Consumer requests and 27. Retrieve Reports – port Repository Access retrieves a diagnostic report from the Report Repository, External Re 1200 or an Imaging Document Source. ____________________________________________________________________________ 37 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

38 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 28. Structured Report Export – A Report Manager composes an HL7 Result transaction by mapping from DICOM SR and transmits it to the Enterprise Report Repository for storage. Key Image Note Stored sition Modality or an Evidence Creator sends a Key 29. – An Acqui Image Note to the Image Archive 1205 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. – An Image Display or an Imaging Document Consumer requests Image Note Retrieve Key 31. and retrieves a Key Image Note from the Image Archive or an Imaging Document Source, 1210 respectively. 32. Authenticate Node [DEPRECATED] – This transaction is identical to, and has been 19] transaction as part of the ITI Audit Trail and supers eded by the Authenticate Node [ITI- Node Authentication Profile (ITI TF -1: 3.19). – This transaction identical to, and has been superseded 33. Maintain Time [DEPRECATED] by the Maintain Time as part of the ITI Consistent Time Profile (ITI TF -2a: 3.1). 1215 – This transaction has been superseded by the [DEPRECATED] 34. Record Audit Event - Record Audit Event as part of the ITI Audit Trail and Node Authentication Profile (ITI TF 2a: 3.20). 35. ystem Scheduler/Order Filler sends descriptions of - The Department S Charge Posted potential procedure and material charges. 1220 36. Account Management – The ADT Patient Registration Actor informs the Charge Processor about creation, modification and ending of the patient’s account. – Based on a query from a worklist client (Evidence 37. Query Post -Processing Worklist Creator), a worklist is generated by the worklist manager (Post -Processing Manager) containing either Post -Processing or Computer Aided Detection (CAD) workitems that 1225 satisfy the quer y. Workitems are returned in the form of a list of General Purpose Scheduled Procedure Steps. Workitem Claimed 38. – A worklist client (Evidence Creator, Report Creator) notifies the ed the worklist provider (Post -Processing Manager, Report Manager) that it has claim 1230 workitem. – A worklist client (Evidence Creator, Report Creator) notifies 39. Workitem PPS In Progress the worklist provider (Post -Processing Manager, Report Manager) that it has started work (i.e., created a General Purpose Performed Procedure Step). Workitem PPS Completed – A worklist client (Evidence Creator, Report Creator) notifies 40. -Processing Manager, Report Manager) of the completion of a the worklist provider (Post 1235 General Purpose Performed Procedure Step. 41. Evidence Creator, Report Creator) notifies the Workitem Completed – A worklist client ( -Processing Manager, Report Manager) that it has finished the worklist provider (Post i.e., completed a General Purpose Scheduled Procedure Step). workitem ( 1240 – The worklist provider informs other interested actors of Performed Work Status Update 42. going status and completion of performed work. the on- 43. – A source actor of Evidence Documents (Acquisition Modality Evidence Document Stored or Evidence Creator) sends recorded, measured or derived diagnostic evidence in t he form of a DICOM Structured Report to the Image Archive. ____________________________________________________________________________ 38 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

39 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1245 – A user of Evidence Documents (Image Display, Report Query Evidence Documents 44. Creator or Report Reader) queries the Image Archive for a list of entries representing Evidence Documents. – A user of Evidence Documents (Image Display, Report Retrieve Evidence Documents 45. Creator or Report Reader) or an Imaging Document Consumer requests and retrieves an 1250 Evidence Document from the Image Archive or an Imaging Document Source, respectively. ry Reporting Worklist Que 46. – Based on a query from a Report Creator worklist client, a worklist 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. Distribute Imaging Information on Media 1255 – A source actor (Portable Media Creator) 47. . The writes image data, other evidence objects and reports onto a piece of interchange media edia Importer, Image Display, media is physically transported to another actor (Portable M Report Reader, Display or Print Composer) which then imports, displays or prints the . The media can also be provided to a patient or a referring evidence objects and reports 1260 -based viewing. physician for web Appointment Notific 48. – The Department System Scheduler/Order Filler sends the Order ation Placer Actor the date and time of the appointment(s) related to one or more Scheduled Procedure Step(s). 49. – The Image Manager/Image Archive notifies interested Instance Availability Notification 1265 -Processing workflow actors (such as the Department System Scheduler/Order Filler, Post 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. An Export Selector sends to an Export Manager an instance of a 51. Store Export Selection – 1270 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 be 1275 exported. 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 – rt of the Cross MTOM/XOP Transaction (RAD TF -3: 4.68) as pa -Enterprise Document 1280 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]. Int 1285 entionally, temporarily Left Blank 56. Intentionally, temporarily Left Blank 57. 58. Intentionally, temporarily Left Blank ____________________________________________________________________________ 39 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

40 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 59. Import Procedure Step In Progress – The Performed Procedure Step Manager receives progress notification of an importation Procedure Step and in t urn notifies the Order Filler, 1290 Image Manager and the Report Manager. – The Performed Procedure Step Manager receives 60. Import Procedure Step Completed completion notification of an importation Procedure Step and in turn notifies the Order Filler, Image Mana ger and the Report Manager. Imported Objects Stored – A system importing DICOM Objects or digitized hardcopy 61. sends imported DICOM Composite Objects to the Image Archive. 1295 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. 1300 Query Dose Information – Obtain a list of references to Dose objects matching a given filter. 65. Retrieve Dose Information – Obtain specific Dose o bjects containing descriptions of Irradiation Events. Create and send a manifest referencing images that are rejected for Rejection Note Stored 66. – quality or patient safety reasons, rejected for incorrect modality worklist selection, or deleted 1305 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 Provide and Register Imaging Document Set – MTOM/XOP – An Imaging Document 68. Source Actor uses the Provide and Register Imaging Document Set Transaction to submit 1310 ITI documents with associated metadata to a Document Repository. [RAD -68] specializes [ - 41]. 69. Retrieve Imaging Document Set – An Imaging Document Consumer Actor uses this Transaction to issue a web service request to retrieve a set of DICOM instances. [RAD -69] 1315 -43]. ITI specializes [ 70. Intentionally, temporarily Left Blank 71. Intentionally, temporarily Left Blank 72. Intentionally, temporarily Left Blank 73. Intentionally, temporarily Left Blank – A Change Requester send new updated instances with 74. Replacement Instances Stored 1320 corrected header information to an Image Manager/Image Archive. Cross Gateway Retrieve Imaging Document Set 75. Initiating Imaging Gateway sends a – An request 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 product 1325 . The decisions cover four levels of optionality: implementations • For a system, select which actors it will incorporate. (Multiple actors per system is acceptable). ____________________________________________________________________________ 40 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

41 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • For each actor, select which Integration Profiles it will participate in. 1330 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 the ections 3 Integration Profile Tables in S ) and later. • Finally, for each transaction, select which optional features will be supported. (Ref er to the transaction descriptions in RAD TF Volume 2 and Volume 3) ctors, IHE Integration Profiles, 1335 Implementers should provide a statement describing which IHE a optional transactions and optional features are incorporated in a given product. The recommen ded 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 the e or more additional actors: implementation of on 1340 • 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 • gration Profiles shall be grouped with a Performed Procedure Step Manager. The Inte grouped Performed Procedure Step Manager shall be capable of being disabled via 1345 configuration. • 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 1350 Performed Procedure Step Manager shall be capable of being disabled via configuration. • 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 participat -Processing Workflow shall be grouped with ing in Post • 1355 an 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 Integ ration 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 grouped 1360 with either an Image Manager or a Department System Scheduler. The Portable Media Importer in the Portable Data for Imaging Profile • shall be grouped with at least one of the following actors from one or more Radiology profiles in order to perform import of the supported evidence objects and/or Diagnostic Reports: Evidence Creator (Evidence Documents) • 1365 ____________________________________________________________________________ 41 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

42 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 • 1370 (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 retrieving from a Document Repository as defined in the Document Registry and 1375 ITI XDS . .b Profile is generic in terms of Profile The Importer Actor in the Import Reconciliation Workflow • . It may not defining a specific transport mechanism for the Evidence Objects it imports be ne cessary for the Importer to be grouped with additional Actors to support specific transport mechanisms . For example, to support import from PDI Media, the Importer 1380 Actor must be grouped with the Portable Media Importer Actor. • The Change Requester is generi c in terms of not defining a specific mechanism for obtaining the original instances that it requests changes to. It shall be grouped with at least one of the following actors in order to obtain the original instances: 1385 • Evidence Creator • Acquisition Modality Image Manager/Image Archive • When multiple actors are grouped in a single product implementation, all transactions originating or 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 1390 defined between actors in the required groupings defined above. For example, the Procedure Step In Progress/Completed transaction does not need to be supported between the Performed Procedure Step Manager and the Image Manager when these are grouped together in a single system. On the other hand, the Report Submission Transaction 1395 must be supported even by an implementation that groups the Report Creator and the Report Manager. ore actors are grouped together, internal communication between actors is When two or m assumed to be sufficient to allow the necessary information flow to support their functionality; chive to for example, the Image Manager provides necessary information updates to the Image Ar support its Query/Retrieve functionality. The exact mechanisms of such internal communication 1400 are outside the scope of the IHE Technical Framework. ____________________________________________________________________________ 42 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

43 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The following examples describe which actor ’s typical systems might be expected to support. not intended to be a requirement, but rather to provide some examples to aid This is understanding. • 1405 A modality system, such as an MRI scanner and console or Ultrasound system might typically include an Acquisition Modality Actor and a Print Composer Actor . • -processing workstation or advanced review ging workstation, such as a post An ima and a station might typically include an Image Display Actor , an Evidence Creator Actor . Print Composer Actor 1410 A HIS registration and order entry system might typically include the ADT Patient • . and an Order Placer Actor Registration Actor • A departmental RIS system might typically include a Department System Scheduler , an Order Filler Actor , a Performed Procedure Step Manager Actor , a Report Actor Actor Manager and a Report Reader Act or. An Ultrasound system that generates echo report measurements would likely include an • 1415 that supports both the Scheduled Workflow Profiles and the Actor Acquisition Modality Evidence Documents Profile. When an implementation has an actor supporting multiple integration profiles, the actor is required to support logical cross -behaviors/ transactions . For example, if an Evidence Creator 1420 -Processing Workflow and Evidence Documents Profiles, then the actor must supports the Post generate PPS messages when creat ing evidence documents . If an Image Display supports the Simple Image and Numeric Reports and Consistent Presentation of Images Profiles, then the actor must make use of any GSPS referenced by the Simple Image and Numeric Report when rendering the relevant images. 1425 If an implementation supports the Consistent Presentation of Images Integration Profile with both 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, the combined actors must perform the image data manipulations necessary to match the presentation of the Hardcopy with the Softcopy presentations. 1430 Manager, If an implementation includes a Print Composer in combination with an Image 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. ____________________________________________________________________________ 43 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

44 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1435 Scheduled Workflow (SWF) 3 establishes the continuity and integrity of basic Scheduled Workflow Integration Profile The departmental imaging data. It specifies a number of transactions that maintain the consistency of patient 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 other evidence objects associated with a particular performed procedure step have been stored 1440 (archived) and are available to enable subsequent workflow steps, such as reporting. It may also as provide central coordination of the completion of processing and reporting steps as well notification of appointments to the Order Placer. ____________________________________________________________________________ 44 8-07-27 Rev. 1 7.0 : IHE International, Inc. Copyright © 2018 – Final Text 201

45 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. . 1445 -1, not all of the “optional” transactions listed in Table Note : In an attempt to simplify Figure 3.1 -1 are shown in the 3.1 diagram. ADT Pt. Registration [RAD - 1] ↓ Pt. Registration [RAD ↓ - 1] 2] - Placer Order Management [RAD ← - ↓ 12] 12: Patient Update [RAD 12] - Patient Update [RAD ↓ - → Filler Order Management [RAD 3] 48] Appointment Notification [RAD - → Order Placer DSS/ Order Filler ↓ Procedure Scheduled [RAD - 4] - 11] ↑ Image Availability Query [RAD Procedure Updated [RAD 13] - ↓ ↑ Performed Work Status Update [RAD - 42] 6] ↑ Modality PS in Progress [RAD - ↓ 42] - Performed Work Status Update [RAD - ↑ 7] Modality PS Completed [RAD 49] - Instance Availability Notification [RAD ↑ 20] ↑ Creator PS in Progres s [RAD - 21] Creator PS Completed [RAD ↑ - or Evidence Creat Image Display ↓ Creator PS in Progress [RAD - 20] 21] ↓ - Creator PS Completed [RAD Storage Creator Images ↓ Commitment [RAD ↓ 10] - Performed - Stored [RAD 18] ↓ Query Images Procedure 14] - [RAD Step Manager Retrieve Images ↓ [RAD 16] - Image Image Manager Archive - 6] Modality PS in Progress [RAD → 7] - Modality PS Completed [RAD → → Creator PS in Progress [RAD - 20] 21] → - Creator PS Completed [RAD Storage Modality Image Stored [RAD 8] ↑ - ↑ - Commitment [RAD 10] 6] - Modality PS in Progress [RAD ← 7] - Modality PS Completed [RAD ← Acquisition Modality Query Modality Worklist [RAD 5] ← - 1: Scheduled Workflow Diagram Figure 3.1- 1450 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 to listed in Section 3.2. support is 1455 ____________________________________________________________________________ 45 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc. Rev. 1

46 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Actors and Transactions Table 3.1- 1: Scheduled Workflow - TF Transactions Optionality Actors Reference ADT Patient Registration -1] R RAD TF -2: 4.1 Patient Registration [RAD -12] R RAD TF -2: Patient Update [RAD 4.12 Order Placer Patient Registration [RAD -1] R RAD TF -2: 4.1 -12] RAD TF R Patient Update [RAD -2: 4.12 Placer Order Management [RAD R RAD TF -2: 4.2 -2] 4.3 -2: Filler Order Management [RAD -3] R RAD TF -48] O RAD TF -3: 4.48 Appointment Notification [RAD Department System Patient Registration [RAD -1] R RAD TF -2: 4.1 Scheduler/ RAD TF 4.12 -2: Patient Update [RAD -12] R Order Filler Placer Order Management [RAD -2] R RAD TF -2: 4.2 Filler Order Management [RAD -3] R RAD TF -2: 4.3 Procedure Scheduled [RAD -4] R RAD TF -2: 4.4 4.5 -2: Query Modality Worklist [RAD -5] R RAD TF RAD TF R Modality Procedure Step In Progress 4.6 -2: [RAD -6] R RAD TF -2: 4.7 Modality Procedure Step Completed [RAD -7] -11] O RAD TF Images Availability Query [RAD 4.11 -2: Procedure Updated [RAD -13] R RAD TF -2: 4.13 Creator Procedure Step in Progress 4.20 -2: R RAD TF -20] [RAD Creator Procedure Step Completed 4.21 R RAD TF -2: [RAD -21] - Performed Work Status Update [RAD O RAD TF -3: 4.42 42] (as the Receiver, see Note 1)) Appointment Notification [RAD -48] O RAD TF -3: 4.48 - 4.49 Instance Availability Notification [RAD O -3: RAD TF 49] Query Modality Worklist [RAD -5] R -2: 4.5 Acquisition Modality RAD TF RAD TF 4.6 R Modality Procedure Step In Progress -2: [RAD -6] Procedure Step Completed 4.7 Modality R RAD TF -2: -7] [RAD Modality Images Stored [RAD -8] R RAD TF -2: 4.8 Storage Commitment [RAD R RAD TF -2: 4.10 -10] Image Manager/ 4.4 Procedure Scheduled [RAD -4] R RAD TF -2: Image Archive -2: 4.6 Modality Procedure Step In Progress R RAD TF -6] [RAD R Modality Procedure Step Completed 4.7 -2: RAD TF [RAD -7] ____________________________________________________________________________ 46 Rev. 1 : IHE International, Inc. 7.0 – Final Text 201 8-07-27 Copyright © 2018

47 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Optionality Actors Transactions Reference -8] R RAD TF -2: 4.8 Modality Images Stored [RAD -10] R Storage Commitment [RAD -2: 4.10 RAD TF Images Availability Query [RAD R RAD TF -2: 4.11 -11] Procedure -13] R RAD TF -2: 4.13 Updated [RAD 4.14 Query Images [RAD -14] R RAD TF -2: Retrieve Images [RAD R RAD TF -2: 4.16 -16] Creator Images Stored [RAD -18] R RAD TF -2: 4.18 Creator Procedure Step in Progress RAD TF 4.20 -2: R [RAD -20] Creator Procedure Step Completed 4.21 -2: R RAD TF [RAD -21] 4.42 RAD TF O -3: - Performed Work Status Update [RAD 42] (as the Receiver, see Note 1) - Instance Availability Notification [RAD 4.49 -3: RAD TF O 49] 4.6 Modality Procedure Step In Progress Performed Procedure Step -2: R RAD TF -6] [RAD Manager Modality Procedure Step Completed RAD TF -2: 4.7 R [RAD -7] Creator Procedure Step in Progress R RAD TF -2: 4.20 [RAD -20] Creator Procedure Step Completed R RAD TF -2: 4.21 [RAD -21] 4.14 Image Display Query Images [RAD -14] R RAD TF -2: -16] 4.16 -2: RAD TF Retrieve Images [RAD R R 4.18 Creator Images Stored [RAD -18] RAD TF -2: Evidence Creator Creator Procedure Step in Progress -2: RAD TF O 4.20 -20] [RAD Creator Procedure Step Completed 4.21 -2: RAD TF O [RAD -21] 4.10 -2: Storage Commitment [RAD -10] R RAD TF 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 manage d by other systems -3: 4.42). (see RAD TF -requisites for this profile. 2-1 for other profiles that may be pre Refer to Table 1460 Scheduled Workflow Integration Profile Options 3.2 1 along with 3.2- Options that may be selected for this Integration Profile are listed in the Table the Actors to which they apply . Dependencies between options when applicable are specified in notes. ____________________________________________________________________________ 47 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

48 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 3.2- 1: Scheduled Workflow - Actors and Options 1465 Actor Option TF Reference ADT Patient Registration HL7 v2.5.1 RAD TF -1: 3.2.1 4.1 -2: RAD TF RAD TF -2: 4.12 Departmental Appointment Notification Order Placer RAD TF -3: 4.48 HL7 v2.5.1 RAD TF -1: 3.2.1 RAD TF -1: 3.3.3.2 4.1 -2: RAD TF RAD TF 4.2 -2: RAD TF -2: 4.3 RAD TF -2 : 4 .12 DSS/Order Filler Image Availability RAD TF -2: 4.11 RAD TF Departmental Appointment Notification -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 -1: RAD TF HL7 v2.5.1 3.2.1 RAD TF 3.3.3.2 -1: 4.1 -2: RAD TF RAD TF 4.2 -2: RAD TF -2: 4.3 -2: 4.4 RAD TF -2: 4.12 RAD TF RAD TF -2: 4.13 Patient Based Worklist Query ( Note 1) -2: RAD TF Acquisition Modality 4.5 Broad Worklist Query (N RAD TF -2: 4.5 ote 1) Assisted Acquisition Protocol Setting RAD TF -2: 4.6 PPS Exception Management RAD TF -2: 4.7 RAD TF Modality Group Case ( Note 2) -2:.4.6 Billing and Material Management -2:4.7 RAD TF -3:4.49 Availability of PPS -Referenced Instances RAD TF Image Manager/ Image Archive PPS Exception Management RAD TF -2:4.7 Performed Work Status Update - Receive RAD TF -2:4.42 RAD TF -1:3.2.1 HL7 v2.5.1 -2:4.4 RAD TF RAD TF -2:4.13 Image Display No options defined - Performed Procedure Step Manager No options defined - -2:4.20 RAD TF Evidence Creator Creator Performed Procedure Step RAD TF -2:4.21 PPS Exception Management ( -2:4.21 RAD TF Note 3) Note 1: At least one of these two options is required. Both may be supported. ____________________________________________________________________________ 48 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

49 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ is required to support all three grouping , it Note 2: When a modality claims support for the Modality Group Case Option -2: 4.6.4.1.2.3.4. scenarios described in RAD TF Note 3: An Evidence Creator claiming the PPS Exception Management Option shall also support the Creator Performed Procedure Step Option. 1470 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 ). ppendix D documented by a reference in the IHE Integration Statement (see A 3.2.1 HL7 v2.5.1 Option The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in the 1475 1. The actor shall permit configuration for each system that transactions referenced in Table 3.2- ansactions whether HL7 v2.3.1 or HL7 v2.5.1 is it communicates with using the referenced tr used. 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 1480 ntations and the field correspondences are summarized in RAD TF -2: Appendix E. impleme 3.3 Scheduled Workflow Process Flow This section describes the process and information flow of patient care as it is defined in the 1] Radiology Technical Framework under “normal” circ umstances. It covers transactions [ RAD- RAD- , which reflect a typical patient encounter from 23] and transaction [ RAD- 1485 through [ 12] registration/admission through the performance of an ordered procedure. See appendix C for an change between the Department System Scheduler/Order Filler overview of the information ex 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 1490 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. Administrative and Procedure Performance P rocess Flow 3.3.1 1495 This case covers both inpatient and outpatient procedures. The patient may be new or known to the current healthcare facility. The following sequence of steps describes the typical process flow when a request is made to perform an imaging proce dure on a patient. ____________________________________________________________________________ 49 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

50 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order Acquisition Image Department System Placer Modality Manager Scheduler/ Order Filler ADT Register/ Admit Patient Patient - 1] Registration [RAD Create Order Placer Order Mgmt – - 2] New [RAD rocedure and/or Schedule P Assign Protocol Procedure Scheduled [RAD - 4] Query Modality 5] - Worklist [RAD 2 Continued in Figure 3.3 .1 - -1: Administrative Process Flow Figure 3.3.1 ____________________________________________________________________________ 50 Rev. 1 Copyright © 2018 8-07-27 : IHE International, Inc. 7.0 – Final Text 201

51 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Print Image Department System Order Manager/ Modality / Scheduler/ Order Server Placer Image Filler Print Archive Composer Modality Procedure Step Modality Procedure Step ress [RAD - 6] In Prog In Progress [RAD - 6] Perform Modality Images Acquisition 8] Stored [RAD - Modality Presentation State Stored [RAD 9] - Modality Procedure Step Modality Procedure Step - AD Completed [R 7] 7] Completed [RAD - Print Request [RAD - 23*] Storage Commitment [RAD 10] - Images Availability Query [RAD 11] - Order Status 3] - Update [RAD 1500 -2: Procedure Performance Process Flow Figure 3.3.1 -23] transaction is not a part of this profile; it is displayed for illustration purposes only. Note: The Print Request [RAD 1505 The following should be noted in relation to the Administrative and Procedure Performance process flow: The Print Composer is grouped with an Acquisition Modality but is shown separately in • the diagram to distinguish the different transactions. : The Department System associates the order with a number of • Schedule Procedure 1510 Requested 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 and ____________________________________________________________________________ 51 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

52 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ d a time slot and ordering. Scheduled Procedure Steps are scheduled, i.e., assigne performing resource (modality). : The radiologist determines the protocol (i.e., settings and conditions • Protocol Assigned 1515 to be used in performing the Scheduled Procedure Steps); in particular, the ordered list of otocol for each of the steps. This may happen prior to, codes identifying the pr Schedule Procedure simultaneous with, or subsequent to the . process step The diagram above shows one particular sequencing of the Modality Procedure Step • 1520 n may occur at any point following the -7] transaction. This transactio Completed [RAD creation 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), or even after storage commitment. The Ra diology Technical Framework does not specify the timing of this transaction in relation to other transactions. 1525 • The diagram above shows the managed creation of images. The equivalent flow applies to other Evidence Documents that the actor supports. Update Flow Patient 3.3.2 This case covers the situation where patient information updates are introduced into the system at the various stages of the normal process flow. Such updates will cause additional transactions to occur to assure synchronization of information between interested actors. Only the affected parts 1530 of the normal flow diagram are presented below. All subsequent process steps will progress according to the normal flow diagram. efore Procedure Scheduling 3.3.2.1 Patient Update b 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 1535 in the Figure 2. 1 and 3.3.2.1- s 3.3.2.1- ____________________________________________________________________________ 52 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

53 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order Acquisition Image Department System Placer Manager Modality Scheduler/ Order Filler ADT Register/ Admit Patient 1] Patient Registration [RA D - Modify Patient Patient 12] - Update [RAD Create Order Placer Order Mgmt – 2] New [RAD - before Order Entry -1: Patient Update Figure 3.3.2.1 ____________________________________________________________________________ 53 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

54 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order Image Acquisition Department System Placer Manager Modality Scheduler/ Order Filler ADT Admit/ Register Patient Patient Registration [RAD 1] - Create Order Placer Order Mgmt – 2] - New [RAD Modify Patient Patient ate [RAD Upd 12] - Figure 3.3.2.1 1540 Order Entry -2: Patient Update after The process includes changing inpatient demographics, merging two patient Modify Patient records and moving the information from one patient record to another. fter Procedure Scheduling Patient Update a 3.3.2.2 If patient information is changed after procedure(s) are scheduled by the Order Filler, the Patient 1545 Update transactions are altered as follows: ____________________________________________________________________________ 54 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

55 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order Acquisition Department System Image Manager Placer Modality Scheduler/ Order Filler ADT Register/ Admit Patient Patient Registration 1] [RAD - Create Order – Placer Order Mgmt New [RAD 2] - hedule Procedure and/or Sc Assign Protocol Procedure 4] - Scheduled [RAD Query Modality Worklist [RAD - 5] Modify Patient Patient Update [RAD - 12] -1: Patient Update a fter Procedure Scheduling Figure 3.3 .2.2 Note that in the Patient Information Reconciliation Profile (PIR), the Image Manager will also be 1550 notified and will have additional responsibility when Patient updates occur. 3.3.3 Order Change Flow Order Change Flow, HL7 v2.3.1 3.3.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 Radiology 1555 Technical Framework requires the initiating 1 actor to cancel the order and generate the new one using the new information. Figures 3.3.3.1- ____________________________________________________________________________ 55 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

56 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ and 3.3.3.1- 2 depict examples of order cancellation/re- ordering 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 rested actors. -2 to ensure synchronization of information between inte 1 and 3.3.1 1560 Figure s 3.3.1- Department System Order Acquisition Scheduler/ Order Image Manager Placer Modality ADT Filler Cancel Order r Mgmt Placer Orde - - Cancel [RAD 2] Procedure Update - [RAD 13] Query Modality Worklist [RAD - 5] Create Order - Placer Order Mgmt - 2] New [RAD Procedure 4] - Scheduled [RAD - Query Modality Worklist [RAD 5] -1: Order Replacement by the Order Placer 3.3.3.1 Figure 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 1565 -2. 3.3.3.1 ____________________________________________________________________________ 56 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

57 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Order Acquisition Image Manager Scheduler/ Order Placer Modality ADT Filler Order Cancelled Filler Order Mgmt 3] - Cancel [RAD - Procedure Update [RAD - 13] - Query Modality Worklist [RAD 5] Create Filler Order Mgmt Order – 3] - New [RAD Procedure 4] Scheduled [RAD - y Worklist [RAD - 5] Query Modalit -2: Order Replacement by the Department System Scheduler/Order Filler 3.3.3.1 Figure The Department System Scheduler/Order Filler may also generate a new order on its own as a 1570 case discussed in Section 4.2. The process flow in means of handling the unidentified patient 2, without the preceding such a situation corresponds to the ordering sequence in Figure 3.3.3.1- Order Cancel transaction. lity of the order discontinuation after Technical Framework does not support notification of the moda Note: The Radiology 1575 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. ____________________________________________________________________________ 57 Copyright © 2018 Rev. 1 7.0 – Final Text 201 8-07-27 : IHE International, Inc.

58 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Change Order Flow, HL7 v2.5.1 Option 3.3.3.2 This case covers the situation when the Order Placer or the Department System Scheduler/Order 1580 Filler has to change order information for systems implementing HL7 v2.5.1. When an order Technical F information change is necessary, the Radiology ramework allows for the initiating 1 and actor to change the order in a single message with the new information. Figures 3.3.3.2- 2 depict examples of order change flow initiated by the Order Placer and the Department 3.3.3.2- System Scheduler/Order Filler respectively. Note that one should consider these transactions as 1 and 3.3.1- 1585 2 being performed between the process flow fragments depicted in the Figure s 3.3.1- to ensure synchronization of information between interested actors. Department System Order Acquisition Scheduler/ Order Image Manager Placer Modality ADT Filler Modify Order - Placer Order Mgmt 2] Modified [RAD - Update Procedure 13 [RAD ] - - Query Modality Worklist [RAD 5] -1: Order Modified by the Order Placer 3.3.3.2 Figure Department System Scheduler/Order Filler may modify an order originally received from the 1590 wn in the Figure Order Placer, as sho 3.3.3.2 -2. ____________________________________________________________________________ 58 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

59 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Order Acquisition Image Manager Scheduler/ Order Placer Modality ADT Filler Modify Order Filler Order Mgmt [RAD – - 3] Modify Update Procedure - 13 ] [RAD - Query Modality Worklist [RAD 5] 3.3.3.2 -2: Order Modified by the Department System Scheduler/Order Filler Figure The Order Placer may not change an order that has already been started, i.e., one for which Order 1595 -Progress” statu Filler has transmitted an “In s. However, if the Order Filler receives the change order 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 the [RAD- 13] transaction to notify Image Manager. Procedure Update The Order Filler may not change a scheduled procedure step that has already been started, i.e., 1600 . The Radiology Progress” status one for which the Acquisition Modality has transmitted an “In- 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 s tep will be completed even 1605 though the order could be changed or discontinued. 3.3.4 Exception Management Workflow . The types of exceptions covered This case addresses the need to manage errors at the modality by this case are as follows: ct Scheduled Procedure Step from the Modality Worklist. Selection of the incorre • The need to handle the consequences of having performed a procedure step other than the • 1610 scheduled one. ____________________________________________________________________________ 59 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

60 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 are listed separately in this section and this Exception Management Workflow is supported by the low PPS EXCEPTION MANAGEMENT Option or other options in the Scheduled Workf 1615 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: 1. , the Before the Modality Procedure Step in Progress transaction is issued Operator/Radiologist changes the order on the Department System Scheduler which then 1620 provides the Modality Worklist as defined by the Scheduled Workflow Integration Profile ion 3.3.3). This will ensure that the most recent (see the Order Change flow described in Sect Worklist Information is used by the Modality . This case does not require the PPS OPTION. The Acquisition Modality shall be able to process EXCEPTION MANAGEMENT 1625 new worklist information that results from this order change; when or how the modality re - queries the Department System Scheduler is not specified by this framework. After the Modality Procedure Step in Progress transaction has been issued, but before the 2. Modality 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 by 1630 Abandoned case (see RAD TF -2: 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 . the After the Modality Procedure Step Completed transaction has been issued, 3. aware that an incorrect worklist entry selection Operator/Radiologist may notice or become 1635 was made. Whether this occurs before the Requested Procedure is read or afterwards, the . Rather the Image modality is not responsible for performing the necessary corrections -2: see RAD TF Manager and the Department Scheduler Actors must make such corrections ( . The Image Manager and the Order Filler may also offer a correction capability 4.7.4.1.3.1) to recover the erroneous instances. IHE does not provide a mechanism to propagate 1640 automatically this correction between the Image Manager/Image Archive and the Department 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 Schedul er/ Order Filler. After the Modality Procedure Step in Progress transaction has been issued, but before the 1. 1645 Modality Procedure Step Completed transaction is issued, the Operator/Radiologist may om what was intended by the decide to modify the “in progress” Performed Procedure Step fr . In the Scheduled Workflow Requested Procedure and Scheduled Procedure Step selected Integration Profile, the Acquisition Modality Actor notifies the PPS Manager (and in turn the 1650 ) by returning a Procedure Code Image Manager and the Department System Scheduler Sequence of zero length. In addition, if the ASSISTED ACQUISITION PROTOCOL SETTING Option is supported by the Acquisition Modality, it can indicate this change by ____________________________________________________________________________ 60 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

61 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ returning a Performed Protocol Code Sequence different from t he Scheduled Protocol Code 3.3.4- Figure Sequence (see 4 below). Before 1655 2. , the the Modality Procedure Step in Progress transaction is issued Operator/Radiologist decides to proceed without changing the order on the Department System Scheduler/Order Filler by performing one or more Procedure Steps different than scheduled by the Modality Worklist entry as defined by the Scheduled Workflow Integration Profile. Its handling at the Acquisition Modality may be facilitated by the ASSISTED ACQUISITION PROTOCOL SETTIN 1660 G Option. Acquisition Image Department System Order Manager/ Scheduler/ Order Modality / Placer Image Archive Filler Query Modality Worklist [RAD - 5] Select MWL Entry (SPS) Modality Procedure Step Modality Procedure Step In Progress [RAD - 6] 6] In Progress [RAD - Perform Acquisition (changed from scheduled) Modality Images 8] - Stored [RAD Modality Presentation State - Stored [RAD 9] Modality Procedure Step Modality Procedure Step - 7] Completed [RAD 7] - Completed [RAD Procedure Code Procedure Code and (Performed and (Performed Protocol Code) Protocol Code) 3.3.4 Figure -1: Exception Management Workflow (Changed from Scheduled on Modality) 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 the 1665 Acquisition Modality, Department System Scheduler and Image Manager Actor s. 1. After the Modality Procedure Step In Progress transaction has been issued, the ator/Radiologist may realize that the wrong SPS has been selected (incorrect patient or Oper incorrect 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 1670 Archive (with or without storage commitment confirmed). With the PPS EXCEPTION MANAGEMENT Option of the Scheduled Workflow Integration Profile, the Acquisition ____________________________________________________________________________ 61 Copyright © 2018 – Final Text 201 7.0 Rev. 1 : IHE International, Inc. 8-07-27

62 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Modality Actor notifies the PPS Manager (and in turn the Image Manager and the artment System Scheduler/Order Filler) of the error so that these systems take Dep 1675 Figure 3.3.4- -2: 4.7.4.1.3.1 and appropriate action (See RAD TF 2 below). IHE does not define how the modality may dispose of and/or correct the images or other Each implementation shall decide if it is useful to support the storage of the evidence objects. corrected images or other evidence objects, when clinically meaningful . However if they do, Modality Procedure Step in Progress/Completed s and Storage Commitment transaction new 1680 shall be used. In this case, the PPS EXCEPTION MANAGEMENT Option of the Scheduled Workflow Integration Profile provides further functionality. The Modality Actor notifies the PPS Manager (and in turn the Image Manager and the Department System Scheduler) of the reason for the discontinuation so that these systems may take the appropriate actions (see 1685 Figure 3.3.4- 3 below). ____________________________________________________________________________ 62 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

63 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Manager/ Image Department System Order Scheduler/ Order Modality / Image Archive Placer Filler 5] Query Modality Worklist [RAD - Select (wrong) MWL Entry (SPS) Modality Procedure Step Modality Procedure Step 6] - In Progress [RAD In Progress [RAD - 6] Perform Acquisition Modality Images (for wrong MWL entry) Stored [RAD - 8] Modality Presentation State Stored [RAD - 9] Modality Procedure Step Modality Procedure Step Completed [RAD - 7] - 7] Completed [RAD Discontinue with Discontinue with wrong MWL entry wrong MWL entry selected selected Query Modality Worklist [RAD - 5] Select (right) MWL Entry (SPS) Modality Procedure Step Modality Procedure Step In Progress [RAD - 6] 6] - In Progress [RAD Optional Recycling of Update instances acquired Modality Images (for right MWL entry) instances with 8] Stored [RAD - wrong WL entry Modality selected. Presentation State d [RAD Store 9] - Modality Procedure Step Modality Procedure Step 7] - Completed [RAD 7] Completed [RAD - Completed Completed Figure -2: Exception Management Workflow (Wrong Worklist Entry Selected) 3.3.4 ____________________________________________________________________________ 63 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

64 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Image Department System Order Manager/ Scheduler/ Order Modality / Placer Image Archive Filler 5] - Query Modality Worklist [RAD Select MWL Entry (SPS) Modality Procedure Step Modality Procedure Step 6] - In Progress [RAD 6] - In Progress [RAD Perform Acquisition Modality Images (PPS Discontinued) 8] Stored [RAD - Modality Presentation State - Stored [RAD 9] y Procedure Step Modalit Modality Procedure Step Completed [RAD - 7] Completed [RAD - 7] Reason for Reason for Discontinue Discontinue 1690 Figure 3.3.4 -3: Exception Management Workflow (Discontinued with a Reason) 3.3.5 Implicit Post -Processing -processing tasks performed as an implicit part of the Scheduled This case addresses image post Workflow. -processing tasks scheduled and managed explicitly using post processing In general, post 1695 worklists are addressed by the Post ection 12 for -Processing Workflow Integration Profile (see S further details on that profile) -processing tasks performed on the . However, at some sites, post acquisition system or adj acent workstations are implied by the information in the acquisition . In such cases, the post -processing is managed by the technician simply carrying out the worklist steps following acquisition . Technicians may be instructed that certain post -processing should always be performed for 1700 certain acquisitions, or alternatively, different protocol codes may be provided in the acquisition -processing . In either case, no worklist is used on the post worklist to indicate intended post - processing Evidence Creator. processing workflow”, the Evidence Creator may obtain source In the case of this “implicit post- 1705 -processing by receiving them from the images and other evidence objects necessary for post efined mechanism) or IHE d Acquisition Modality Actor (either pulled or pushed via some non- by being grouped with an Image Display Actor (giving the system query/retrieve capabilities) . ____________________________________________________________________________ 64 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

65 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Based on the information contained in the images, the Evidence Creator can send status ansactions as shown in the following use messages and store its results according to the IHE tr 1710 cases. The following sequence of steps describes the typical process flow when the Evidence Creator receives the images from an Acquisition Modality via some non- IHE means. ____________________________________________________________________________ 65 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

66 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Image Department System Evidence Manager/ Modality Scheduler/ Order Creator Image Archive Filler 5] - Query Modality Worklist [RAD Select MWL Entry (SPS) Modality Procedure Step Modality Procedure Step 6] - In Progress [RAD - 6] In Progress [RAD Perform Acquisition Modality Images 8] - Stored [RAD Modality Presentation - 9] State Stored [RAD Modality Procedure Step Modality Procedure Step 7] - Completed [RAD 7] - Completed [RAD Transfer Images Creator Procedure Step Creator Procedure Step In Progress [RAD 20] - 20] In Progress [RAD - Perform Post - Processing Creator Images Stored [RAD - 18] Creator Presentation State Stored [RAD - 19] Creator Procedure Step Creator Proc edure Step - 21] Completed [RAD 21] - Completed [RAD 3.3.5 Figure -processing in Scheduled Workflow -1: Post ____________________________________________________________________________ 66 Rev. 1 7.0 – Final Text 201 8-07-27 : IHE International, Inc. Copyright © 2018

67 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Note: -9] and Creator Presentation State Stored [RAD The Modality Presentation State Stored [RAD -19] transactions are 1715 not a part of this profile; they are displayed for illustration purposes only. The following should be noted in relation to the Post -Processing process flow in Scheduled Workflow as described above: -processing are transferred from the Acquisition Modality to the 1720 The images for post • Technical Framework. Evidence Creator by means that are out of scope of the Radiology : The Evidence Creator uses the source images and/or other -Processing Perform Post • -processing evidence objects it receives from the Acquisition Modality to perform post 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 1725 Performed Procedure Step Messages. The following sequence of steps describes the typical process flow when Evidence Creator is y. grouped with Image Displa ____________________________________________________________________________ 67 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

68 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Manager/ Acquisition Evidence Department System Image Archive Modality Scheduler/ Order Creator/ Image Filler Display 5] Query Modality Worklist [RAD - Select MWL Entry (SPS) Modality Procedure Step Modality Procedure Step - 6] In Progress [RAD - In Progress [RAD 6] Perform Acquisition Modality Images - 8] Stored [RAD Modality Presentation - 9] State Stored [RAD rocedure Step Modality P Modality Procedure Step 7] - Completed [RAD Completed [RAD - 7] 14] - Query Images [RAD Retrieve Images 16] [RAD - Creator Procedure Step Creator Procedure Step In Progress [RAD - 20] - In Progress [RAD 20] Creator Images 18] Stored [RAD - form Per - Post Creator Presentation Processing State Stored [RAD - 19] Creator Procedure Step Creator Procedure Step 21] - Completed [RAD Completed [RAD 21] - 1730 -processing in Scheduled Workflow (performed on Evidence Creator) Figure 3.3.5 -2: Post -19] transactions are Note: The Modality Presentation State Stored [RAD -9] and Creator Presentation State Stored [RAD ile; they are displayed for illustration purposes only. not a part of this prof ____________________________________________________________________________ 68 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

69 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The following should be noted in relation to the Post -Processing process flow on the independent workstation: • 1735 - The Evidence Creator is grouped with the Image Display and the images for post processing are retrieved from the Image Archive where the Acquisition Modality has transferred them. : The Evidence Creator uses the source images and/or other -Processing Perform Post • evidence objects it receives from the Image Archive to perform post s and -processing task 1740 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. Departmental Appointment Booking 3.3.6 e use of the Departmental Appointment Notification Option by the Order This case addresses th 1745 Placer and Order Filler Actors. 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 Order acer may request . The Order Pl is managed by the Departmental System Scheduler/Order Filler 1750 along with an Order a preferred date and time for this Order, but it is the Order Filler that sets, . When a new Order is placed updates and possibly cancels the appointment(s) for examinations by the Order Placer or the Order Filler, an Ap pointment Notification (New Bookings) is sent to . This Appointment Notification (New Bookings) may include several the Order Placer appointments bookings in case some of the Scheduled Procedure Steps require separate 1755 appointments. Equally, one or more Sche duled Procedure Steps may be scheduled during the same 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 1760 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 of any scheduling changes that may be made by the Order Filler, but not to request an appointment change. For such a change, it may be necessary to use means not defined in this Integration a phone call to the person entering orders on the Order Filler) that an appointment Profile (e.g., 1765 booki ng has to be changed. ____________________________________________________________________________ 69 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

70 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order Image Department System Placer Manager Scheduler/ Order Filler Create Order Placer Order Mgmt – 2] New [RAD - Schedule Procedure Steps - Appointment Notification and/or Assign Protocol 48] - s [RAD New Booking Procedure Scheduled 4] - [RAD chedule Procedure Res – Appointment Notification Step(s) Reschedule Bookings [RAD 48] - Procedure Update 13] - [RAD - Appointment Notification Cancel Procedure or Cancel Bookings [RAD - 48] Procedure Steps Procedure Update - [RAD 13] 3.3.6 -1: Departmental Appointment Bookings Process Flow Figure 3.4 Data Model for Scheduled Workflow 1770 This section defines the integrated data model adopted by the Radiology Technical Framework es and the DICOM Information Object Definitions (IODs). The Entity for the HL7 messag Relationship (ER) diagram represents the integration of proper subsets of HL7 v2.3.1 and the DICOM Model of the Real World with minor extensions as noted in S ection 3.4.1 and described ppendix B. in A 1775 3.4.1 Model of the Real Worl d Figure 3. 4- 1 depicts the model of the real world within scope of the Scheduled Workflow level integration of the DICOM and HL7 Profile. This model provides an overview of the high- models. This integrated model differs from the DICOM Model of the Real World (refer to 3.3) in the following respects: DICOM PS The Service Episode, Procedure Plan and Procedure Type entities have been excluded • 1780 Technical Framework and are outside the scope of the Radiology ____________________________________________________________________________ 70 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

71 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ en the Visit and Imaging Service Request has been excluded and is The relationship betwe • Technical Framework. Radiology outside the scope of the • The HL7 Placer Order and Filler Order entities have been inserted into the DICOM hierarchy between the Patient entity and Imaging Serv ice Request entity. IHE requires 1785 that 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 us e of the Accession Number - ppendix A for further discussion. DICOM attribute (0008,0050); see A 1790 ____________________________________________________________________________ 71 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

72 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1 - n 0 has Visit Patient 1 Is the subject of n - 0 Placer Order 1 is fulfilled by 1 Filler Order/ Imaging Service Request 1 has - 1 n Requested Procedure n - 0 1 is composed Results in of 1 n - 1 1 - n Scheduled includes Protocol Code Procedure Step n - 0 n - 0 1 describes Results in 0 - m m - 0 Modality Performed Series I nstance Procedure Step Belongs to Belongs to 1 1 1 - n 0 n - 1: Real World Model for Scheduled Workflow Figure 3.4- ____________________________________________________________________________ 72 7.0 8-07-27 Copyright © 2018 Rev. 1 – Final Text 201 : IHE International, Inc.

73 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 3.4.2 Scheduled Workflow Concepts in Practice The IHE “Real World” model for Scheduled Workflow described above offers three major levels 1795 of control that can be used to customize a broad range of specific workflow situations: Order • : A request for an Imaging Service ciated codified, : Unit of work resulting in one report with asso Requested Procedure • billable acts. 1800 • : the smallest unit of work in the workflow Scheduled and Performed Procedure Step that is scheduled (work to do) and/or performed (work done). The Order Filler/Department System Scheduler uses the Universal Service ID in each order that it 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 one 1805 of 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) and edure Steps. for each Requested Procedure Code, the breakdown in Scheduled Proc The figure below defines an example of the breakdown of a “rule out pulmonary embolism” Order. 1810 : Order R/O Pulmonary Embolism : Chest X - ray Requested Procedure Scheduled Procedur : e Step Chest PA and Lateral Requested Procedure : NM Ventilation Perfusion : Scheduled Procedure Step NM Ventilation Acquisition Scheduled Procedure Step NM Perfusion Acquisition 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, . The NM Ventilation Perfusion Procedure has been hence two different Requested Procedures ent will scheduled as two different Scheduled Procedure Steps, to account for the fact that the pati 1815 ____________________________________________________________________________ 73 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

74 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ have the two NM acquisitions performed at a different time, thus allowing for patient preparation . This is the way this institution has decided to handle this Order between the two examinations . -ray and the Another Institution may choose to require the same r adiologist to read both the X . In that case it would define in its Procedure plan for the same Order to have a single NM images 1820 Requested Procedure with three Scheduled Procedure Steps. a simpler breakdown such as this Many Orders processed in a Radiology Department would have Chest X -ray example. Order : Chest X - ray ray : Requested Procedure Chest X - : Scheduled Procedure Step Chest PA and Lateral 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 ca ses may be 1825 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. . The requested In the IHE Scheduled Workflow, the Accession Number identifies the Order Procedure ID distinguishes among Requested Procedures when an Order requires multiple 1830 Procedures. IHE sets a common meaning for these two terms to provide clinicians with a consistent and non- ambiguous access across different vendor products (RIS, PACS and Modalities). Tracking Performed Procedure Steps 3.4.2.1 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 1835 been performe d. 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. Using the Pulmonary Embolism example above, one may decide to follow the Order breakdown 1840 as defined in the procedure Plan. ____________________________________________________________________________ 74 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

75 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ : Order R/O Pulmonary Embolism : Chest X - ray Requested Procedure Performed Procedure Step : Scheduled Procedure Step : Chest PA and Lateral Chest PA and Lateral NM Ventilation Perfusion Requested Procedure : : Scheduled Procedure Step : Performed Procedure Step NM Ventilation Acquisition NM Ventilation Acquisition Scheduled Procedure Step Performed Procedure Step NM Perfusion Acquisition NM Perfusion Acquisition -ray Requested Procedure would contain the series of images associated with the The Chest X tilation Perfusion would contain Chest PA and Lateral Performed Procedure and the NM Ven . From this example both the series for the ventilation and the series of images for the perfusion one can see how the Requested Procedure forms the “folder” where the radiologists find the 1845 images to be read resulting from t he 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 ray - Requested Procedure : Chest X : Performed Procedure Step Scheduled Procedure Step : Chest PA and Lateral Chest PA and Lateral Requested Procedure NM Ventilation Perfusion : Scheduled Procedure Step : : Performed Procedure Step NM Ventilation Acquisition NM Ventilation Acquisition Scheduled Procedure Step Performed Procedure Step n NM Perfusion Acquisitio NM Perfusion Acquisition In this later case, the Nuclear Scheduled Procedure Steps will be cancelled 1850 . Only the Chest X -ray Requested Procedure will “contain” the Image corresponding to the Chest PA and lateral Chest X-ray. To illustrate further the capabilities of the IHE Scheduled Workflow look at a Profile , let's Chest/Abdomen/Pelvis Order that a radiology department chooses to break down into a Chest 1855 Requested Procedure and an Abdomen/Pelvis Requested Procedure in order to take advantage of . Some hospitals also may want to produce sepa the subspecialties of its radiologists rate reports to align with the charging policies. ____________________________________________________________________________ 75 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

76 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Order : CT Chest/Abdomen/Pelvis : CT Chest Requested Procedure ed Procedure Step Schedul : CT Chest w/o contrast : Performed Procedure Step : CT Abdomen/Pelvis Requested Procedure CT Chest/Abdomen/pelvis w/o contrast : Scheduled Procedure Step CT Abdomen/ Pelvis w/o contrast In this example, a single Performed Procedure Step has been performed in response to two . At the time 1860 . IHE refers to this as a Group Case (see RAD TF Scheduled Procedure Steps -2: 4.6) 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 the Abdomen/Pelvis Requested Procedure. Extending the Scheduled Workflow Concepts to Include Post 3.4.2.2 -Processing Tasks 1865 ection 3.4.2.1 above) may be extended to include other The workflow concepts (as described in S Scheduled Procedure Steps, such as those used to describe post -processing tasks. 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. 1870 Order : MR Brain Functional Analysis : MR Brain Functional Analysis Requested Procedure Sched uled Procedure Step : : Performed Procedure Step MR Brain Acquisition MR Brain Acquisition Scheduled Procedure Step Performed Procedure Step MR Functional Analysis MR Functional Analysis In the above example, two different Scheduled Procedure Steps have been defined for the Requested Procedure. This reflects the fact that in this radiology department, the functional -processing is not performed by the MR Technologist, but by the Radiologist and analysis post 1875 therefore needs to be independently scheduled on an independent workstation. Another department may well choose to have the Technologist perform the post -processing immediately . In that case the -located workstation) after the MR acquisition (either on the MR itself or on a co ____________________________________________________________________________ 76 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

77 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Requested Procedure would include a single Scheduled Procedure Step that includes both the -processing task. acquisition and the post es supported by This Section does not provide an exhaustive description of all the workflow cas 1880 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. 3.4.3 Model Scheduled Workflow Information 1885 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 the entities is indicated. Figure An example of the conventions used to specify an entity’s relationships is presented in 1890 2. 3.4- 1 N Entity Name diagram and not shown to clarify the ER Foreign Key (FK) relating this entity to previous - The FK is relational model. represent a intended to 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 ombined to guarantee uniqueness. indicates two attributes must be c Figure 3.4- 2: Example of the Entity Relationship Diagram 4.4 present the overview of the IHE Information Model Figures 3.4- . Mappings between 3 and 3- -2: Appendix B. specific HL7 Elements and DICOM Attributes are identified in RAD TF 1895 ____________________________________________________________________________ 77 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

78 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient n - 0 1 Patient ID + Issuer of Patient ID 1 Visit n 0 - 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 1 Filler Order / Imaging Service Request der Number + Issuer of Placer Order Number Placer Or Filler Order Number + Issuer of Filler Order Number Accession Number *The Order Filler can expand 1 ingle order into multiple that s Requ ested Procedures. See - 1 n* - RAD TF 4.4 for more 2: Requested Procedure details. Filler Order Number + Issuer of Filler Order Number Accession Number Study Instance UID Requested Procedure ID To Modality To Scheduled Performed Procedure Procedure Step Step Entity 3: Schedule Workflow Information Model Figure 3.4- 1900 ____________________________________________________________________________ 78 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

79 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1 From Requested Procedure Step 1 n - 1 Scheduled Procedure Step Requested Procedure ID Study Instance UID Scheduled Procedure Step ID n** - 0 - n** 0 0 - m** Modality Performed Procedure Step 0 - m** Scheduled Procedure Step ID Study Instance UID Performed Procedure Step UID*** Affected SOP Instance UID 1 - n 1 **See Volume II, Section 4.6 for Series a thorough description of the cardinality relationship options Performed Procedure Step UID*** of Modality Performed N Procedure Step. Series Instance UID ure ***The Performed Proced Step UID is present as the Affected SOP Instance UID. 1 - 0 n DICOM Instance Series Instance UID SOP Instance UID 4: Schedule Workflow Information Model, continued Figure 3.4- ____________________________________________________________________________ 79 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

80 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1905 Patient Information Reconciliation (PIR) 4 The Scheduled Workflow the extends Patient Information Reconciliation Integration Profile by offering the means to match images, and the Reporting Workflow Integration Profile 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, rofile allows subsequent reconciliation of the patient record with images that are 1910 this integration p 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 i mmediately 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 and reports, greatly simplifying these exception ha ndling situations. In addition, this Integration 1915 Profile allows the Image Manager and Report Manager to receive patient update messages to maintain consistency of the patient information. The Image Manager and Report Manager do not ns in the Scheduled Workflow Integration Profile. receive those transactio ____________________________________________________________________________ 80 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

81 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1920 Actors/Transactions 4.1 1 diagrams the actors involved with this profile and the transactions between actors. Figure 4.1- The shaded actors are NOT actually included in this profile but are included to show the other ry Reporting Worklist, Query/ endpoint of transactions that ARE part of the profile (e.g., Que Retrieve Reports and Query/ Retrieve Images). As a result, the shaded actors are not listed in 1. Table 4.1- 1925 Order Placer ADT → Patient Update [RAD - 12] Patient Update [RAD ↓ - 12] / Order Filler DSS Patient Up 12] - date [RAD ↓ ↓ 11] - Images Availability Query [RAD - ↓ Procedure Update [RAD 13] Patient Update [RAD - 12] ↓ ↓ Procedure Update [RAD - 13] - ↑ Modality PS in Progress [RAD 6] ↑ Modality PS Completed [RAD - 7] Report Manager ↑ Query Reporting Worklist [RAD - 46] Query Reports [RAD ↑ 26] - Performed 27] Retrieve Reports [RAD ↑ - Procedure Step Report Creator/ Manager Report Reader Image Image Manager Archive → 6] Modality PS in Progress [RAD - → - dality PS Completed [RAD Mo 7] 14] - Query Images [RAD ↑ ↑ 16] Retrieve Images [RAD - Image - 6] ← Modality PS in Progress [RAD Display ← 7] - Modality PS Completed [RAD Acquisition Modality ← - 5] Query Modality Worklist [RAD Figure 4.1- 1: Patient Information Reconciliation Diagram 1930 ____________________________________________________________________________ 81 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

82 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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, 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 1935 may choose to support is listed in Section 4.2. - Actors and Transactions 1: Patient Information Reconciliation Table 4.1- Transactions Optionality TF Refe rence Actors ADT Patient Registration -12] R RAD TF -2: 4.12 Patient Update [RAD RAD TF Order Placer -12] R Patient Update [RAD -2: 4.12 Department System 4.12 -2: RAD TF R Patient Update [RAD -12] Scheduler/ Procedure Update [RAD -13] R RAD TF -2: 4.13 Order Filler Query Modality Worklist [RAD 4.5 -5] R RAD TF -2: Modality Procedure Step In Progress 4.6 R RAD TF -2: [RAD -6] Modality Procedure Step Completed R RAD TF -2: 4.7 -7] [RAD RAD TF Images Availability Query [RAD -11] O 4.11 -2: Acquisition Modality Query Modality Worklist [RAD -5] R RAD TF -2: 4.5 4.6 -2: Modality Procedure Step In Progress R RAD TF -6] [RAD Modality Procedure Step Completed 4.7 -2: RAD TF R [RAD -7] 4.12 Patient Update [RAD -12] R RAD TF Image Manager/ -2: Image Archive [RAD -13] Procedure Update RAD TF -2: 4.13 R Modality Procedure Step In Progress 4.6 -2: R RAD TF -6] [RAD Modality Procedure Step Completed RAD TF -2: 4.7 R [RAD -7] Query Images [RAD -14] R RAD TF -2: 4.16 Retrieve Images [RAD -16] R RAD TF -2: 4.16 4.11 -2: R RAD TF Images Availability Query [RAD -11] Performed Procedure Step 4.6 Modality Procedure Step In Progress -2: RAD TF R -6] Manager [RAD Modality Procedure Step Completed R RAD TF -2: 4.7 [RAD -7] Report Manager 4.12 Patient Update [RAD -12] R RAD TF -2: (optionally grouped with a Procedure Update [RAD -13] R RAD TF -2: 4.13 Report Repository) Query Report [RAD -26] R RAD TF -2: 4.26 Retrieve Reports [RAD -27] R RAD TF -2: 4.27 R RAD TF -3: 4.46 Query Reporting Worklist [RAD -46] 2-1 for other profiles that may be pre Refer to Table -requisites for this profile. ____________________________________________________________________________ 82 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

83 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. 1940 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 in Volume 2 and Volume 3. To support the Patient Information Reconciliation Profile, an actor that claims support of other 1945 content 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. tient information update but The Report Manager must update existing workitems based on the pa since the report content is not modified the rest of the reporting workflow is not affected. In other 1950 words, 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 the patient update. In case of DICOM SR, the patient information might be included in the content sequence. The 1955 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 1960 Options that may be selected for this Integration Profile are listed in the Table 4.2- 1 along with the a ctors to which they apply. – Actors and Options 1: Patient Information Reconciliation Table 4.2- Options Actor TF Reference HL7 v2.5.1 RAD TF -1: 4.2.1 ADT Patient Registration 4.12 -2: RAD TF Order Placer HL7 v2.5.1 RAD TF -1: 4.2.1 RAD TF -2: 4.12 RAD TF -1: DSS/Order Filler HL7 v2.5.1 4.2.1 TF -2: 4.12 RAD RAD TF -2: 4.13 - Acquisition Modality No options defined 4.2.1 Image Manager/ Image Archive HL7 v2.5.1 RAD TF -1: RAD TF -2: 4.12 4.13 -2: RAD TF No options defined Manager Performed Procedure Step - ____________________________________________________________________________ 83 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

84 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Options TF Reference Actor 4.2.1 -1: RAD TF HL7 v2.5.1 Report Manager RAD TF -2: 4.12 -2: 4.13 RAD TF HL7 v2.5.1 Option 4.2.1 1965 The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in the 1. The actor shall permit configuration for each system that transactions referenced in Table 4.2- it communicates with using the referenced transactions whether HL7 v2.3.1 or HL7 v2.5.1 is used. It is possible that the actor may receive HL7 v2.3.1 messages and send HL7 v2.5.1 messages or vice versa. 1970 antic equivalency with HL7 v2.3.1 The specifications in the HL7 v2.5.1 Option maintain sem -2: Appendix E . implementations and the field correspondences are summarized in RAD TF Unidentified Patient Image Acquisition and Reconciliation 4.3 ocedures for This section describes the general process flow related to the handling of pr unidentified patients. The transactions covered are Patient Registration [RAD -1], Placer Order -2], Procedure Scheduled [RAD -4], MWL Provided [RAD -5], Modality 1975 Management [RAD - Procedure Step In Progress [RAD -6], Modality Procedure Step Complete d/Discontinued [RAD 7], Patient Update [RAD -12], and Procedure Update [RAD -13]. The Unidentified Patient case covers the trauma case or emergency room patient when a patient’s condition requires that a procedure be conducted immediately. This is done befor e proper patient registration, ordering and/or scheduling of the procedure are performed (due to the 1980 lack of either information or time or other deviation from the normal process flow). In this case operly updated at the ADT, Order patient/study information must be later reconciled and pr 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 1985 ils): (see S ections 4.4.1 – 4.4.5 for deta : Unidentified Patient registered at ADT and ordered at Order Placer. • Case 1 : Unidentified Patient registered at ADT and ordered at Department System Case 2 • Scheduler/Order Filler. : Unidentified Patient registered at ADT but acquisition completed at Modality Case 3 • prior to order. 1990 In cases 1, 2, and 3, the ADT may utilize the Master Patient Index (MPI) internally. The interaction of the ADT with MPI to resolve the patient information to the correct Patient ID may nformation reconciliation within the ADT role. The IHE be embedded in the process of patient i Technical Framework in future years may define patient reconciliation transactions using MPI. Technical Framework also supports cases when registration or temporary The Radiology 1995 registration of a patient by ADT is not applicable or desired, for example: ____________________________________________________________________________ 84 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

85 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. • 2000 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. 2005 ections 4.4.4 and 4.4.5): The following additional use cases are identified (see S • ed temporary Departmental ID and scheduled at Case 4 : Unidentified Patient assign Department System Scheduler/Order Filler. Case 5: Image Acquisition completed without scheduling at Department System • 2010 Scheduler/Order Filler. 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, rk in future years may define patient reconciliation transactions the IHE Technical Framewo using Master Patient Index (MPI). 2015 The Radiology Technical Framework also recognizes that the following 4- step case of handling unidentified patients may be utilized in certain installations: The patient is delivered to the department, where a temporary departmental Patient ID and/or 1. name are assigned. 2. The order is then entered by the Department System Scheduler/Order Filler and with this 2020 Patient 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. 2025 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 syst em locally merges the new record with the existing one identified by the departmental Patient ID. Because this case requires reconciliation at multiple points throughout the enterprise, IHE does 2030 not recommend this workflow. ion during Image Acquisition Patient Information Reconciliat 4.3.1 This section describes the general process flow related to the handling of procedures for image . The transactions covered are Patient during patient reconciliation acquisition ongoing ____________________________________________________________________________ 85 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

86 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2035 -4], 2], Procedure Scheduled [RAD -1], Placer Order Management [RAD- Registration [RAD MWL Provided [RAD -6], Modality Procedure -5], Modality Procedure Step In Progress [RAD -13], Step Completed/Discontinued [RAD -7], Patient Update [RAD -12], Procedure Update [RAD Query Images [RAD -14], Query Presentation States [RAD -16] and -15], Retrieve Images [RAD Retrieve Presentation States [RAD -17]. 2040 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 . Even after a Patient Update has occurred images coming from the Modality the Image Manager may continue to use the original Patient Information, so on- going Patient update with incoming . It is the responsibility of the Image Manager to images from the modality may be necessary 2045 ensure that the patient information is updated in the images, Grayscale Softcopy Presentation . This States and other Evidence Objects when they are retrieved from the Image Archive example is described in use case 6 (see Section 4.4.6). Use Cases 4.4 The following sections describe the Unidentified Patient use cases. For the purpose of simplification, the following transactions were omitted from the corresponding diagrams: 2050 • Modality Performed Procedure Step In Progress [RAD- 6] • Modality Images Stored [RAD -8] Modality Presentation State Stored [RAD -9] • -10] Storage Commitment [RAD • 2055 These transactions may occur within the time frame of the diagram, but their content does not affect each of the use cases. 4.4.1 atient Registered at ADT and Ordered at the Order Case 1: Unidentified P Placer The ADT is a single point of patient reconciliation in the enterprise. Process flow requires that any unidentified patient be assigned a permanent Patient ID and a temporary name (e.g., “John 2060 ection 3.1) including order Doe”). All subsequent transactions follow the normal flow (see S entry and procedure scheduling. When the real patient identity is known, the ADT is responsible and Department for reconciliation of its own records as well as informing the Order Placer System Scheduler/Order Filler about corresponding changes. The ADT sends a Patient Update 2065 message to both the Order Placer and Department System Scheduler/Order Filler. The Department System Scheduler/Order Filler sends the Patient Update m essage to the Image Manager and the Report Manager. ____________________________________________________________________________ 86 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

87 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Image Report Order Acquisition ADT Scheduler/ Manager Manager Placer Modality Order Filler Register J.Doe Patient 1] - Registration [RAD Placer Order – Management - 2] New [RAD Schedule Procedure Images Procedure Acquired 4] Scheduled [RAD - - 5] Query Modality Worklist [RAD Modality Procedure Step Modality Procedure Step Patient Reco nciliation Completed [RAD - 7] Completed [RAD - 7] J.Doe > J.Smith - Patient Update/ Pat ient Update/ Merge [RAD - 12] Merge [RAD - 12] - Patient Update/ Merge [RAD 12] – Case 1 1: Unidentified Patient Figure 4.4- Significant Transactions: 2070 To reconcile the patient information, the ADT may register a new patient and merge the • -1] temporary patient with the correct patient and send both Patient Registration [RAD and Patient Update [RAD -12] (Merge) transactions. If a permanent Patient ID was assigned, then the ADT may only send a Patient Update • 2075 12] transaction with proper information. [RAD- e Performed Procedure Step Manager is not shown on the Process Flow diagrams Note that th grouped with the Department and is presumed to be grouped with the Image Manager. It may be System Scheduler/Order Filler with corresponding changes in the flow of PPS related nsactions between the Image Manager and Department System Scheduler/Order Filler. tra ____________________________________________________________________________ 87 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

88 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 4.4.2 2080 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 are scheduled normally and image acquisition uses modality worklist . When the patient information t Update messages to both the Order Placer and is reconciled, the ADT sends the Patien 2085 . The Department System Scheduler/Order Filler Department System Scheduler/Order Filler sends the Patient Update message to the Image Manager and the Report Manager. Department System Image Order Report ADT Acquisition Scheduler/ Manager Placer Manager Modality Order Filler Register J.Doe Patient Registration - [RAD 1] Filler Order Management – Schedule Procedure - 3] New [RAD Procedure 4] - Scheduled [RAD Images Acquired Query Modality Worklist [RAD - 5] Modality Procedure Step ent Reconciliation Pati Modality Procedure Step - Completed [RAD 7] Completed [RAD - 7] - > J.Smith J.Doe Patient Update/ 12] - Merge [RAD Patient Updat e/ 12] Merge [RAD - Patient Update/ Merge [12] Figure 4.4- – Case 2 2: Unidentified Patient 2090 ____________________________________________________________________________ 88 Rev. 1 : IHE International, Inc. 7.0 – Final Text 201 8-07-27 Copyright © 2018

89 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Significant Transactions: • To reconcile the patient information, the ADT may register a new patient and merge the temporary patient with the correct patient and send both registration and merge transactions. 2095 If a permanent Pati ent ID was assigned, then the ADT may only send a Patient Update • transaction with proper information. • 3] transaction is sent from Department A Filler Order Management (New Order) [RAD- System Scheduler/Order Filler to the Order Placer. 2100 Case 3: Unidentified Patient Registered at ADT but Completed at Modality 4.4.3 Prior to Order . However, no order As in cases 1 and 2, this uses a permanent Patient ID generated by the ADT 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 2105 (typically, from a card) and conveyed to the Department System Scheduler/Order Filler and the ent System . Subsequently, the Departm Image Manager by the Acquisition Modality 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 tment System Scheduler/Order . The Depar Filler sends a Patient Update message to the Image Manager and the Report Manager. 2110 ____________________________________________________________________________ 89 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

90 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Image Report Order Acquisition ADT Scheduler/ Manager Manager Placer Modality Order Filler Register J.Doe Images Patient Registration Acquired [RAD - 1] Modality Procedure Step Completed [RAD - 7] Modality Procedure Step - 7] Completed [RAD Filler Order Management – New Order 3] - New [RAD Procedure Scheduled [RAD - 4] Patient Reconciliation - > J.Smith J.Doe tient Update/ Pa Merge [RAD 12] - Patient Update/ - 12] Merge [RAD 12] Patient Update/ Merge [RAD - – Case 3 3: Unidentified Patient Figure 4.4- Significant Transactions: 2115 7], the Department System • On receiving a Modality Procedure Step Completed [RAD- Scheduler/Order Filler recognizes it as an unscheduled case. The Department System Scheduler/Order Filler sends a Filler Order Management (New • ) [RAD- Order 3] transaction to the Order Placer. Using the information from the Procedure Step Completed transaction and the placed • 2120 order, the DSS/Order Filler creates a new Requested Procedure record and sends a Procedure Scheduled transaction to the Image Manager. • new patient and merge the To reconcile the patient information, the ADT may register a temporary patient with the correct patient and send both registration and merge transactions. ____________________________________________________________________________ 90 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

91 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2125 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. 4.4.4 Case 4: Unidentified Patient Assigned Temporary Departmental ID and Scheduled at DSS/Order Filler In this case, no valid Patient ID is available to the Department System Scheduler/Order Filler . It 2130 assigns a temporary Patient ID and a temporary name and schedules the required procedure. Note: The Department System Scheduler/Order Filler must ensure that the assigned temporary Patient ID is unique within its scope. The temporary Patient ID is con . When patient information becomes veyed to the Image Manager 2135 known, the ADT sends new patient information to both the Order Placer and the Department . The Department System Scheduler/Order Filler reconciles System Scheduler/Order Filler received patient in formation with that associated with the temporary Patient ID and merges the permanent patient record with its own temporary one and sends a Patient Update transaction to . At the same time, the Department System the Image Manager and the Report Manager Scheduler/Order Filler generates and submits an order to the Order Placer using a permanent 2140 Patient ID. ____________________________________________________________________________ 91 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

92 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Image Report Order Acquisition ADT Scheduler/ Manager Manager Placer Modality Order Filler Schedule Procedure Procedure Scheduled [RAD - 4] Images - 5] Query Modality Worklist [RAD Acquired Modality Procedure Step Modality Procedure Step Completed [RAD - 7] 7] Completed [RAD - Register J.Smith Patient n Reconciliatio Patient Registration Patient Update/ - 1] [RAD 12] - Merge [RAD 12] Patient Update/ Merge [RAD - Filler Order Management - - New [RAD 3] Procedure Update - [RAD 13] – Case 4 4: Unidentified Patient Figure 4.4- Significant Transactions: t System Scheduler/Order • Patient information is reconciled internally by the Departmen 2145 Filler using the Patient Registration from ADT. -12] The Department System Scheduler/Order Filler sends the Patient Update [RAD • transaction to the Image Manager. The Department System Scheduler/Order Filler sends the Filler Order Management (New • 2150 [RAD- Order) 3] transaction to the Order Placer. Case 5: Image Acquisition Completed Without Scheduling at Department 4.4.5 System Scheduler/Order Filler In this case, no valid Patient ID is available to the Department System Scheduler/Ord er Filler and no scheduling is done before the procedure is performed. A temporary ID and name are entered ____________________________________________________________________________ 92 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc. Rev. 1

93 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2155 by the technologist at the Modality and conveyed to the Department System Scheduler/Order e selected by the technologist Filler and to the Image Manager. The Patient ID and name ar 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 ment System Scheduler/Order Filler. uniqueness within the scope of Depart 2160 Upon receiving the Modality Procedure Step Completed message, the DSS/Order Filler and Image Manager recognize an unscheduled case based on the content of the message (absent or . When patient information F-2: Appendix A) empty Referenced Study Sequence, see RAD T 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 2165 t record with the temporary one and sends a Patient performs a merge of the permanent patien . At the same time, Department System Update to the Image Manager and the Report Manager Scheduler/Order Filler generates and submits an order to the Order Placer using a valid Patient ID. ____________________________________________________________________________ 93 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

94 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Image Order Report Acquisition ADT Scheduler/ Order Manager Placer Manager Modality Filler Images Acquired Modality Procedure Step 7] Completed [RAD - Register J.Smith Modality Procedure Patient Step Reconciliation Patient Registration Completed - [RAD 1] 7] - [RAD Patient Update/ - Merge [RAD 12] Patient Update/ Merge [RAD 12] - Filler Order Management – 3] - New [RAD Procedure Scheduled [RAD - 4] 2170 Case 5 Figure 4.4- 5: Unidentified Patient – Significant Transactions: • On receiving a Procedure Step Completed transaction, the Department System Scheduler/Order Filler recognizes it as an unscheduled case. 2175 • rnally by the Department System Scheduler/Order Patient information is reconciled inte 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. ____________________________________________________________________________ 94 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

95 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The Department System Scheduler/Order Filler sends a Filler Order Management (New • 3] transaction to the Order Placer. Order) [RAD- 2180 Using the information from the Procedure Step Completed transaction and placed order, • the Department System Scheduler/Order Filler c reates a new Requested Procedure record -4] transaction to the Image Manager and Report and sends a Procedure Scheduled [RAD Manager. Case 6: Patient Information Reconciliation During Image Acquisition 4.4.6 2185 Updates may need to occur after the initial Patient Reg istration 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 . The Im age Manager will need to continue updating the Registration and Order information 2190 patient information from items retrieved from the Image Archive. Significant Transactions: The Modality may continue to send information using the original patient information • occurred. even after the patient update has The Image Manager must continue reconciling Patient Information even after the Patient • 2195 Update transaction has been completed. Only partial transactions are shown. Other transactions are performed according to the profile requirements. ____________________________________________________________________________ 95 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

96 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Order Department System Image Manager/ ADT Modality Placer Image Scheduler/ Order Filler Archive - Query Modality Worklist [RAD 5] Perform Acquisition Modality Procedure Step Modality Procedure Step 7] - Completed [RAD Completed [RA D - 7] Modify Patient Modality Images Stored [RAD - 8] Patient Update - 12] - Merge [RAD Patient Update/ - 12] rge [RAD Me Perform Patient Reconciliation Perform Acquisition (Append) Modality Procedure Step Modality Procedure Step Completed [RAD Completed [RAD - 7] - 7] Original Patient Data Original Patient Data Modality Images Stored [RAD - 8] Perform Patient Reconciliation 6: Patient Information Reconciliation During Image Acquisition Figure 4.4- 2200 ____________________________________________________________________________ 96 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

97 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Consistent Presentation of Images (CPI) 5 specifies a number of transactions Consistent Presentation of Images Integration Profile The that maintain the consistency o f presentation for grayscale images. The presentation of images depends upon the contrast/brightness and the spatial and graphical operations applied, such as 2205 cal user annotations, shutters, flip/rotate, display area selection, and zoom. The spatial and graphi operations are defined in the Grayscale Softcopy Presentation State. For the consistency of the perceived pixel intensity a standard contrast curve, the Grayscale Standard Display Function, has been defined against which different types of display and hardcopy output devices are calibrated. 2210 This profile is intended to establish consistency between any combination of softcopy and hardcopy displays. In order to guarantee both grayscale contrast/brightness consistency and spatial/ 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 for 2215 s. color image -Processing Profile, when combined with this profile, The Scheduled Workflow Profile or Post 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. 5.1 2220 Actors/Transactions 1 diagrams the actors involved with this profile and the transactions between actors. Figure 5.1- ____________________________________________________________________________ 97 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

98 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Display Evidence Creator Query Images [RAD - 14] ↓ ↓ Creator Image Stored [RAD 18] - ↓ 15] Query Pres. States [RAD - - 19] ↓ Creator Pres. State Stored [RAD Storage Commitment [RAD - ↓ 10] - ↓ Retrieve Images [RAD 16] 14] - Query Images [RAD ↓ 17] Retrieve Pres. States [RAD ↓ - 16] - Retrieve Images [RAD ↓ Image Image Archive Manager 8] Modality Image Stored [RA ↑ - D Storage Commitment [RAD - ↓ 10] - 9] Modality Pres. State Stored [RAD ↑ Acquisition Modality Print Composer ↓ Print Request with Presentation LUT[RAD - 23] Print Server Figure 5.1- 1: Consistent Presentation of Images Diagram Table 5.1- 1 lists the transactions for each actor directly involved in the Consistent Presentation 2225 of Images Integration Profile. In order to claim support of this Integration Profile, an (labeled “R”). Transactions labeled “O” implementation must perform the required transactions 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. Table 5.1- 1: Consistent Presentation of Images - Actors and Transactions 2230 Actors Transactions Optionality TF Reference 4.8 -2: RAD TF R -8] Modality Images Stored [RAD Acquisition Modality Storage Commitment [RAD RAD TF -2: 4.10 -10] R Modality Presentation State Stored R RAD TF -2: 4.9 -9] [RAD Image Manager/ Modality Images Stored [RAD -8] R RAD TF -2: 4.8 Image Archive Storage Commitment [RAD -10] R RAD TF -2: 4.10 4.14 Query Images [RAD -14] R RAD TF -2: -16] Retrieve Images [RAD 4.16 -2: RAD TF R ____________________________________________________________________________ 98 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

99 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Actors Transactions Optionality TF Reference -18] R RAD TF -2: 4.18 Creator Images Stored [RAD R 4.9 -2: Modality Presentation State Stored RAD TF -9] [RAD -15] R RAD TF -2: 4.15 Query Presentation States [RAD - 4.17 -2: R RAD TF Retrieve Presentation States [RAD 17] -2: 4.19 R RAD TF Creator Presentation State Stored [RAD -19] Image Display Query Images [RAD -14] R RAD TF -2: 4.14 Retrieve Images [RAD -16] R RAD TF -2: 4.16 RAD TF Query Presentation States [RAD -15] R -2: 4.15 Retrieve Presentation States [RAD R RAD TF -2: 4.17 - 17] Creator Images Stored [RAD -18] O RAD TF -2: 4.18 Evidence Creator Presentation State Stored RAD TF -2: 4.19 R Creator -19] [RAD R RAD TF -2: 4.10 -10] Storage Commitment [RAD Query Images [RAD -14] O RAD TF -2: 4.14 Retrieve Images [RAD RAD TF -16] O -2: 4.16 Print Composer Print Request with Presentation LUT 4.23 -2: R RAD TF -23] [RAD 4.23 Print Server Print Request with Presentation LUT -2: RAD TF R -23] [RAD Note: 2-1 for other profiles that may be pre -requisites for this profile. Refer to Table 5.2 Consistent Presentation of Images Integration Profile Options 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 in notes. 2235 Table 5.2- 1: Consistent Presentation of Images – Actors and Options TF Reference Actor Options Acquisition Modality No options defined - Image Manager/ Image Archive No options defined - Image Display No options defined - Evidence Creator No options defined - -2: 4.23.4.2.4 RAD TF Print Composer User Specifiable Lighting Condition No options defined Print Server - ____________________________________________________________________________ 99 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

100 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Consistent Presentation of Images Process Flow 5.3 This section describes the typical process flow related to viewing images with Grayscale Softcopy Presentation States and performing image post -processing that may generate new 2240 images and/or Grayscale Softcopy Presentation States. The transactions covered are [ RAD- 14] through [ . 22] RAD- 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; 2245 • Between imaging departments (e.g., Cardiology and Radiology); or Throughout the Healthcare Enterprise to other departments or care providers other than • an imaging department (e.g., Surgery, Neurology, Oncology). enables advanced review as well as simple or sophisticated Consistent Presentation of Images -processing of images along with related objects (such as Grayscale Softcopy Presentation post 2250 States, or Structured Reports) in a variety of clinical scenarios. Examples include the following: • ed on patient identifying information, a clinician wishes to look for imaging studies Bas 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 r • ead wishes to retain viewing parameters including clinical annotations; 2255 • 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 prior imaging 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 2260 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. The appearance of grayscale images displayed on different types of softcopy display devices or n been inconsistent. To address this printed by different types of hardcopy output devices has ofte problem and achieve consistent presentation of grayscale images the DICOM Standard defines: 2265 A standard curve, the Grayscale Standard Display Function, against which different types • should be calibrated; of display and hardcopy output devices • Basic Print Management with Presentation Look Up Table, for controlling the consistent appearance of preformatted images on printed output; 2270 Grayscale Softcopy Presentation State, an object for storing and communicating the • parameters 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 ____________________________________________________________________________ 100 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

101 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ transformations (grayscale transformations, shutter transformations, image annotation, spatial transformations, and display area annotation) that shall be applied when the images are presented on a softcopy display. 2275 The typical use of these capabilities is depicted in Figure 5.3- 1. Image Evidence Print Image PPS Manager/ Creator Manager Display Server Image Archive Print Composer 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 20] - Step In Progress [RAD Image and/or GSPS Creation Creator Images Stored [RAD 18] - 19] - Creator Presentation State Stored [RAD Print Request 23] with Presentation LUT [RAD - Crea tor Procedure Step Completed [RAD - 21] Creator Procedure - 21] Step Completed [RAD - 10] Storage Commitment [RAD Presentation of Images Process Flow 1: Consistent Figure 5.3- ____________________________________________________________________________ 101 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

102 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2280 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 be • 2285 grouped with other actors that have access to images; s which are not part of this The diagram above includes Procedure Step transaction • . The diagram shows one profile, but are defined the associated workflow profile particular sequencing of the Procedure Step Completed transaction. This transaction may SPS) creation. This means it occur at any point after image and/or Presentation State (G 2290 can occur before images and/or GSPS are stored, after storage, after printing as in this example, or even after storage commitment. The Technical Framework does Radiology not specify the timing of this transaction in relation to other transactions. ____________________________________________________________________________ 102 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

103 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 6 Presentation of Grouped Procedures (PGP) 2295 addresses what is Presentation of Grouped Procedures Integration Profile (PGP) The sometimes referred to as the linked studies problem: viewing image subsets resulting from a single acquisitio e.g., n with each image subset related to a different requested procedure ( CT chest, abdomen and pelvis). It provides a mechanism for facilitating workflow when viewing ften for images and reporting on individual requested procedures that an operator has grouped (o 2300 the 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 of images allows separate viewing and interpretation of t he image subsets related to each of the requested procedures. 6.1 Actors/Transactions 2305 1 diagrams the actors involved with this profile and the transactions between actors. Figure 6.1- DSS/ Order Filler 6] - Modality PS in Progress [RAD ↑ ↑ Modality PS Completed [RAD - 7] Performed Procedure Step Manager Image Image Archive Manager 6] Modality PS in Progress [RAD → - 7] - Modality PS Completed [RAD → ↑ Modality Pres. State Stored 9] - [RAD ← 6] - Modality PS in Progress [RAD - 7] eted [RAD Modality PS Compl ← Acquisition Modality iagram Figure 6.1- 1: Presentation of Grouped Procedures D ____________________________________________________________________________ 103 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

104 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1 lists the required transactions for each actor directly involved in the Presentation of .1- Table 6 2310 Grouped Procedures (PGP) Integration Profile. In order to claim support of this Integration nsactions (labeled “R”). Transactions Profile, an implementation must perform the required tra 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 6.2. Table 6.1- 1: Presentation of Grouped Procedures - Actors and Transactions TF Optionality Actors Transactions Reference 4.6 -2: RAD TF Department System Scheduler/ Modality Procedure Step In R Order Filler Progress [RAD-6] (note 1) R 4.7 -2: RAD TF Modality Procedure Step -7] Completed [RAD Modality Procedure Step In 4.6 -2: RAD TF Acquisition Modality R Progress [RAD-6] (note 1) 4.7 -2: RAD TF R Modality Procedure Step Completed [RAD -7] Modality Presentation State RAD TF -2: 4.9 R -9] Stored [RAD Image Manager/ Modality Procedure Step In R 4.6 -2: RAD TF Image Archive See N ote 1) Progress [RAD-6] ( Modality Procedure Step 4.7 -2: RAD TF R -7] Completed [RAD Modality Presentation State RAD TF -2: 4.9 R Stored [RAD -9] Performed Procedure Step Modality Procedure Step In R RAD TF -2: 4.6 [RAD 1) ote Manager (See N Progress -6] Modality Procedure Step 4.7 R RAD TF -2: Completed [RAD -7] Refer to Table -requisites for this profile. 2315 2-1 for other profiles that may be pre Note 1: This transaction has an extension that is required by this actor in this profile. This detailed definition of this extension is in RAD TF -2: 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 Step In Progress/Completed and the Modality Presentation State Stored) requires an Image Display to Procedure 2320 w-aware actors. Such actors may be an Image Manager/Archive or Department be integrated with other workflo -alone Image Display cannot directly benefit from the PGP Integration System Scheduler/Order Filler. A stand -alone Image Display supports the Consistent Presentation of Images . However, if the stand Profile capabilities Integration Profile, it may benefit from the Presentation States generated by the Acquisition Modality implementing the PGP Integration Profile. Presentation of Grouped Procedures Integration Profile Options 2325 6.2 1 along with 6.2- Options that may be selected for this Integration Profile are listed in the Table the Actors to which they apply. ____________________________________________________________________________ 104 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

105 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 6.2- 1: Presentation of Grouped Procedures – Actors and Options Actor Options TF Reference ned No options defi -- Acquisition Modality No options defined Department System Scheduler/ -- Order Filler Image Manager/ -- No options defined Image Archive -- Performed Procedure Step No options defined Manager 6.3 2330 Presentation of Group Procedures Process Flow 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 RAD- Procedure Step acquisition. The transactions covered are [ . 10] RAD- 5] t hrough [ The following use case defines the PGP transaction flow: 2335 • When a number of Scheduled Procedure Steps, each corresponding to a different Requested Procedure, are grouped by a technologist and result in the acquisition of images 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 • 2340 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. • y create one or more Grayscale For each of the Requested Procedures, the operator ma Softcopy Presentation States in order to define the corresponding viewing parameters applicable to a subset of images related to the Requested Procedure. These Grayscale 2345 Softcopy Presentation States shall be associated with a specific Performed Procedure Step related to the Requested Procedure. The following example illustrates the PGP flow: 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 the 2350 operator 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 the chest presentation state. A Procedure Step Completed t ransaction related to this chest view would then be sent to the Image Manager and to the Department System 2355 . Likewise for the abdomen and the pelvis, thus resulting in four Scheduler/Order Filler hree PPS each related to the PPS, one for the images of the three grouped procedures and t presentation states. Finally, the images and GSPSes are stored in the Image Archive and Storage Commitment is performed. ____________________________________________________________________________ 105 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

106 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • A reading physician may use the GSPSes (associated with the Requested Procedure 2360 action) created by the technologist to facilitate viewing and indicated in the PPS trans interpreting 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 st eps describes the typical process flow involved in Presentation of Grouped Procedures: ____________________________________________________________________________ 106 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

107 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Acquisition Image Manager/ Scheduler/ Order Modality Image Archive Filler Query Modality 5] Worklist [RAD - Modality Procedure Step Modality Procedure Step In Progress [RAD 6] - - 6] In Progress [RAD Perform Acquisition Modality Images Stored [RAD - 8] Modality Procedure Step Modality Procedure Step 7] - Completed [RAD Completed [RAD - 7] Storage Commitment 10] [RAD - Modality Procedure Step Modality Procedure Step 6] - In Progress [RAD In Progress [RAD - 6] Create GSPS This set of Modality Presenta tion transactions State Stored [RAD 9] - would be repeated 3 t imes (once for each of the three Modality Procedure Step presentation Modality Procedure Step Completed [RAD - 7] states in the - 7] Completed [RAD example. Storage Commitment [RAD - 10] 2365 1: Presentation of Grouped Procedures Process Flow Figure 6.3- ____________________________________________________________________________ 107 8-07-27 : IHE International, Inc. – Final Text 201 7.0 Rev. 1 Copyright © 2018

108 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 7 Access to Radiology Information (ARI) The Access to Radiology Information Integr ation Profile specifies a number of query transactions providing access to radiology information, including images and related reports, in a 2370 . Such access is useful both to the radiology DICOM format as they were acquired or created 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. Actors/Transactions 7.1 Figure 7.1- 1 diagrams the actors involved with this profile and the transactions between actors. 2375 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 s. Image Display and Image Manager/ Image Archi ve Actor Image Display ↓ xx: Content Query - RAD ↓ RAD - yy: Content Retrieve Image Image Archive Manager Report Repository External Report Repository Access ↑ - RAD 26: Query Reports - RAD ↑ 26: Query Reports RAD - 27: Retrieve Reports ↑ - 27: Retrieve Reports RAD ↑ Report Reader 2380 1: Access to Radiology Information Diagram Figure 7.1- ____________________________________________________________________________ 108 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

109 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 7.1- 1 lists the transactions for each actor directly involved in the Access to Radiology Integration Profile, an 2385 Information Integration Profile. In order to claim support of this implementation 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 in Section 7.2. 1: Access to Radiology Information - Actors and Transactions Table 7.1- Actors Optionality TF Reference Transactions 4.26 Report Reader Query Reports [RAD -26] R RAD TF -2: -27] R RAD TF -2: 4.27 Retrieve Reports [RAD Report Repository Query Reports [RAD -26] 4.26 R RAD TF -2: Retrieve Reports [RAD -27] R RAD TF -2: 4.27 4.26 External Report Repository RAD TF R Query Reports [RAD -26] -2: Access RAD TF R -27] Retrieve Reports [RAD 4.27 -2: Image Display Required transactions depend on the Content Profiles supported Image Manager/ Required transactions depend on the Content Profiles supported Image Archive 2-1 for other profiles that may be pre Note: Refer to Table -requisites for this profile. 2390 The Image Display and Image Manager/ Archive Actor s are required to support the Query/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 . 2395 ions Access to Radiology Information Integration Profile Opt 7.2 1 along with Options that may be selected for this Integration Profile are listed in the Table 7.2- . Dependencies between options when applicable are specified in the Actors to which they apply notes. 1: Access to Radiology Information - Actors and Options 2400 Table 7.2- Actor Options TF Reference Image Display Multiple Sources RAD TF -1: 7.3.1 Image Manager/ No options defined Image Archive -1: 7.3.1 Multiple Sources RAD TF Report Reader Report Repository No options defined No options defined External Report Repository Access - ____________________________________________________________________________ 109 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

110 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Multiple Sources Option 7.3 This option requires Image Displays and Report Readers to support query and retrieve from multiple 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, a 2405 single Image Manager/Image Archive. An Image Display that implements this option supports a - ultrasound mini user that desires to view information consolidated from multiple sources ( e.g., PACS, cardiology PACS, and radiology PACS). Querying multiple sources also provides an opportunity for an Image Display to access objects 2410 stored in a “legacy” archive that has been replaced by, and is possibly having its information migrated to, a new Image Manager/Image Archive. 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 and retrieve from multiple Image Manager/Image Archives. 2415 In order to claim support for this profile option, a Report Reader shall be able to query and retrieve from multiple Report Repositories. There is no requirement as to whether the multiple queries or retrieves are done concurrently or sequentially. lays and Report Readers shall have the ability to be configured to access multiple Image Disp Image Manager/Image Archives and Report Repositories (respectively). 2420 Image Managers and Report Managers shall also support the Patient Information Reconciliation integratio n profile in order to ensure that the information gathered from them is as accurate as . Since having actors in different ADT (patient identifier) domains could result in possible unpredictable query results, this option assumes that all actors are members of the same ADT 2425 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 initially query 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 to 2430 trigger a query of multiple sources for both images (and anything else stored in an Image Manager/Image Archive) and reports. If communication with an information source fails, an Image Display or Report Reader shall . In addition, the Image Display and provide the information it received from the other sources Report Reader shall in form the user that they are viewing potentially incomplete results. -level or series 2435 -level query to When an Image Display or Report Reader performs a study multiple 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 the study/series an Image Display and Report Reader shall collate the information, determine if the ____________________________________________________________________________ 110 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

111 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 2440 The consolidated view of results may be shown and updated either as responses are received or when the final response has been received from the last responding information source. A participating Image Display or Report Reader shall manage duplicate instances in a manner that avoids redundant retrieval. 2445 ____________________________________________________________________________ 111 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

112 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Key Image Note (KIN) 8 specifies transactions that allow a user to mark one or Key Image Note Integration Profile The more images in a study as significant by attaching to them a note managed together with the study . This note includes a title stating the purpose of marking the images and, optionally, a user 2450 comment field . Physicians may attach Key Image Notes to images for a variety of purposes: referring physici an access, teaching files selection, consultation with other departments, and image 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 t he Section 14) for a description of general evidence document Evidence Documents Profile ( 2455 handling. 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 2460 Workflow). 8.1 Actors/Transactions Figure 8.1- 1 diagrams the actors involved with this profile and the transactions between actors. Image Display Evidence Creator [RAD ↓ Query Images 14] - Commitment: Storage Store Key Image Note ↓ ↓ Retrieve Images - 16] [RAD [ 10 - RAD ↓ ] - [RAD 29] 30] ↓ Query Key Image Notes [RAD - [RAD eve Key Image Notes Retri ↓ 31] - Image Image Archive Manager Storage Commitment Note [ ↑ Store Key Image - 29] RAD [ RAD - 10 ] ↑ Acquisition Modality 2465 Figure 8.1- 1: Key Image Note Diagram ____________________________________________________________________________ 112 : IHE International, Inc. 7.0 – Final Text 201 Rev. 1 Copyright © 2018 8-07-27

113 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1 lists the transactions for each actor directly involved in the Key Image Notes Table 8.1- Integration Profile. In order to claim support of this Integrati on 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 Section 8.2. 2470 1: Key Image Note Integration Profile - Actors and Transactions Table 8.1- TF Transactions Optionality Actors Reference RAD TF -10] R Acquisition Modality -2: 4.10 Storage Commitment [RAD [RAD -29] R RAD TF -2: 4.29 Key Image Note Stored Evidence Creator Storage Commitment [RAD -10] R RAD TF -2: 4.10 Key Image Note Stored -29] R RAD TF -2: 4.29 [RAD Image Manager/ Image Archive 4.10 Storage Commitment [RAD -10] R RAD TF -2: Image Archive Query Images [RAD -14] R RAD TF -2: 4.14 Retrieve Images [RAD -16] R RAD TF -2: 4.16 Key Image Note Stored 4.29 -2: RAD TF R -29] [RAD Query Key Image Notes [RAD R RAD TF -2: 4.30 -30] -31] R RAD TF -2: 4.31 Retrieve Key Image Notes [RAD Query Images [RAD -14] Image Display R RAD TF -2: 4.14 Retrieve Images [RAD -16] R RAD TF -2: 4.16 4.30 Query Key Image Notes [RAD -30] R RAD TF -2: 4.31 -2: RAD TF -31] Retrieve Key Image Note [RAD R Refer to Table -requisites for this profile. 2-1 for other profiles that may be pre 8.2 Key Image Notes Integration Profile Options 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 in 2475 notes. Table 8.2- - Actors and Options 1: Key Image Notes Actor Options TF Reference Acquisition Modality No options defined - Evidence Creator No options defined - No options defined - Image Manager/ Image Archive - No options defined Image Display ____________________________________________________________________________ 113 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

114 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Key Image Note Pattern 8.3 The Key Image Note allows a user to mark one or more images in a study as significant by attaching to them one or more notes managed together with the study. Each note includes a title 2480 stating the purpose of marking the images and a user comment. Physicians may attach Key es for a variety of purposes: referring physician access, teaching files Image Notes to imag selection, consultation with other departments, and image quality issues, etc. The list of titles why the images are being marked is defined by DICOM and is contained in CID used to describe 7010 (Key Object Selection Document Title) in DICOM PS3.16. 2485 A single Key Image Note may reference several images within a study. Multiple Key Image Notes may reference the same image. reference to a specific When a Key Image Note refers to an image, it may also include a Presentation State for the image thus ensuring that the Key Image Note includes significant 2490 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 2-1 and shall use the DICOM Key 8- 2495 Object Selection Document SOP Class definition. The marked images of a study are those referenced 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 2500 Identical Documents Sequence is required per the DICOM Standard. 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 is beyond 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 to 2505 support 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 Observation Context (CONTAINER) 1 CONTAINS 0-1 1-n Image Reference Key Image Description (IMAGE) (TEXT) Figure 8.3- 1: Key Image Note Pattern ____________________________________________________________________________ 114 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

115 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2510 Simple Image and Numeric Report (SINR) 9 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 of reporting into discrete s for creation, management, storage and viewing . Separating these functions while defining transactions to exchange the reports between them enables a vendor to include one or more of these functions in an actual system. 2515 Reports exchanged have a simple structure attractive to many imaging departments: a title, an observation 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 to facilitate computer searches . Such reports can be input to the formal diagnostic report, thus 2520 -entry of information. avoiding re 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 the Reporting Workflow Integration Profile). Actors/Transactions 9.1 Figure 9.1- 1 diagrams the actors involved with this profile and the transactions between actors. 2525 Report Creator ↓ - 24: Report Submission RAD ↓ 28 Structured Report Export: RAD - Report Manager Enterprise Report Repository RAD - 25: Report Issuing ↓ ↑ 26: Query Reports - RAD Report Repository External Report Repository Access 27: Retrieve Reports ↑ - RAD RAD ↑ - 26: Query Reports ↑ RAD 26: Query Reports - ↑ RAD - 27: Retrieve Reports RAD - ↑ 27: Retrieve Reports Report Reader Figure 9.1- 1: Simple Image and Numeric Report Diagram 2530 ____________________________________________________________________________ 115 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

116 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ and 1 lists the transactions for each actor directly involved in the Simple Image Table 9.1- Numeric Report Integration Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” ation Profile and that are optional . A complete list of options defined by this Integr 2535 implementations may choose to support is listed in Section 9.2. Table 9.1- 1: Simple Image and Numeric Report - Actors and Transactions TF Transactions Optionality Actors Reference -2: -24] R RAD TF Report Creator 4.24 Report Submission [RAD Report Manager Report Submission [RAD -24] R RAD TF -2: 4.24 Report Issuing [RAD -25] R RAD TF -2: 4.25 Query Reports [RAD -26] R RAD TF -2: 4.26 Retrieve Reports [RAD R RAD TF -2: 4.27 -27] Structured Report Export 4.28 -2: O RAD TF [RAD -28] Report Reader Query Reports [RAD -26] R RAD TF -2: 4.26 Retrieve Reports [RAD -27] R RAD TF -2: 4.27 RAD TF R -25] Report Issuing [RAD Report Repository 4.25 -2: Query Reports [RAD R RAD TF -2: 4.26 -26] RAD TF R Retrieve Reports [RAD -2: 4.27 -27] External Report Repository Query Reports [RAD -26] R RAD TF -2: 4.26 Access -2: Retrieve Reports [RAD R RAD TF -27] 4.27 Structured Report Export Enterprise Report Repository 4.28 -2: RAD TF R -28] [RAD Refer to Table -requisites for this profile. 2-1 for other profiles that may be pre Simple Image and Numeric Report Integration Profile Options 9.2 Options that may be selected for this Integration Profile are listed in the Table 9.2- 1 along with 2540 the a ctors to which they a pply . Dependencies between options when applicable are specified in notes. 1: Simple Image and Numeric Report - Actors and Options Table 9.2- TF Reference Options Actor Enterprise Report Repository No options defined - External Report Repository Access No options defined - Report Creator Enhanced SR RAD TF -2: 4.24.4.1.2 Report Manager No options defined - RAD TF -2: 4.27.4.2.2 Enhanced SR Report Reader No options defined Report Repository - ____________________________________________________________________________ 116 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

117 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2545 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 a reference in the IHE Integration Statement (see A ppendix D). Diagnostic 9.3 Report Process Flow This section describes the typical process flow related to diagnostic reporting. The transactions . 2550 27] [RAD- RAD- through [ 24] covered are In the initial stage of diagnostic reporting, a reading physician records the diagnosis by ng a draft DICOM Structured Report object, which is submitted to the Report Manager. generati Once a report is sent to the Report Manager, the Report Creator relinquishes control of the report to the Report Manager. erred to as “reports” and may be encoded There are other documents which are sometimes ref 2555 using DICOM SR (for example, procedure reports, CAD results and echocardiography measurement reports) however such documents do not follow the same kind of verification and . These other documents serve different purposes and distribution process described in this profile . Profile are instead addressed in the Evidence Documents 2560 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 the Report 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 a minimum the final report must be sent to the Report Repository. A Report Creator can 2565 effectively amend a report by submitting a new SR SOP Instance. The Report Repository provides permanent storage of DICOM Structured Reports. It also allows ved throughout the enterprise by Report Readers. A Report reports to be queried and retrie Reader provides a user interface to view DICOM Structured Reports that it retrieves from the Report Repository or External Report Repository Access. y to obtain other enterprise department 2570 The External Report Repository Access is a gatewa 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 R epository receives diagnostic reports in HL7 format. The Simple Image Report and Simple Image and Numeric Reports are required minimally to 2575 have the functionality defined in template TID 2000. Creators may introduce increased rms to the SOP class. The templates referenced in the Technical complexity as long as it confo Framework are included in DICOM Part 16. ____________________________________________________________________________ 117 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

118 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Report Report Report Report External Report Enterprise Repository Report Creator Manager Repository Reader Repository Access Report Creation Report - Submission [RAD 24] Report Issuing 25] [RAD - Report Modification or Verification Report Issuing [RAD - 25] - Structured Report Export [RAD 28] Query Reports [RA D - 26] 27] - Retrieve Reports [RAD View Reports Query Reports [RAD - 26] - 27] Retrieve Reports [RAD View Reports 2580 Figure 9.3- 1: Diagnostic Reporting Process Flow ____________________________________________________________________________ 118 8-07-27 Rev. 1 7.0 : IHE International, Inc. Copyright © 2018 – Final Text 201

119 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Diagnostic Reporting Use Cases 9.4 DICOM Structured Reports offer the capabilit y to encode arbitrarily structured diagnostic report data. The Radiology 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. 2585 rams in the following sections define the report content pattern and utilize the following The diag conventions: Each rectangle is a single Content Item. • Italic text in a rectangle denotes a generic grouping of Concept Names to be used for the • 2590 ust be configurable in the reporting actors. Content Item. These m • 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). • ines defines the relationship between Content Items. Text on l 2595 • Numbers on lines define the cardinality of descendent Content Items. Simple Image Report 9.4.1 The Simple Image Report allows documents with multiple sections (with headings) containing report text and referen ces 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 from which their conclusions were inferred. This content pattern is shown in Figure 2600 1 and shall 9.4- use the DICOM Basic Text SR Information Object Definition and Basic Image Diagnostic Report Template (TID 2000 in DICOM PS3.16). Note that TID 2000 has other requirements not shown in the diagram. ____________________________________________________________________________ 119 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

120 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ HAS OBS CONTEXT Observation Context Document Title (See section 9.3.3) (CONTAINER) 1 CONTAINS 1 - n HAS OBS CONTEXT Observation Context Section Heading (See section 9.3.3) (CONTAINER) 0 1 - CONTAINS 0 n - n - 0 0 - n Image Reference Report Text Coded Entry (TEXT) (IMAGE) (CODE) INFERRED FROM INFERRED FROM n 0 - 0 - n Image Reference Image Reference (IMAGE ) (IMAGE) 1: Simple Image 2605 Figure 9.4- Report Pattern Simple Image and Numeric Report 9.4.2 The Simple Image and Numeric Report is similar to the Simple Image Report described in 9.3.1 but allows the addition of numeric values. This enables a diagnosis to include Section c values. Like the Simple Image Report, particular text values measurements and other numeri 2610 can be encoded to signify that they are inferred from specific images or numeric values. This 2 and shall use the DICOM Enhanced SR Information 9.4- content pattern is shown in Figure inition and Basic Image Diagnostic Report Template (TID 2000 in DICOM PS3.16). Object Def Note that TID 2000 has other requirements not shown in the diagram. ____________________________________________________________________________ 120 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

121 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ HAS OBS CONTEXT Document Title Observation Context (See section 9.3.3) (CONTAINER) 1 - 1 n CONTAINS HAS OBS CONTEXT Section Heading Observation Context (CONTAINER) (See section 9.3.3) 1 - 0 CONTAINS n 0 - n - 0 0 - n n 0 - Coded Entry Measurement Image Reference Report Text (CODE) (NUM) (IMAGE) (TEXT) INFERRED FROM INFERRED FROM 0 - n n - 0 n 0 - n 0 - Measurement ference Image Re Measurement Image Reference (NUM) (IMAGE) (NUM) (IMAGE) 2615 2: Simple Image and Numeric Report Pattern Figure 9.4- Observation Context 9.4.3 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 2620 template is contained in DICOM PS3.16: DICOM Content Mapping Resource (DCMR). Observation context content items may be descended from the root content item, and may be superseded by subsequent observation contexts at the section level . Therefore, the observation context may change throughout the report. This capability allows one report to include, for 2625 example, observations on a mother and fetus, observations by multiple observers, or observations from multiple studies. ____________________________________________________________________________ 121 Rev. 1 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0

122 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 10 DEPRECATED Basic Security (SEC) - -Audit Trail and n ITI This profile has been superseded by the Radiology Audit Trail Option i -3: 5.1 for a detailed description of the Radiology Node Authentication Profile (see RAD TF Audit Trail Option). 2630 ____________________________________________________________________________ 122 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

123 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Charge Posting (CHG) 11 The specifies information exchange from the Department Charge Posting Integration Profile System Scheduler/Ord er Filler to the Charge Processor about charges associated with particular 2635 procedures, as well as communication about patient demographics, accounts, insurance, and guarantors between ADT Patient Registration and Charge Processor . The Charge Posted Transaction contains some information to generate a claim. Currently, these interfaces contain . The goal of including this in the Radiology -like data fixed field formatted or HL7 Technical 2640 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 have . The result is that the Cha rge Processor will receive more knowledge of the radiology internals complete, timely and accurate data. The Department System Scheduler/Order Filler indicates to the Charge Processor that procedures are available for Technical and/or Professional billing 2645 cur . The Charge Posted transaction may oc . Regulations and site operating procedures determine when a at various times in the workflow procedure is eligible for Charge Posting . Often, the events are different for technical and professional charges . Technical charges are typically eligible at procedure completion. 2650 . 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. ____________________________________________________________________________ 123 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

124 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 11.1 ansactions Actors/Tr 2655 ADT Report Manager ↓ RAD - 36: Account 42: Performed Work - ↓ RAD Management Status Update ler DSS/Order Fil ↑ RAD 6: Modality PS In Progress - Post - ↑ RAD - 7: Modality PS Completed Processing Charge Processor RAD → 35: - 20: Creator PS In Progress - RAD ↑ Manager Charge Posted ↑ RAD - 21: Creator PS Completed 59 Import PS In Progress - RAD ↑ ↑ RAD - 60: Import PS Completed 39: Workitem Completed - RAD ↑ RAD ← 20: Creator PS In Progress - RAD - : Creator PS Completed 21 ← Performed Evidence Creator Procedure Step Manager 6: Modality PS In Progress - ← RAD RAD ← - 7: Modality PS Completed Acquisition Modality RAD 59 Import PS In Progress - ← RAD Import PS Completed 60: - ← Importer Figure 11.1- 1: Charge Posting Transaction Diagram 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 the . A complete list of 2660 required transactions (labeled “R”). Transactions labeled “O” are optional options defined by this Integration Profile and that implementations may choose to support is listed in Section 11.2. Actors and Transactions Table 11.1- 1: Charge Posting – Actors Transactions Optionality TF Reference 4.36 -36] -3: ADT Patient Registration Account Management [RAD RAD TF R Department System RAD TF -3: 4.35 (note 5) R Charge Posted [RAD -35] Scheduler/ Modality Procedure Step In Progress 4.6 -2: RAD TF R Order Filler/Performed -6] [RAD ____________________________________________________________________________ 124 Copyright © 2018 8-07-27 : IHE International, Inc. – Final Text 201 7.0 Rev. 1

125 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Transactions Optionality Actors TF Reference Procedure Step Manager 4.7 Modality Procedure Step Completed RAD TF R -2: (note 3) [RAD -7] (note 2) -20] 4.20 R RAD TF -2: Creator PS In Progress [RAD Creator PS Completed [RAD R RAD TF -2: 4.21 -21] Performed Work Status Update 4.42 -3: R RAD TF -42] [RAD R RAD TF -3: 4.59 Import Procedure Step In Progress -59] [RAD R RAD TF -3: 4.60 Import Procedure Step Completed [RAD -60] (note 4) Modality Procedure Step In Progress Acquisition Modality R RAD TF -2: 4.6 -6] (note 1) [RAD R RAD TF -2: 4.7 Modality Procedure Step Completed [RAD -7] Performed Work Status Update 4.42 -3: RAD TF R Report Manager -42] [RAD -20] Creator PS In Progress [RAD Evidence Creator 4.20 -2: RAD TF R RAD TF -21] R Completed [RAD -2: 4.21 Creator PS -Processing Manager -3: 4.39 Post Workitem Completed [RAD -39] R RAD TF (note 3) Charge Processor Charge Posted [RAD -35] (note 5) R RAD TF -3: 4.35 Account Management [RAD -36] R RAD TF -3: 4.36 Step In Progress RAD TF R -3: 4.59 Importer Import Procedure [RAD -59] R RAD TF -3: 4.60 Import Procedure Step Completed [RAD -60] (note 4) 2-1 for other profiles that may be pre -requisites for this profile. Refer to Table Note: Note 1 : An Acquisition Modality that claims the Charge Posting Profile shall support the Assisted Protocol Setting Option 2665 (see RAD TF -2: 4.6.4.1.2.4.2) . : In the transaction, the DSS/Order Filler shall use the Billing and Material Management information supplied by the Note 2 -2: 4.7.4.1.3.2 -2: 4.7.4.1.3.2) or the Importer (see RAD TF AD TF -3: RAD TF and Acquisition Modality (see R 4.60.4.1.3.2) Note 3: The Post -Processing Manager participates in this profile only if the Post Processing Workflow Integration Profile is 2670 pported. In this case, the Post -Processing Manager shall be grouped with the -requisite profiles su one of the pre DSS/ Order Filler. Note 4 : To claim the Charge Posting Profile, the Importer shall support the Billing and Material Management Option (see RAD TF -3: 4.60.4.1.2.3). 2675 Note 5: The DSS -35]. ( -3: See RAD TF /Order Filler and Charge Processor shall support the HL7v2.3.1 semantics for [RAD 4.35.4.1.2). Charge Posting Integration Profile Options 11.2 h 1 along wit 11.2- Options that may be selected for this Integration Profile are listed in the Table . Dependencies between options when applicable are specified in the Actors to which they apply notes. 2680 ____________________________________________________________________________ 125 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

126 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 11.2- 1: Charge Posting – Actors and Options TF Reference Options Actor - No options defined ADT Patient Registration Department System Scheduler/ - No options defined Order Filler -2: 4.7 PPS Exception Management RAD TF Acquisition Modality Modality Group Case -2: 4.6 RAD TF RAD TF -2: 4.7.1.2.3 Billing and Material Management - Performed Procedure Step Manager No options defined Creator (N ote 1) Evidence - No options defined Report Manager No options defined - - No options defined Charge Processor Billing and Material Management Importer -3: RAD TF .4.1.2.3 4.60 : The Billing and Materials Management Option may in some cases also apply to an Evidence Creator Actor in Note 1 . However, it is at this time not specified. Charge Posting ____________________________________________________________________________ 126 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

127 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Charge Posting Process Flow 11.3 Acquisition Perfor med DSS/ Order Charge Ev idence Report Importer A DT M o d alit y Procedure Processor Creator Manager Filler Step Manager Account Management Patient Reg istration Charge Posted Import Import Procedur e Step Procedure Step Co mpleted Co mpleted Charge Posted Modality Modality Procedure Step Procedure Step Co mpleted Co mpleted Charge Posted Creator PP S Co mpleted Creator PP S Co mpleted Charge Posted Repo rting Perfor med W ork Completed Status Update Charge Posted 2685 1: Charge Posting Process Flow Figure 11.3- ____________________________________________________________________________ 127 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

128 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. Use Cases 11.3.1 2690 This section describes the potential use cases relating to the charge posting functionality. It is the partment System Scheduler/Order Filler to ensure that the billing responsibility of the De information 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. sor shall accept the Charge Posted Transaction information. Interpretation and 2695 The Charge Proces subsequent billing processes by the Charge Processor are beyond the scope of this profile. Below are listed the typical use cases: A Department System Scheduler/Order Filler mak es technical charges available for • posting when the modality has completed the procedure. 2700 A Department System Scheduler/Order Filler makes professional charges available for • . posting at time of report verification onal charges available at time of result A site makes both technical and professi • verification. A site may have a single charge that comprises both the technical and professional • 2705 . components Technical Billing 11.3.2 e. These Technical charges are based on the procedure and often include typical materials usag 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 2710 . Addi tionally, a site may wish to Filler receives confirmation that the procedure is completed send information on materials used during a procedure to the Charge Processor for inclusion with the 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. 11.3.3 2715 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 Transacti on. The Professional Billing Charge Posted Transaction can be sent any time after the Department System Scheduler/Order Filler receives confirmation from the Report Manager that the report 2720 eport Manager with has been completed and verified. This may be done by grouping the R Department System Scheduler. country specific procedure coding scheme. IHE specifies a non- that Note The Charge Posted Transaction defines the below sources of information: ____________________________________________________________________________ 128 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

129 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient Order Information • • 2725 Scheduling and Requested Procedure Scheduling and Scheduled Procedure Step • • Modality Performed Procedure Step • - Completed / Discontinued Status Information Protocol Code • 2730 Consumables • Optionally, additional manual input or processing by the Department System • Scheduler/Order Filler or Charge Posting Data Model f 11.4 Technical Framework for the HL7 messages used in The data model adopted by the Radiology the Charge Posting Profile is based on a subset of HL7 v2.3.1 as described is 2735 Section 11.3.1. 11.4.1 Model of the Real World of the real world within scope of the Charge Posting Profile. 1 depicts the model Figure 11.4- This model corresponds to the approach suggested in the HL7 standard, in particular: • 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. 2740 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 a one visit. There may be one charge posted for multiple procedures and one result of procedure to be charged in multiple charge postings, for example, for Technical and 2745 Professional charges. y Requested Procedures may be Billable Procedures. One Requested Procedure ma • correspond to more than one Billable Procedure. ____________________________________________________________________________ 129 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

130 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient 1 Has - 0 n Account 1 Encompasses 1 - n Visit 1 has n 1 - Requested Procedur e Is a Billable Procedure - 0 n 1 1 - n is composed of 1 - m Procedure Charge 2750 1: Model of the Real World for Charge Posting Figure 11.4- ____________________________________________________________________________ 130 7.0 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 Rev. 1

131 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 12 -Processing Workflow (PWF) Post As of June 2012, IHE introduces a new Trial Implementation Profile : IMPORTANT NOTE: , 2755 . The use cases addressed are largely the same as PWF -Acquisition Workflow (PAWF) Post . The PWF Profile documented in this section but the underlying mechanisms are improved 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 2760 The Post -Processing Workflow Integration Profile addresses the need to schedule and track the status of the typical post -processing workflow steps, such as Computer Aided Detection or klists for each of these tasks are generated and can be queried, workitems . Wor Image Processing can be selected and the resulting status returned from the system performing the work to the 2765 . Typically the workitems will involve the creation of objects s system managing the work uch as images and evidence documents . The created images and evidence documents contain the necessary references for maintaining continuity of order information. The Post -Processing Workflow Integration Profile is a continuation of the Scheduled Workflow Integration Profile. 2770 Actors/Transactions 12.1 -Processing Workflow Integration 1 shows the actors directly involved in the Post Figure 12.1- Profile and the relevant transactions between them . The italicized transactions represent a e transactions. The specific transactions required are dependent on “generic” set of query/ retriev which specific content profile(s) are supported by the Image Display and Image Manager/ Image s. Archive Actor 2775 ____________________________________________________________________________ 131 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

132 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ v → RAD - 11: Images Availability Query ← RAD - 42: Performed Work Status Update → Image Ima ge DSS/Order Filler Archive Manager - Processing Post Manager 37: Query P - RAD ost ↑ - Processing Worklist - RAD 10: RAD ↑ 38: Workitem Claimed - ↑ Storage Commitment RAD 40: Workitem PPS In Progress - ↑ - RAD 41: Workitem PPS Completed ↑ 39: Workitem Completed RAD - ↑ Evidence - RAD ↑ 18: Creator Images Stored Creator 14: Query Images ↑ - RAD - 16: Retrieve Images RAD ↑ RAD xx: Query Other Content - ↑ Image Display yy: Retrieve Other Content ↑ RAD - am -Processing Workflow Actor Diagr 1: Post Figure 12.1- 1 lists the transactions for each actor directly involved in the Post -Processing Table 12.1- Integration Profile. In order to claim support of this Integration Profile, an implementation must 2780 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 12.2. - Actors and Transactions 1: Post Table 12.1- -Processing Integration Profile Transactio ns Optionality TF Reference Actors Department System 4.11 RAD TF -2: Images Availability Query [RAD -11] R Scheduler/ R Performed Work Status Update (Send) 4.42 -3: RAD TF Order Filler -42] [RAD Image Manager/ 4.11 RAD TF -2: R -11] Images Availability Query [RAD Image Archive -14] O RAD TF -2: 4.14 Query Images [RAD Retrieve Images [RAD -16] O RAD TF -2: 4.16 O Creator Images Stored [RAD -18] RAD TF -2: 4.18 -10] O RAD TF -2: 4.10 Storage Commitment [RAD Performed Work Status Update (Send) 4.42 -3: RAD TF R -42] [RAD O Evidence -14] Query Images [RAD 4.14 -2: RAD TF ____________________________________________________________________________ 132 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

133 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Reference ns Transactio Actors Optionality Creator/Image Retrieve Images [RAD -16] O RAD TF -2: 4.16 Display -18] O RAD TF -2: 4.18 Creator Images Stored [RAD -10] O RAD TF -2: 4.10 Storage Commitment [RAD Query Post -Processing Worklist [RAD 4.37 -3: R - RAD TF 37] -38] R Workitem Claimed [RAD RAD TF -3: 4.38 Workitem PPS In Progress [RAD -40] R RAD TF -3: 4.40 -41] R [RAD RAD TF -3: 4.41 Workitem PPS Completed Workitem Completed [RAD -39] R RAD TF -3: 4.39 [RAD -Processing Worklist Query Post 4.37 -3: RAD TF R - Post -Processing Manager 37] Workitem Claimed [RAD 4.38 R RAD TF -3: -38] 4.40 R -40] -3: RAD TF Workitem PPS In Progress [RAD Workitem PPS Completed [RAD -41] 4.41 R RAD TF -3: R [RAD -39] -3: RAD TF Workitem Completed 4.39 Note: -requisites for this profile. 2-1 for other profiles that may be pre Refer to Table 2785 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 Actor s may also support the Consistent Presentation of Images or Key Image Note Profile s. In that case, the Evidence Creator 2790 is expected to create GSPS and Key Image Note objects as part of its scheduled workitems . The Image Display and Image Manager Actor s would be expected to store, commit, query, retrieve and display those objects as described in the relevant profiles. The s cenarios 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 2795 as the corresponding image object related transactions. 12.2 -Processing Workflow Integration Profile Options Post Options that may be selected for this Integration Profile are listed in the table below along with the Actors to which they apply. – Actors and Options Table 12.2- 1: Post -Processing Integration Profile 2800 Actors Option TF Reference - No options defined Department System Scheduler/ Order Filler No options defined - Image Manager/ Image Archive No options defined Image Display - ____________________________________________________________________________ 133 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

134 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Actors Option Reference Evidence Creator/Image - No options defined Display defined - Post -Processing Manager No options 12.3 Implementation Issues Actor Grouping Clarification 12.3.1 This profile is designed with the following implementation scenarios in mind: Scenario 1: . The DSS in The Post -Processing Manager is grouped with the Image Manager in System A 2805 . In this case: System B needs status information -Processing Workflow Profile as the Post -Processing System A claims support of the Post s. Actor Manager and Image Manager and implements System B claims support of the Scheduled Workflow Profile as the DSS Actor the optiona 2810 l Performed Work Status Update transaction. Scenario 2: The Post -Processing Manager is grouped with the DSS in System A . The Image Manager in System B is not interested in status information . In this case: kflow Profile as the Post System A claims support of the Post -Processing Wor -Processing Manager and DSS Actor s. 2815 System B claims support of the Scheduled Workflow Profile as the Image Manager Actor . Scenario 3: . The Image Manager in -Processing Manager is grouped with the DSS in System A The Post eds status information System B ne . In this case: System A claims support of the Post -Processing Workflow Profile as the Post -Processing 2820 Manager and DSS Actor s. Actor and System B claims support of the Scheduled Workflow Profile as the Image Manager implements the optional Performed Work Status Update transaction. Scenario 4: -Processing 2825 . Another Post A Post -Processing Manager is grouped with the DSS in System A Manager is grouped with the Image Manager in System B . In this case: -Processing Workflow Profile as the Post -Processing System A claims support of the Post s. Manager and DSS Actor -Processing -Processing Workflow Profile as the Post System B claims support of the Post Manager and Image Manager 2830 s. Actor ____________________________________________________________________________ 134 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

135 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ This leaves the site with the decision of how to reconcile control of the post -processing . There are two approaches. workflow Any system implementing the Post- Processing Manager shall be able to disable this functionality through configuration. -Processing Manager lects one of the two systems to be the Post In the first approach, the site se 2835 -Processing workflow by configuring the other to disable its workflow management for the Post . functionality - -Processing Manager to start Post In the second approach, the site may configure one Post Processing worklists for one set of procedure codes and configure the second Post -Processing . Making -Processing worklists for a complementary set of procedure codes Manager to start Post 2840 overlapping and comple mentary is a configuration sure that the procedure code sets are non- responsibility of the site. Input Availability 12.3.2 -Processing Manager will have some In case of being grouped with the Image Manager, the Post 2845 Processing internal logic to determine when images available are sufficient for the Post- -processing to be performed. In some cases, it may not be necessary for a post workflow to begin. 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 Archive for query. The image set needed for the Post -Processing workitem might or might not include all 2850 -Processing Manager has be en notified about via previous MPPS or/and the instances the Post -PPS messages related to a requested procedure. Based on the received information and its GP Processing Manager decides which data the Post internal logic the Post- -Processing workitem input consists of. 2855 the Post -Processing Manager will create a workitem in the Post- Processing worklist Generally, when the required images are available, although it may create the workitem before that with an ag set to empty or incomplete Input Information Sequence and the Input Availability Fl PARTIAL, until the images are available in the Image Archive. -Processing Client (Evidence Creator) must be prepared -Processing Manager and Post The Post 2860 . to handle workitems with PARTIAL image availability in a stable fashion g Client may elect not to present workitems with PARTIAL status to the user The Post -Processin . If the Post -Processing Client for selection until their status later changes to COMPLETE -Processing Cli chooses to let the user select and start work on those items, then the Post ent is -processing worklist and make sure the user/application responsible for monitoring the post 2865 receives the full data when it is available. Processing Manager may choose to leave workitems with PARTIAL status Similarly the Post- . If the Post until the status is COMPLETE out of provided worklists -Processing Manager decides to provide PARTIAL workitems in the worklists, then it may be expected to check image ____________________________________________________________________________ 135 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

136 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ availability and provide updated post -processing worklist replies to queries from the Post - g Client for workitems the client claims. 2870 Processin 12.3.3 -Processing Workflow Evidence Creators in Scheduled Workflow vs. Post -Processing Workflow Profile shall use mechanisms An Evidence Creator that supports the Post 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 the 2875 Modality Performed Procedure Step transactions to communicate tasks performed as described in the Scheduled Workflow Profile. 12.4 Post -Processing Process Flow -processing use cases. The following are some possible post 2880 Computer Aided Detection Use Case 12.4.1 is to be acquired and a mammography screening exam or a lung CT) e.g., A modality procedure ( . The images and CAD processing results will CAD processing is to be performed on the images be interpreted together on a review workstation by the reading physician. The specific actors in this case are Acquisition Modality (digital mammography or CT acquisition system), Evidence Creator/Image Display (CAD processing system), Department 2885 System Scheduler, Image Manager/Image Archive, Post -Processing Manager, and Image Display (review workstation). -Processing Manager is grouped with either the Department System Scheduler or Image The Post . The DICOM Standard Manager and is responsible for providing work to the Evidence Creator -ray or CT), Query/Retrieve, services used are Storage of Images (Digital Mammography X 2890 General Purpose Worklist, and Storage of Structured Reports ( Mammography CAD or e.g., Chest CAD). When MPPS Complete has been received and the acquired images are available on the Image -Processing Manager would add a CAD workitem to the worklist. The CAD Archive, the Post processi 2895 ng 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 CAD processing, reporting the status back to the Post -Processing Manager (including reference s to result objects created) . The generated Evidence documents (CAD processing results) are stored e.g., . as DICOM Structured Reports ( Mammography CAD or Chest CAD) The Evidence Document includes references to the images that were analyzed (typically for 2900 mammography screening, the MLO and CC views of the left and right breasts), a summary of the algorithms that were executed, including algorithm identification, whether they succeeded or . For example, CAD processing for failed, and the findings detected by the algorithms mammography or lung studies may include identification of the locations of things like . -calcifications on the images suspected densities (masses) and micro 2905 ____________________________________________________________________________ 136 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

137 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 Image . At the end, the Post Manager -Processing Manager is -SPS update that the notified with a GP 2910 scheduled 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 . In this way, the profile complements the Simple Image and Numeric diagnostic report generated . Report Profile 3D Reconstruction Use Case 12.4.2 2915 A modality procedure ( e.g., a standard CT lumbar spine exam) is to be acquired and reconstructed and the results sent to a 3D post -processing application where Multi -Planar . The originally Reconstruction (MPR) is performed to get coronal images of the lumbar spine es and the new coronal images are interpreted together, either at the modality created axial imag 2920 or on a review station. a CT system), Image e.g., The specific actors in this case are the Acquisition Modality ( eduler, Image Display/Evidence Creator (3D workstation), Department System Sch Manager/Image Archive, Post -Processing Manager, and Image Display (review workstation). -Processing Manager is grouped with either the Department System Scheduler or Image The Post Manager and is responsible for providing work to the Evidence Creator . The DICOM Standard 2925 services used are Storage of Images (CT), Query/Retrieve, and General Purpose Worklist. When MPPS Complete has been received and the acquired images are available on the Image Archive, the Post -Processing Manager would add a pos t-processing workitem (GP -SPS) to the worklist. 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 2930 MPR processing, reporting the status back to the Post -Processing Manager (including references to result objects created) . At the end, . The MPR result images are stored as DICOM Images (CT) -SPS update that the scheduled step is -Processing Manager is notified with a GP the Post complete . The images are then available for retrieval by the Image Display Actor on a review/reporting 2935 system . 12.4.3 Post -Processing Process Flow Diagrams The following scenario illustrates a case where an image processing task is performed on . The acquired images and then a subsequent CAD step is performed on the processed images Transaction Summary is depicted for two scenarios: 2940 -Processing Manager is grouped with the Department System Scheduler The Post • • -Processing Manager is grouped with the Image Manager The Post ____________________________________________________________________________ 137 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

138 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The Performed Work Status Update (Started) message must be sent sometime after the Workitem Claimed transaction but at the latest, when the first GP . In -PPS In Progress is received eivable that in some . Also, it is conc this scenario it is shown right after the Workitem Claimed 2945 scenarios, the processing workstation has loaded potentially useful studies/images prior to claiming the workitem or maybe even before getting the worklist. ____________________________________________________________________________ 138 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

139 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ DSS / (CAD System) (3D Worksta tion) Image Manager/ Post - Processing Evidence Evidence Creator/ (Review) Image Archive Manager Image Display Creator/ Image Image Display Display Images - Create Post Processing Wor kitem Available Query Processing - Query Post Worklist Workitem Claimed (Post - Processing) Performed Work Status Update (Started) Retrieve Images Workitem PPS Perform - Post Processing In Progress 3D Processing Creator Images Stored Storage Commitment Workitem PPS Completed Workitem Completed Performed Work Processing) (Post - Status Update (Completed) Create CAD Workitem sing Worklist Query Post Proces - Workitem Claimed Performed Work (CAD) Status Update (Started) Retrieve Images Workitem PPS In Progress CAD Evidence Documents Stored Perform CAD Processing Storage Commitment Worktiem PPS Completed Workitem rmed Work Perfo Completed Status Update (CAD) (Completed) Query/Retrieve Images/Evidence Documents 2950 -Processing Manager Grouped with Department System Scheduler 1: Post Figure 12.4- ____________________________________________________________________________ 139 : IHE International, Inc. 8-07-27 – Final Text 201 7.0 Rev. 1 Copyright © 2018

140 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Manager/ (CAD System) (3D Workstation) Processing Post - Image Archive Evidence Creator/ Evidence DSS (Review) Manager Image Display Creator/ Image Image Display Display Images Available - Create Post Processing Workitem Processing Query Post - Worklist Workitem Claimed Processing) - (Post Performed Work Status Update (Star ted) Retrieve Images Workitem PPS Processing - Post In Progress Perform 3D Processing Creator Images Stored Storage Commitment Workite m PPS Completed Workitem Completed Performed Work (Post - Processing) Status Update (Completed) Create CAD Workitem Query Post Processing Worklist - Workitem Claimed Performed Work (CAD) Status Update (Started) Retrieve Images Workitem PPS In Progress CAD Evidence Document Stored Perform Storage Commitment Processing CAD Workitem PPS Completed Workitem Performed Work Completed Status Update (CAD) (Completed) Query/Retrieve Images/Evidence Documents -Processing Manager Grouped with Image Manager 2: Post Figure 12.4- ____________________________________________________________________________ 140 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

141 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Reporting Workflow (RWF) 13 The Reporting Workflow Profile addresses the need to schedule and track the status of the 2955 various 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. Worki tems can be claimed. The resulting intermediate and final statuses can be returned from the system performing the work to the system managing the . The system managing the work also makes the status available for other interested systems work 2960 ise. in the enterpr 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 . see S Simple Image and Numeric Report (SINR) Profile ( ection 9) The Reporting Workflow Integration Profile is a continuation of the Scheduled Workflow 2965 Integration Profile. Actors/Transactions 13.1 1 shows the actors directly involved in the Reporting Workflow Integration Profile Figure 13.1- . Other actors that may be indirectly involved due to and the relevant transactions between them their participation in the Scheduled Workflow, etc. are not necessarily shown. Image Display can participate in this profile if it is grouped with a Report Creator. 2970 ____________________________________________________________________________ 141 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

142 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ DSS/ Order Filler - 4: Procedure Scheduled RAD ↓ - RAD 13: Procedure Update ↓ - ↑ 42: Performed Work Status Update RAD Report Report Report 46: Query Reporting Worklist RAD - ← C Reader Manager reator ← RAD - 38: Workitem Claimed - RAD ← 41: Workitem Completed RAD - 39: Workitem PPS in Progress ← 40: Workitem PPS Completed ← RAD - 7: Modality PS Completed - RAD ↑ Performed Procedure Step Manager Image Image - 11: Image Availability Query ← RAD Archive Manager Figure 13.1- 1: Reporting Workflow Actor Diagram 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 2975 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 13.2. Actors and Transactions on Profile - 1: Reporting Workflow Integrati Table 13.1- Optionalit TF Reference Actors Transactions y Department System RAD TF 4.4 -2: Procedure Scheduled [RAD -4] R Scheduler/ Procedure Update [RAD -13] 4.13 R RAD TF -2: Order Filler -3: RAD TF Performed Work Status Update 4.42 R -42] [RAD (Receive) RAD TF 4.11 Image Manager/ -2: R Images Availability Query [RAD -11] Image Archive RAD TF Query Images [RAD -14] R -2: 4.14 -16] Retrieve Images [RAD RAD TF R 4.16 -2: ____________________________________________________________________________ 142 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

143 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Optionalit Actors Transactions TF Reference y Query Reporting Worklist [RAD -46] R Report Creator RAD TF -3: 4.46 (Report Reader) R RAD TF -38] 4.38 Workitem Claimed [RAD -3: R Workitem PPS In Progress [RAD RAD TF -3: 4.39 -39] Workitem PPS Completed [RAD -40] R 4.40 RAD TF -3: RAD TF R -41] -3: 4.41 Workitem Completed [RAD Procedure Scheduled [RAD -4] -2: R Report Manager RAD TF 4.4 Images Availability Query [RAD -11] R RAD TF -2: 4.11 Procedure Update [RAD -13] R -2: RAD TF 4.13 4.46 -3: RAD TF R -46] Query Reporting Worklist [RAD Workitem Claimed [RAD R RAD TF -3: 4.38 -38] Progress [RAD-39] R Workitem PPS In RAD TF -3: 4.39 Workitem PPS Completed [RAD -40] R RAD TF -3: 4.40 Workitem Completed [RAD R RAD TF -3: 4.41 -41] 4.42 -3: RAD TF R Performed Work Status Update (send) -42] [RAD R RAD TF 4.7 -2: Modality Performed Procedure Step Completed [RAD -7] R 4.7 -2: Modality Performed Procedure Step RAD TF Performed Procedure Completed [RAD Step Manager -7] 2980 Refer to Table 2-1 for other profiles that may be pre -requisites for this profile. 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 some . Generally these decisions are based cases, it may not be necessary for a report to be generated on the procedure code of the requested procedure. 2985 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: System A claims support of the Reporting Workflow Profile as the Report Manager and Image 2990 s. Actor Manager System B claims support of the Scheduled Workflow Profile as the DSS Actor and implements the optional Performed Work Status Update transaction. Scenario 2: . The Image Manager in System B The Report Manager is grouped with the DSS in System A 2995 needs status information. In this case: ____________________________________________________________________________ 143 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

144 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ ow Profile as the Report Manager and DSS System A claims support of the Reporting Workfl s. Actor Actor System B claims support of the Scheduled Workflow Profile as the Image Manager . Scenario 3: 3000 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: . Actor System A claims support of the Reporting Workflow Profile as the Report Manager 3005 duled Workflow Profile as the DSS Actor System B claims support of the Sche and implements the Performed Work Status Update transaction. and Actor System C claims support of the Scheduled Workflow Profile as the Image Manager may implement the optional Performed Work Status Update transaction if the needed. Input Availability 13.1.2 3010 The Report Manager uses the Images Availability Query transaction to know when images are evant for the reporting workflow available in the Image Archive for query. The image set rel might or might not include all the instances the Report Manager has been notified about via -PPS messages related to a requested procedure. Based on the received previous MPPS or/and GP Report Manager decides which data the reporting workitem information and its internal logic the input consists of. 3015 Generally, the Reporting Manager will create a workitem in the reporting worklist when the required images are available, although it may create the workitem before that with an incomplete 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 3020 . If the Report status to the user for selection until their status later changes to COMPLETE Creator allows the user to select and start work on items with partially available input, then the Report 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 the 3025 . If the Report Manager provides workitems provided worklist until the status is COMPLETE with partially available input data in the worklist, then a later check of the image availability and update of the workitem in the worklist may be expected even for workitems that have been already claimed. Reporting Workflow Integration Profile Opt ions 3030 13.2 1 along with 13.2- Options that may be selected for this Integration Profile are listed in the Table the Actors to which they apply . Dependencies between options when applicable are specified in notes. ____________________________________________________________________________ 144 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

145 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 13.2- 1: Reporting Workflow - Actors and Opti ons Actor Options TF Reference Department System Scheduler / HL7 v2.5.1 RAD TF -1: 13.2.1 -2: RAD TF 4.4 Order Filler -2: 4.13 RAD TF Image Manager/ - No options defined Image Archive Report Creator - No options defined 13.2.1 Report Manager HL7 v2.5.1 RAD TF -1: RAD TF -2: 4.4 RAD TF 4.13 -2: No options defined Report Reader - No options defined Performed Procedure Step Manager 3035 13.2.1 HL7 v2.5.1 Option The HL7 v2.5.1 Option requires actors to support HL7 v2.5.1 in addition to HL7 v2.3.1 in the transactions referenced in Table 13.2- 1. The actor shall permit configuration for each system that it communicates with using the referenced transactions whether H L7 v2.3.1 or HL7 v2.5.1 is 3040 used. 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 -2: Appendix E . ld correspondences are summarized in RAD TF implementations and the fie 13.3 Reporting Tasks 3045 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 acqu ired images, reviews them and typically generates either a draft report or dictation. Interpretation and Dictation - • the physician generates an audio file of dictated observations that will make up the diagnostic report’s content. 3050 • Transcription - the transcriptionist accesses the physician’s dictated report and generates the transcribed text report. • the physician accesses the transcribed or draft report, confirms the text Verification - content accuracy and generates the verified report. hysician accesses the report, reviews the content and may generate either 3055 • the p Review - an agreement or disagreement. Comparison - • the physician accesses two verified reports, reviews the content, and generates either a difference report or confirmation of similarity. ____________________________________________________________________________ 145 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

146 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ the coder accesses a draft or verified report, and assigns codes. Coding - • Note 3060 : 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. Depending on the capabilities of the system containing the Report Creator Actor and the permissions of the user, it may be possible to carry out several steps at once . For example, a 3065 speech recognition workstation may support interpretation, dictation and transcription all at once, and a senior physician may have authority to immediately verify the resul ting report . In other situations or implementations, it may be necessary to perform the steps separately. The types and . A sequential process made up of an sequence of tasks may vary from site to site ation task is very common, but can vary 3070 interpretation/dictation, a transcription and a verific between institutions. The logic of determining what tasks to schedule and when to schedule them is the responsibility . Typically, this logic will involve completion of the Report Manager and is not defined by IHE . Much of the needed information -requisite tasks and/or availability of needed input objects of pre 3075 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 Report Manager. The logic of presenting a relevant list of workitems to the user is the responsibility of the Report Creator and is only partially defined by IHE in the Query Reporting Worklist transaction. Typically, this will in volve filtering the available workitems based on the Scheduled Workitem 3080 Code (to find particular types of tasks), the Scheduled Human Performer (to find work for a particular 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 a particular order), or Procedure Step Status (to find work in a particular state). 3085 . Query Reporting W -3: 4.46 - A number of common workitem codes are listed in RAD TF orklist 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. As the Report Creator completes tasks, it reports performed workitem codes to the Report Manager . This is particularly important when the Report Creator performs additional tasks as it enables the Report Manager to modify the workflow . Further robustness and flexibility is 3090 provided 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. gives an example of a full Reporting 1, parts 1 & 2) Figure The following diagram ( 13.3- 3095 Workflow from scheduling of the initial Interpretation/Dictation task, to the final release of the . Prior to the start of this, images and evidence documents would have been stored verified report and PPS transactions containing references to those objects sent to the to the Image Manager Report Manager. ____________________________________________________________________________ 146 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

147 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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. 3100 (s) below, there are parenthetic notations associated with most of the Query In the figure Progress/ Completed transactions. These notes Reporting Worklist and Workitem PPS In- indicate the Scheduled or Performed Workitem Codes associated with those transactions. For a complete set of codes 4. 4.46- -3: Table , refer to RAD TF 3105 Report Report Image Manager/ Report Report Acq S DS Creator/ Manager Image Archive Repository Creator/ Modality Report Image Reader Display Modality Images Stored Evidence Docs Stored MPPS 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 Perform Workitem PPS Interpretation & In Progress Dictation (Interpretation) Interpretation Create & Dictation Workitem PPS Audio Report Completed (Interpretation) “External Audio Storage” Workitem PPS In Progress (Dictation) Workitem PPS Completed (Dictation) Workitem Completed Create Transcription Worklist Task Performed Work Status (completed) Figure 13.3- 1 (part 1): Reporting Workflow Overall Sequence ____________________________________________________________________________ 147 Rev. 1 : IHE International, Inc. 7.0 – Final Text 201 8-07-27 Copyright © 2018

148 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Manager/ Report Report Report eport R DSS Image Archive Repository Creator/ Report Manager Creator/ Image Reader Display Query Reporting Worklist (Transcription) Workitem Claimed (Transcription) “Retrieve External Audio” Performed Work Status (in progress) Workitem PPS In Progress Perform (Transcription) Transcription Transcription Report creation Report Submission Workitem PPS Completed (Transcription) Workitem Completed Performed Work Create Verification Worklist Task Status (completed) Report Report Image Manager/ Report Report DSS reator/ C Manager mage Archive I Repository Report Creator/ Image Reade Display Query Reporting Worklist Workitem Claimed (Verification) Performed Work Status (in progress) Retrieve Report (Preliminary) Workitem PPS In Progress (Verification) Verification Perform Verification Report Submission Report Issuing (Verified) Workitem PPS Completed (Verification) Report Workitem Completed Reader Performed Work Status (completed) Query Reports Retrieve Reports 1 (part 2): Reporting Workflow Overall Sequence Figure 13.3- 3110 ____________________________________________________________________________ 148 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

149 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Diagnostic Reporting Use Cases 13.4 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, their feasibility is demonstrated. 13.4.1 3115 Use case 1: Predefined Report The primary user is the reading physician. When interpreting a study, the user chooses a report -configured draft reports and can edit the report’s content in order to customize from a list of pre it. This use case covers the si tuation where the user can use a predefined/ canned report (which is frequently the case when the results are normal), and has permission to verify the report. 3120 This use case finally results in: multiple Performed Procedure Steps for each of the performed w • orkitems 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. • 3125 The basic flow is illustrated in Figure -1 13.4 ____________________________________________________________________________ 149 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

150 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Report Report Image Manager/ Report DSS Creator/ Manager Image Archive Creator/ Report Image Reader Display MPPS Completed Create Interpretation Worklist Task Images Available Query Reporting Worklist Workitem Claimed (Interpretation) Performed Work Status (in progress) Retrieve Images Workitem PPS s In Progres Report Creation (Interpretation) Workitem PPS Verify Report Completed (Interpretation) Workitem PPS In Progress (Verification) Workitem PPS Completed (Verification) Report Submission Workitem Completed Performed Work Status (completed) 1: Predefined Report 1 Use Case Figure 13.4- 3130 Use case 2: Workitem Deferred 13.4.2 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 to complete it. At the end of this use case the workitem status is set to scheduled and the workitem remains in 3135 the worklist. -2 (optional transactions denoted by dotted lines). 13.4 The basic flow is illustrated in Figure Transactions Workitem PPS In Progress and Workitem PPS Completed are optional since some s may let the user skip before sending these transactions implementation ____________________________________________________________________________ 150 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

151 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Report Report Image Manager/ Report DSS Creator/ Manager Image Archive Creator/ Report Image Reader Display MPPS Completed Create Interpretation Worklist Task Images Available Query Reporting Worklist Performed Work Work item Claimed Status (in progress) Query Images Retrieve Images Start Work it em PPS Interpretation in progress (in progress) Work item PPS Completed (discontinued) P erformed Work Work item Status (scheduled) Completed (scheduled) 3140 Figure 13.4- 2 Use Case 2: Workitem Deferred Use case 3: Direct Report Creation 13.4.3 The primary user is the reading physician. This use case takes place when the user creates the report’s content. The user may define a template or choose a template from pre- defined ones to fill in. The major difference between this use case and the “Predefined Report” use case ( 3145 Section 13.4.1) is that in this use case, the user is expected to have to perform more “customization/ i.e., in contrast to the ‘canned report’ nature of the Predefined tailoring” of the report content ( Report case). At the end of this use case the workitem status is set to completed, the workitem is removed from 3150 the worklist, a report is generated, the output results status message references the generated and the multiple report, the suggested subsequent workitem is set to Report Verification Performed workitem code sequences include Interpretation and Transcription. The -3. 13.4 basic flow is illustrated in Figure ____________________________________________________________________________ 151 8-07-27 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 Copyright © 2018

152 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 the generated report is verified, and the multiple Performed workitem code sequences include 3155 nd Report Verification. Interpretation, Transcription a Report Report Image Manager/ Report DSS Creator/ Manager Image Archive Creator/ Report Image Reader Display MPPS Completed Create Interpretation Worklist Task Images Available Query Reporting Worklist Workitem Claimed (Interpretation) Performed Work Status (in progress) Retrieve Images Workitem PPS In Progress Report Creation (Interpretation) Report content created/ edited by user Workitem PPS Completed (Interpretation) Extension: Verify Workitem PPS Report Completed (Verification) Report Submission Workitem Completed Performed Work Status (completed) Figure 13.4- 3 Use Case 3: Direct Report Creation Use case 4: Interpretation and Dictation 13.4.4 3160 The primary user is the reading physician. This use case takes place when the user dictates the interpretatio n. This use case finally results in: ____________________________________________________________________________ 152 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

153 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • multiple Performed Procedure Steps for each of the performed workitems Interpretation 3165 and Dictation, each having a corresponding code value in the Performed Workitem Code Sequence; an output results status message, refe rencing 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 3170 -4 (optional transactions denoted by dotted lines). 13.4 Technical Framework to define the “External Audio Storage” transaction NOTE: It is beyond the scope of the Radiology shown in this figure. This use case has two variations. The first variation is when a voice recognition system is available at the Report Creator. In this case a report is generated, the output results reference the 3175 generated report, the suggested subsequent workitem is set to Report Verification, and two e created each having a Performed Workitem Code Sequence value Performed Procedure Steps ar of Interpretation or Transcription respectively. The second variation takes place when a voice recognition 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 each having a Performed Workitem Code Sequence value of Interpretation, Transcription or Report 3180 Verification respectively. ____________________________________________________________________________ 153 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

154 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Report Report Image Manager/ Report Audio External DSS Creator/ Manager Image Archive Creator/ Repository Report Image Reader Di splay MPPS Completed Create Dictation Worklist Task Images Available Query Reporting Worklist (interpretation, Dictation) k Performed Wor Work item Claimed Status (in progress) Query Images Retrieve Images Dictation Perform Interpretation, Work item PPS Dictation in progress Create (interpretation, Audio Report Dictation) “External Audio Storage” Work item PPS Completed (interpretation, Dictation) Performed Work Work item Status (completed) Completed Create Transcription Worklist Task Figure 13.4- 4 Use Case 4: Interpretation and Dictation 3185 Use case 5: Transcription 13.4.5 The primary user is the transcriptionist. This use case can start when an audio file is available, d report. and takes place when the transcriptionist transcribes the audio content into a transcribe This use case finally results in: • a Performed Procedure Step for Transcription, having a corresponding code value in its 3190 Performed Workitem Code Sequence; • an output results status message, referencing the generated report and suggesting its Verif ication as subsequent workitem; removing the workitem from the worklist, after the workitem status was set to completed. • 13.4 The basic flow is illustrated in Figure -5. ____________________________________________________________________________ 154 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

155 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Technical Framework to define the “Retri NOTE: It is beyond the scope of the Radiology eve External Audio” transaction 3195 shown in this figure. Report Report Audio External Image Manager/ Report DSS Manager Creator/ ive Repository Image Arch Creator/ Report Image Reader Display Create Transcription Worklist Task Query Reporting Worklist (Transcription) Performed Work Work Item Claimed Status (in progress) Tran scription “Retrieve External Audio” Workitem PPS in progress Perform (Transcription) Transcription Report creation Report Submission Workitem PPS Completed Performed Work (Transcription) Status (completed) Workitem Completed Create Verification Worklist Task 5 Use Case 5: Transcription Figure 13.4- Use case 6: Partial completion 13.4.6 3200 The primary user is the reading physician. This use case happens when the user begins the task and then decides that this task cannot be completed at this moment. The reason can be that more input is necessary to perform this task such 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 3205 when interpretation would be possible again At the end of this use case the workitem status is set to discontinued, and the workitem is removed from the worklist. The Report Creator may decide whether sending partial results to the Report Manager (via the 3210 Workitem PPS transactions) is useful. The basic flow is illustrated in Figure -6 (optional transactions denoted by dotted lines). 13.4 ____________________________________________________________________________ 155 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

156 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Preferably the Report Manager would need to know about the re ason for discontinuation. However, this is not possible actually with the DICOM GP PPS transaction. It will be included later when this becomes possible. Report Report Image Manager/ Report DSS Creator/ Manager Image Archive Creator/ Report Image Reader Display MPPS Completed Create Interpretation Worklist Task Images Available Query Reporting Worklist Performed Work Work item Claimed Status (in progress) Query Images Retrieve Images Work item PPS in progress (in progress) Start Interpretation More input Work item PPS needed Discontinued (discontinued) Work item Performed Work Completed Status (discontinued) (dicontinued) processing - post Create Modality/ Worklist List 3215 6 Use Case 6: Partial Completion Figure 13.4- Use case 7: Verification 13.4.7 The primary user is the verifying physician. 3220 -verified report needs verification. Verification is a This use case can start when a non confirmation of the correctness of the report’s content. It is NOT a legal signature. For DICOM SR instances, verification res ults in setting the Verification Flag value to “VERIFIED”. This use case finally results in: ____________________________________________________________________________ 156 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

157 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • a Performed Procedure Step for Report Verification, having a corresponding code value 3225 in its Performed Workitem Code Sequence; an output results status message, re • ferencing the verified report; removing the workitem from the worklist, after the workitem status was set to completed. • -7. The basic flow is illustrated in Figure 13.4 Report Report Image Manager/ Report DSS Manager Creator/ Image Archive Creator/ Report Image Reader Display Create Verification Worklist Task Query Reporting Worklist (Verification) Performed Work Work item Claimed Status (in progress) Query Reports Verification Retrieve Reports PPS in progress Work item (Verification) Perform Verification Report Submission Work item PPS Completed (Verification) Performed Work Work item Completed ed) Status (complet 3230 7 Use Case 7: Verification Figure 13.4- 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. 3235 Use case 8: Double reading 13.4.8 The primary user is the reading physician. This use case takes place when two report objects are needed for the same requested procedure. ____________________________________________________________________________ 157 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

158 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ o reporting workitems. Each workitem is processed separately The Report Manager generates tw 3240 according to use cases 1 to 7. Once both verified reports are generated, they are compared according to the comparison use case. 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 3245 be compared. At the end of this use case, the user finds the reports either similar or different. In the case of a disagreement, a discrepancy report is gener ated. The basic flow is illustrated in Figure -8. This flow assumes that the reports being compared 13.4 have been submitted to the Report Manager. Report Report Image Manager/ Report DSS Manager Creator/ Image Archive Creator/ Report Image Reader Display Create comparison Worklist Task Query Reporting Worklist Performed Work Work item Claimed Status (in progress) Query Reports Comparison Retrieve Reports Work item PPS in progress (in progress) Perform comparison Create ”discrepancy” report Report Submission Work item PPS Completed (completed) Work item Completed Performed Work (completed) Status (completed) 3250 Figure 13.4- 8 Use Case 9: Comparison ____________________________________________________________________________ 158 Rev. 1 7.0 – Final Text 201 8-07-27 : IHE International, Inc. Copyright © 2018

159 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 13.4.10 Use case 10: Review The primary user is the reading physician. This use case takes place when the user needs to 3255 review 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 a coll eague. In this case, the Report Manager would schedule Review workitems either based on a request from the user, the administrator, or automatically based on department policy and the user being marked as “back”. 3260 ting” where a ‘student’ is given a list of reports done by Another scenario is in an “educational set a more senior colleague to review with the purpose of learning from it. 13.4.11 Use case 11: Over Read The primary user is the reading physician. This is often done for the purposes of quality the reading process. assurance on 3265 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 with the original report’s content. In the case of an agreement, an additional ‘Verifying Observer 3270 added to the original report object. In the case of a disagreement, a discrepancy Sequence’ is report is generated. ____________________________________________________________________________ 159 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

160 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Evidence Documents (ED) 14 image information, such as measurements, The Evidence Documents Profile allows detailed non- 3275 o be made available as input to the process of generating a CAD results, procedure logs, etc. t diagnostic report either as additional evidence for the reporting physician or in some cases for selected items in the Evidence Document to be included in the diagnostic report. ating and using Evidence Documents can be managed by worklists that The process of cre provide patient/ procedure details and by performed procedure steps that report status 3280 information (e.g., see Integration Profiles on Scheduled Workflow, Post -Processing Workflow, Reporting Workflow). Evidence Documents represent one of the inputs to the reporting process described in the Reporting Workflow Profile and may provide details which get included in diagnostic reports described in the Simple Image & Numeric Reports Profile. It s 3285 hould 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 historical reasons. 14.1 Actors/Transactions 1 shows the actors directly i Figure 14.1- nvolved in the Evidence Documents Integration Profile 3290 and the relevant transactions between them . Other actors that may be indirectly involved due to their participation in Scheduled Workflow, etc. are not necessarily shown. Evidence Creator Report Image Display Creator Storage 44: Query Evidence Documents - RAD ↓ - 43: Evidence RAD ↓ ↓ Commitment: RAD - 10 ocuments ↓ RAD - 45: Retrieve Evidence D Documents Sd Image Image Manager Archive Storage ↑ RAD - 43: Evidence - 10 ↑ Commitment: RAD Documents Sd Acquisition Modality 1: Evidence Documents Actor Diagram Figure 14.1- ____________________________________________________________________________ 160 Rev. 1 7.0 8-07-27 Copyright © 2018 : IHE International, Inc. – Final Text 201

161 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 the 3295 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 14.2. Table 14.1- 1: Evidence Document Integration Profile - Actors and Transactions Transactions Optionality TF Reference Actors [RAD -10] R Storage Commitment RAD TF -2: 4.10 Evidence Creator Evidence Documents Stored -43] R [RAD RAD TF -3: 4.43 Commitment [RAD -10] R Storage RAD TF -2: 4.10 Acquisition Modality [RAD -43] R Evidence Documents Stored RAD TF -3: 4.43 Image Manager/ RAD TF 4.10 -2: Storage Commitment [RAD -10] R Image Archive RAD TF R -43] [RAD Evidence Documents Stored 4.43 -3: Query Evidence Documents [RAD-44] R RAD TF -3: 4.44 Retrieve Evidence Documents R 4.45 -3: RAD TF -45] [RAD Query Evidence Documents [RAD-44] Image Display -3: RAD TF R 4.44 (Report Creator) -45] 4.45 [RAD Retrieve Evidence Documents -3: R RAD TF -requisites for this profile. 2-1 for other profiles that may be pre Refer to Table 3300 Note: 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 be able to Query/Retrieve the Evidence documents, and the Report Creator is expected to be able to transfer some contents of the retrieved document into the report it creates. 3305 14.2 Evidence Documents Integration Profile Options Options that may be selected for th is 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 in notes. Table 14.2- 1: Evidence Documents - Actors and Options Actor Reference TF Options - - Evidence Creator No options defined - - No options defined Acquisition Modality Image Manager/ No options defined - - Image Archive No options defined - - No options defined - - Image Display (Report Creator) - - No options defined ____________________________________________________________________________ 161 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

162 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 3310 The Evidence Creator, Acquisition Modality and Image Manager/ Image Archive will likely . Each DICOM SOP Class that is supported by the support a variety of DICOM SOP Classes actor shall be listed in the product’s DICOM Conformance Statement. The IHE Integration Statement (see A ppendix D) shall reference the DICOM Conformance Statement but does not repeat the list of DICOM SOP Class es that are considered to contain Evidence Documents. 3315 -3: 4.43, Examples of DICOM SOP Classes that may contain evidence are listed in RAD TF 2. Table 4.43- 1 and Table 4.43- Evidence Document Process Flow 14.3 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 3320 . The start and completion of creating Evidence Documents is reported in the Scheduled Progress/Completed Workflow Profile by the Evidence Creator using Creator Procedure Step In- transactions, or by the Acquisition Modality using the Modality Procedure Step In- e Creator using the -Processing Workflow by the Evidenc Progress/Completed; and in the Post 3325 -Progress/Completed transactions. Workitem Procedure Step In 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 . Evidence Documents represent the uninterpreted information that is primarily the Report 3330 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 availabl e for wide distribution. 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 3335 Processing Workflow Manager) and the way the Evidence Creator repor ts status in the Post- Profile (using a Workitem PPS transaction to the Post -Processing Workflow Manager), two examples of the process flow will be shown below. the workflow in the The scheduling part of the workflow that would typically precede the part of 1 (Administrative Process Flow) in the Scheduled 3.2- ure 3340 following diagram can be seen in Fig Workflow Profile. ____________________________________________________________________________ 162 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

163 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Evidence Creator/ Department System Image Manager/ Image Display/ Image Display Scheduler/ Order Image Archive Report Creator Filler Query Images Retrieve Images Creator Procedure Creator Procedure Step In Progress Step In Progress Perfo rm Measurements Evidence Document Stored Creator Procedure Creator Procedure Step Completed Step Completed Storage Commitment nts Query Evidence Docume Retrieve Evidence Documents Apply Measurements 3-1: Evidence Document Management In Scheduled Workflow Figure 14. Note that the Procedure Step t 3345 ransactions and the Query/ Retrieve Images transactions in the . above 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 the ure -Processing Manager Grouped with Fig following diagram can be seen in 12.3- 1. (Post -Processing Workflow Profile. Department System Scheduler) in the Post 3350 ____________________________________________________________________________ 163 – Final Text 201 Rev. 1 : IHE International, Inc. Copyright © 2018 8-07-27 7.0

164 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ DSS / (CAD System) Image Manager/ - Processing Post Evidence Creator/ (Review) Image Archive Manager Image Display ge Display Ima Query Post - Processing Worklist Workitem Claimed Performed Work (CAD) Status Update (Started) Retrieve Images Workitem PPS In Progress Evidence Documents Stored Perform CAD Processing Storage Commitment Worktiem PPS Completed Workitem Performed Work Completed Status Update (CAD) (Completed) Query Evidence Documents Retrieve Evidence Documents -Processing Workflow 3-2: Evidence Document Management In Post Figure 14. em transactions in the above diagram are not part of the Note that the Worklist and Workit . Evidence Documents Profile ____________________________________________________________________________ 164 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

165 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 15 (PDI) 3355 Portable Data for Imaging Integration Profile Portable Data for Imaging Integration Profile specifies actors and transactions that The . The intent of provide for the interchange o f imaging -related information on interchange media 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 (where 3360 appropriate), reconciliation of data during import, and the structure of the media contents. The central elements of the profile are: -related information based on the DICOM standard Reliable interchange of imaging • viewable content on A Web Content Option • which provides guidelines for including web- media 3365 DVD and USB Media Options • -encoded objects The Web Content Option addresses the case of media containing both DICOM -encoded objects. and objects in XHTML or JPEG derived from these DI COM Actors/ Transactions 15.1 1 diagrams the actors directly involved in this profile and the transactions between Figure 15.1- 3370 actors. ____________________________________________________________________________ 165 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

166 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ → RAD 47: Distribute Imaging - Inform ation on Media Display → - RAD 47: Distribute Imaging ia Information on Med Image Display RAD → 47: Distribute Imaging - Information on Media Report Reader RAD 47: Distribute Imaging → - Print Information on Media Composer Portable Portable 47: - Distribute Imaging → RAD Media Media Information on Media Creator Importer Figure 15.1- 1: Portable Data for Imaging Diagram Table 15.1- 1 lists the transactio ns for each actor directly involved in the Portable Data for , an implementation shall 3375 Imaging Profile. In order to claim support of this integration profile perform the required transactions (labeled “R”). Transactions labeled “O” are op . A tional is listed in Section 15.2. Note that one complete list of options defined by this integration profile of a number of actors must be grouped with Portable Media Importer as described in Section 2.5. - Actors and Transactions 1: Portable Data f or Imaging Integration Profile Table 15.1- Actors Transactions Optionality TF Reference Distribute Imaging Information on R RAD TF -3: 4.47 Portable Media Creator Media [RAD -47] Distribute Imaging Information on Portable Media Importer R RAD TF -3: 4.47 [RAD Media -47] 4.47 -3: Image Display RAD TF Distribute Imaging Information on R Media [RAD -47] Report Reader R RAD TF -3: 4.47 Distribute Imaging Information on Media [RAD -47] RAD TF R 4.47 -3: Distribute Imaging Information on Print Composer Media [RAD -47] ____________________________________________________________________________ 166 8-07-27 Copyright © 2018 : IHE International, Inc. – Final Text 201 7.0 Rev. 1

167 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Reference Actors Transactions Optionality 4.47 Distribute Imaging Information on Display (ITI TF) R RAD TF -3: Media [RAD -47] 3380 Portable Data for Imaging Integration Profile Options 15.2 1 along with the 15.2- are listed in Table Options that may be selected for this integration profile . Dependencies between options when applicable are specified in actors to which they apply notes. Table 15.2- 1: Portable Data for Imaging - Actors and Options 3385 Actor Options TF Reference Web Content Portable Media Creator -1: 15.4.2 RAD TF RAD TF -3 : 4.47.4.1.2 DVD Media RAD TF -1: 15.4.4 -3 : 4.47.4.1.4.1 RAD TF USB Media -1: 15.4.4 RAD TF -3 : 4.47.4.1.4.2 RAD TF DVD Media Portable Media Importer RAD TF -1: 15.4.4 -3 : 4.47.4.1.4.1 RAD TF USB Media RAD TF -1: 15.4.4 RAD TF -3 : 4.47.4.1.4.2 DVD Media Image Display -1: 15.4.4 RAD TF RAD TF -3 : 4.47.4.1.4.1 USB Media -1: 15.4.4 RAD TF F-3 : 4.47.4.1.4.2 RAD T Report Reader DVD Media RAD TF -1: 15.4.4 -3 : 4.47.4.1.4.1 RAD TF USB Media RAD TF -1: 15.4.4 -3 : 4.47.4.1.4.2 RAD TF RAD TF -1: 15.4.4 Print Composer DVD Media RAD TF -3 : 4.47.4.1.4.1 -1: 15.4.4 USB Media RAD TF RAD TF -3 : 4.47.4.1.4.2 No options defined - Display 15.3 Portable Data for Imaging Process Flow This section describes the typical process flow related to the use of Interchange Media. The transaction covered 47] [RAD- istribute Imaging Information on Media i s D . 3390 The following steps can be identified in this process flow: ____________________________________________________________________________ 167 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

168 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • 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 the Portable Media Creator has access to the data from a grouped actor, or another source . outside the scope of IHE The media is physically transp 3395 -related orted to a destination where the imaging • 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 3400 dia Importer objects are present on the media and cannot be imported, the Portable Me notifies the operator of the studies and series affected and makes clear that they are not supported by the importing application. The Image Display, Report Reader, Display or Print Composer reads the objects it • 3405 nding on the receiver’s needs. If some objects are not supports and renders them depe supported by the reading application it notifies the operator that those objects are not supported. The potential usage scenarios of the data are described in the use cases below. 15.3.1 Use Cases This profil 3410 e is not intended to provide an archival solution. The matter of whether or not CD, DVD or USB media are suitably robust for long -term archive is not addressed by IHE. Diagnostic and therapeutic imaging data, Use Case 1 - Patient/Referring Physician Viewing: 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 3415 the same media or using a web browser. For security and priva cy reasons, media given to a . Refer to Section patient would not contain data of other patients 15.5 for additional security considerations. One or more patients’ data, such as images, Healthcare Enterprise Interchange: Use Case 2 - 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 read 3420 import” or “reference import”. anager/Archive to be Second Read Import: Media data is imported to the Image M • read/over read. In order to avoid data conflicts, key patient/study attributes may need to be reconciled with existing local data. Images and related presentation states can be sent to a Print Composer to be printed. 3425 Media data is imported to the Image Manager/Archive and/or Report Reference Import: • 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 to be reco nciled with existing local data. ____________________________________________________________________________ 168 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

169 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 3430 Media data is used to enable diagnostic or therapeutic : Use Case 3 - Operating Room Viewing processes in environments without a reliable network connection. The volume of data can be very large and may contain image data, p -processing results and reports. In the operating ost 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 3435 -related activities: The use cases can be specified in terms of three media Media Export • • Media Viewing • Media Import Media Export (All Use Cases): 3440 The Portable Media Creator assembles the media content (DICOM and web -viewable content) and writes it to the physical medium. The following sequence of activities will be performed during media creation: • . Export of DICOM data (FSC activity) Optionally, export of web- viewable data, which involves deriving easily accessible 3445 • informative data from the DICOM data (Web Content Option). • Opt ionally, inclusion of additional content ( e.g., a DICOM Viewer or viewing software components on the media to access DICOM data) . B) Media Viewing: 3450 (care providers, other users and patients without DICOM viewing B1) Web (Use Case 1) equipment or software): -viewable media content is received and displayed by a Display A Any web ctor, which exists as a generally available resource ( i.e., web browser) . Note that the Portable Media -viewable content on all media since it will be Creator cannot rely on the presence of web 3455 included only on media created using the Web Content Option). B2) DICOM (Use Case 1 and 3) (users with DICOM viewing equipment or software): The DICOM portion of the media content is displayed using specialized applications pre - ding environment or included on the media itself. The variety of existing in the rea can process is DICOM objects that an Image Display and/or Report Reader Actor indicated by its support of the corresponding content profiles. The Print Composer Actor 3460 dia to a Print Server for printing. sends images from the me C) Media Import (Use Case 2): The “Media Import” activity is accomplished by a Portable Media Importer and deals Actor exclusively with the DICOM portion of the media content. The Portable Media Importer is ____________________________________________________________________________ 169 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

170 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 3465 grouped 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. accesses all DICOM instances referenced by the er Actor The Portable Media Import DICOMDIR file and enables the user to select a media patient dataset to be imported. The Portable Media Importer obtains local data that is known to be accurate within the 3470 • prise and reconciles “key attributes” of patient and study importing institution/enter information (when required). A method for performing these steps is documented in the -3: 4.47.4.1.3 Import Reconciliation Workflow Profile (see Section 3.21). Refer to RAD TF ttributes” and the related reconciliation actions to be performed. for the list of “key a The Portable Media Importer may for example be grouped with an Evidence Creator to allow the storage of its Note: 3475 diagnostic and therapeutic imaging content to an Image Manager/Image Archiv e, or grouped with a Report a Report Repository. This enables use of the content for subsequent “relevant prior” Creator to store reports on could also be used to allow subsequent . A grouping with an Acquisition Modality Actor data for future reads over reads”. , the In the case of a Portable Media Importer grouped with the Print Composer Actor “reads/ 3480 imported 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 the previous sections. ____________________________________________________________________________ 170 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

171 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Report Portable Portable Evidence Image Report Creator Creator Media Manager Manager/ ia Creator Med Display Display Importer Archive Assemble Export Media Content Distribute Web Web Imaging Viewing Viewing Information on Media Access DICOM Distribute Directory Imaging DICOM Info Information on Viewing Media Evidence ect Obj Display Access Distribute DICOM Imaging Directory Info Information on Media Reconcile patient/study data on media using data Import locally obtained Store Diagnostic Reports Report Submission Store Evidence Images Creator Images Stored 1: Portable Data for Imaging Process Flow Figure 15.3.2- 3485 ____________________________________________________________________________ 171 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

172 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Media Content 15.4 The requirements on media content are intended to promote the reliable transfer of imaging data, tic reports, and to allow for the viewing of images and reports on general including diagnos purpose computers. The intent is that the media content be a “complete set of images of diagnostic quality” (a quote 3490 on Expert Panel on Medical from a statement on the matter by the American Medical Associati Imaging). The media content can be accessed via two "entry points" on the media: the DICOMDIR file for -viewable content. DICOM imaging information and optionally the INDEX.HTM file for web COM data and may optionally include web- Created media are required to contain DI 3495 viewable viewable data, if present, shall faithfully preserve the clinical data derived from it. This web- intent of the original DICOM information. DICOM Content 15.4.1 ia Storage Application Profile The DICOM data shall be created by using the DICOM Med appropriate for the content as defined in the Distribute Imaging Information on Media 3500 . The transaction and depending on the Options supported by the Portable Media Creator 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 name of directory that contains them. 15.4.2 Web Content Option 3505 Portable Media Creators implementing the Web Content Option may also include web- viewable data on the media. -viewable data shall be derived from the DICOM information as XHTML files and The web referenced JPEG images. The XHTML entry page (INDEX.HTM) shall allow access to all of sing a generally available 3510 -users to access relevant media content u this data. This enables end web browser . The INDEX.HTM file shall be placed in the root directory. -viewable data specified in this integration profile reflects the full set of the Note that the web exported DICOM data or a subset considered at the time of creation to faithfully represent the patient's clinical condition. For example, if a DICOM Structured Report references only Key 3515 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 Viewing applications (for example a DICOM Media Viewer) may optionally be included on the 3520 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. ____________________________________________________________________________ 172 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

173 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ DICOM format) may be also included on the Additional data (e.g., a diagnostic report in non- specified by this profile, such data shall be placed media. Since the format of any such data is not in a separate directory on the media. If such data is referenced in the INDEX.HTM file, it shall 3525 be clearly indicated that this content was not generated in conformance with the IHE Radiology Technical Framework, and its reliable import has not been addressed. 15.4.4 Media Type (CD, DVD and USB) The baseline media type is CD with uncompressed images. Named options for support of compressed images (using JPEG lossy and lossless and JPEG 2000 3530 reversible and irreversible) on DVD and USB media are defined. Compressed images on CD, such as are commonly used for cardiac angiography and for cine ultrasound, are supported through the use of the DVD Media Option, which allows for CD as a media type that can be read by DVD drives. Security and Privacy Aspects 3535 15.5 s shall make a reasonable effort to ensure that no malicious Actor Portable Media Creator software (viruses, etc.) is present on created media. The automatic launch of applications from media poses a risk that malicious software could be started and it is recommended that media reading actors not allow automatic launching. Portable Media Creators should therefore also avoid using automat ic launching. This includes not 3540 automatically launching a DICOM media viewer that may be present on the media. at the receiving actor are Furthermore, if a DICOM media viewer is present, security issues minimized by: working under normal (restricted) user privileges and not requiring the user to work with • 3545 administrator or root privileges and • not needing software installed on the computer where the media is used. -2: 3.20 and RAD Audit trails to track export/import/viewing activities are addressed in ITI TF TF-3: 5.1. Portable Media Creator and media reading actors that claim support of the Audit Trail and Node Authentication Integration Profile shall generate such audit trail entries. Encryption of data and other access controls to media content are not addressed in this profile. 3550 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 not give a patient a disk containing data from other patients, do not leave disks where they can be taken by unauthorized persons, etc.). volume For many Use Cases it is not appropriate to place data from multiple patients on a single 3555 easons. ecurity and privacy r of media for s ice to include on media, either in the physical label, in the DICOMDIR or It is not good pract DICOM instances, the Web Content or any other content, such sensitive information as the patient’s address, telephone number or national identifier (such as a US Social Security ____________________________________________________________________________ 173 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

174 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Numb er), which might be used for unauthorized purposes such as identity theft or fraud. Though 3560 it is not a requirement of this profile to require the Portable Media Creator to remove any such edia, it is strongly information from any DICOM instances received prior to encoding on m recommended. ____________________________________________________________________________ 174 : IHE International, Inc. Copyright © 2018 – Final Text 201 7.0 Rev. 1 8-07-27

175 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ NM Image Integration Profile 16 3565 The NM Image Profile specifies how NM Images are to be stored by Acquisition Modalities and . Evidence Creator workstations and how Image Displays should retrieve and make use of them It define s 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 creat ed by NM Cardiac Processing Packages, should be stored using DICOM objects that can be displayed on general 3570 purpose Image Display systems. is undergoing revision, and vendors considering implementation Note that the NM Image Profile are advised to include the modifications contained in the trial implementation version “NM . For additional information please contact the IHE Image Profile with Cardiac Option” 3575 [email protected] -Rad Radiology Technical Committee at IHE The NM Image Profile can be enhanced b y combining it with workflow profiles such as -Processing Workflow and Reporting Workflow which address how Scheduled Workflow, Post to schedule, manage and report the status of the steps in which NM Image objects are created. Actors/ Transactions 16.1 .1- 3580 1 shows the actors directly involved in the NM Image Integration Profile and the Figure 16 . Other actors that may be indirectly involved due to their relevant transactions between them -Processing Workflow Profile, etc. are participation in the Scheduled Workflow Profile, the Post not necessarily shown. ____________________________________________________________________________ 175 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

176 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Evidence Creator Image Display RAD - 18: Creator - 10: Storage Commitment ↓ RAD Images Stored ↓ - RAD 14: Query Images ↓ ↓ 16: Retrieve Images RAD - Image Image Archive Manager RAD - 8: Modality Images - ↑ RAD 10: Storage Commitment ↑ Stored Acquisition M odality 3585 1: NM Image Actor Diagram Figure 16.1- 1 lists the transactions for each actor directly involved in the NM Image Profile. In Table 16.1- tegration profile , an implementation must perform the required order to claim support of this in transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of named options defined by this integration profile and that implementations 3590 may choose to support is listed below in Section 16.2. 1: NM Image Integration Profile - Actors and Transactions Table 16.1- TF Actors Transactions Optionality Reference -8] Modality Images Stored [RAD 4.8 -2: RAD TF R Acquisition Modality R RAD TF -2: 4.10 -10] Storage Commitment [RAD Creator Images Stored [RAD -18] R RAD TF -2: 4.18 Evidence Creator Storage Commitment [RAD -10] R RAD TF -2: 4.10 Image Manager/Archive Modality Images Stored [RAD -8] R RAD TF -2: 4.8 Creator Images Stored [RAD 4.18 -18] R RAD TF -2: -10] R RAD TF -2: 4.10 Storage Commitment [RAD R Query Images [RAD -14] RAD TF -2: 4.14 Retrieve Images [RAD -16] R RAD TF -2: 4.16 4.14 Image Display Query Images [RAD -14] R RAD TF -2: 4.16 -2: RAD TF R -16] Retrieve Images [RAD ____________________________________________________________________________ 176 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

177 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 data from original NM modality image data . Examples of such derivative data include: 3595 a) Reconstruction, reorientation, filtering, or other processing of NM data, with output of NM moda lity 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. For all NM modality objects created, the evidence creator must meet the requirements of an 3600 acquisition modality with respect to encoding, storage, and inclusion of required DICOM tags, as -2: 4.8.4.1.2.2. noted in RAD TF If the system creates SC or MFSC objects, the evidence creator is encouraged to support the Result Screen E xport Option, and conform to the requirements of this option for any stored result screens. 3605 NM Image Integration Profile Options 16.2 1 along with are listed in the Table Options that may be selected for this integration profile 16.2- the Acto . Dependencies between options when applicable are specified in rs to which they apply notes. Actors and Options 1: Evidence Documents - Table 16.2- 3610 Actor Options TF Reference Acquisition Modality No options defined -- RAD TF -2: 4.18.4.1.2.4 Evidence Creator Result Screen Export Option -2: 4.16.4.2.2.4 RAD TF Image Archive/Manager -- No options defined -2 : 4.16.4.2.2.2.5 RAD TF Review Option Image Display 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 by . It should also be sufficient for secondary review (without reprocessing referring physicians capability) of cardiac nuclear medicine studies by cardiologists and for correlation of nuclear 3615 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 be . static or may contain moving components) in commonly displayable DICOM formats s which support Result Screen Export should claim the appropriate Actor Acquisition Modality 3620 . options as an Evidence Creator ____________________________________________________________________________ 177 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

178 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Processing functions of both cardiac and non- cardiac data are not addressed in this profile, and should be performed on a dedicated NM workstation. NM Image Process Flow 16.3 Evidence Creator/ Acquisition Image Manager/ Image Display Image Display Modality Image Archive Perform Acquisition Modality Images Stored NM Images - Storage Commitment Query Images Retrieve Images - NM Images Generate Result Screens Creator Images Stored Result Screens - Storage Commitment Query Images NM Images Retrieve Images - Retrieve Images Result Screens - Present NM Images & Result Screens to User 3625 1: NM Image Process Flow Figure 16.3- storing and using NM Image content can be managed in much the same The process of creating, -Processing Workflow way as other image content using the Scheduled Workflow and Post 3630 Profiles . Examples of NM Workflow and Guidelines for carrying it out using the two mentioned rofiles can be found in Appendix E: Nuclear Medicine. Workflow P ____________________________________________________________________________ 178 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

179 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Teaching File and Clinical Trial Export (TCE) 17 This profile defines a means of selecting the relevant images, key image notes, reports, evidence which would typically be grouped documents and presentation states on the Export Selector ( with an Acquisition Modality, Image Display, Evidence Creator or Report Creator), a means to 3635 enter 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 Image r Portable Media Creator). 3640 Manager/Archive o 17.1 Actors/Transactions 1 shows the actors directly involved in the Teaching File and Clinical Trial Export Figure 17.1- Integration Profile and the relevant transactions between them . Other actors that may be e to their participation in Key Image Note, Consistent Presentation of indirectly involved du 3645 Images, Evidence Document, Simple Image and Numeric Report and Portable Data for Imaging Profiles, etc. are not shown. Export lector Se ↓ Stor - [RAD t Selection e Expor 51] Store In sta nce s -50] [RAD ↓ ↓ i e Add Stor ti on al T each ing Fi le n [RAD atio Inform -52] Export Manager Export Ins tanc es - [RAD 53] ↓ Receiver cal Trial Export Actor Diagram 1: Teaching File and Clini Figure 17.1- 1 lists the transactions for each actor directly involved in the Teaching File and Table 17.1- 3650 , an Clinical Trial Export Profile. In order to claim support of this integration profile implementation must per form the required transactions (labeled “R”). Transactions labeled “O” and that are optional . A complete list of options defined by this integration profile implementations may choose to support is listed in Section 17.2. ____________________________________________________________________________ 179 8-07-27 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 Copyright © 2018

180 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table 17.1- 1: Teaching File and Clinical Trial Export Integration Profile - Actors and 3655 Transactions Transactions Optionality TF Reference Actors Store Instances [RAD -50] R (see Note) Export Selector RAD TF -3: 4.50 4.51 R Store Export Selection [RAD RAD TF -3: -51] Store Additional Teaching File O RAD TF -3: 4.52 -52] Information [RAD RAD TF Export Manager -50] R (see Note) Store Instances [RAD -3: 4.50 R -51] RAD TF -3: 4.51 Store Export Selection [RAD Store Additional Teaching File R RAD TF -3: 4.52 Information [RAD -52] Export Instances [RAD -53] R RAD TF -3: 4.53 Export Instances [RAD 4.53 -3: RAD TF R -53] Receiver -50 Store Instances Note: If the Export Manager is grouped with an Image Manager/Archive, there is no need for RAD transactions between the Export Selector and the Export Manager as long as the instances are already available to the Export Manager. 3660 17.2 Teaching File and Clinical Trial Export Integration Profile Options Options that may be selected for this integration profile are lis ted in the Table 17.2- 1 along with the a ctors to which they apply . Dependencies between options when applicable are specified in notes. 1: Teaching File and Clinical Trial Export - Actors and Options 3665 Table 17.2- Options TF Reference Actor RAD TF -1: 17.2.3 Export Selector Additional Teaching File Information -3 : 4.52 RAD TF Delay for Reason RAD TF -1: 17.2.4 -3 : 4.51.4.1.5 RAD TF De -identify Pixel Data Export Manager RAD TF -1: 17.2.1 RAD TF -3 : 4.51.4.1.4.4 RAD TF Remap Identifiers -1: 17.2.2 -3 : 4.51.4.1.4.3 RAD TF Additional Teaching File Information -1: 17.2.3 RAD TF RAD TF -3 : 4.52 -1: 17.2.4 RAD TF Delay for Reason RAD TF -3 : 4.51.4.1.5 Additional Teaching File Information RAD TF -1: 17.2.3 Receiver -3 : 4.53 RAD TF ____________________________________________________________________________ 180 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

181 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -identify Pixel Data Option De 17.2.1 -identifying instances by removing In the default case, the Export Manager is responsible for de the necessary DICOM attributes or replacing them with alternative identification values (pseudonymization), without invalidating the IOD. This operation would normally be fully 3670 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 Ultrasound and Secondary Capture images, it is difficult to remove this automatically. Accordingly, a human operator would use an appropriate user interface to “black out” offending areas of text. 3675 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. The option does not specify constraints on how this capability might be implemented, either in user or ed work list for operators terms of workflow, such as providing an internally manag interface features, such as the size, shape and number of graphic operations needed for editing 3680 the pixels. Remap Identifiers Option 17.2.2 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 3685 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 band mechanism, such as a data transmittal form. 3690 However, c linical trial workflow is greatly enhanced if the subject enrollment list is used to remap the patient’s actual identifiers to the trial subject identifiers, and additional clinical trial ity is the “remap identifiers attributes are inserted into the header. Provision of such a capabil option”. Further, in some protocols, the list of expected studies and their mapping to pre -defined time 3695 points is known in advance, and the remapping capability could take advantage of this knowledge, if available. This named option requires that such a remapping capability be present. The option does not specify constraints on how this capability might be implemented, either in terms of configuration, such as providing a user interface or preloading capability for the subject 3700 -driven generation of enrollment list or remapping table, or sophistication, such as providing rule 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 the -3: 4.51.4.1.4.3. -51] transaction in RAD TF description of the Store Export Selection [RAD ____________________________________________________________________________ 181 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

182 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Additional Teaching File Information Option 17.2.3 3705 The manifest of instances to be exported (the Export Selection) consists of references only, with mation. To allow for the user of the Export Selector to not only flag instances no additional infor for 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 be 3710 -51] Key Object Selection document references the exported. The Store Export Selection [RAD Additional Teaching File Information SR instances. Once pseudonymized, this information is exported using the Export Instances [RAD- 53] t ransaction just like any other instance. 17.2.4 Delay for Reason Option 3715 Images may have been selected for teaching before the final pathological diagnosis or other -identified before transfer to the authoring system, information is known, yet may need to be de nt to the after which additional material cannot be linked. Since such information may be importa integrity of the teaching file, this option defines a mechanism for the Export Manager to delay export until the system has received the specified information, and then to forward both to the Receiver. 3720 Implementation Issues 17.3 This profile is designed with the following implementation scenarios in mind: Scenario 1: The Export Manager is grouped with an Image Manager/Archive. In this case, there is no need for Store Instances [RAD- 3725 t Manager, 50] transactions between the Export Selector and the Expor as long as the instances are already available to the Export Manager. Scenario 2: The Export Manager is not grouped with an Image Manager/Archive. In this case, Store 50] Instances [RAD- transactions between the Export Selector and the Export Manager are used to make the instances available to the Export Manager. 3730 Scenario 3: The Receiver is grouped with a Portable Media Creator and claims support of the Portable Data for Imaging Profile. In this case the instances and manifest received a re recorded to media. Scenario 4: 3735 The Export Manager is grouped with the Image Manager/Archive in System A. The Receiver is grouped with an Image Manager/Archive in System B. In this case, the exported instances and manifest are made available in System B. ____________________________________________________________________________ 182 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

183 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Teaching File and Clinical Trial Export Integration Profile Process 17.4 Flow This section describes the typical process flow related to the selection, pseudonymization and 3740 export of images, key image notes, reports, evidence documents and presentation states during the creation of a teaching file or for a clinical trial. through [ 50] RAD- . 53] RAD- The transactions covered are [ In general, the process flow is as follows. s On an Export Selector, the user selects images, key image notes, reports, evidence document 3745 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). The Export Selector is possibly grouped with an Image Display, an Acquisition Modality, an 3750 Evidence Creator and/or a Report Creator. When grouped with an appropriate Actor participating in the appropriate Profile, the device may also be capable of displaying or importing Portable d retrieval of Reports (SINR Profile), Evidence Documents (ED Media (PDI Profile), query an Profile), 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 3755 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. The instances are transferred to the E xport Manager, unless the Export Manager is grouped with 3760 an 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. The Export Manager is capable of replacing patient identifiers with pseudonymous identifiers, y possibly according to some pre -registered mapping scheme or arbitrarily, and optionall 3765 -identification, and optionally delaying providing manual editing of the pixel data to perform de 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). 3770 ____________________________________________________________________________ 183 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

184 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Export Receiver Export tor lec anager Se M -50] AD [R ces n sta Store In 52] - AD R [ Info F T l ion a it d Store Ad [RAD -51] Selection Export Store Dela y for Pathology y f ti n -ide De ttrib ute s A ify nt ide De - Pixel Dat a Remap ifiers Ident 53] - es [RAD tanc Export Ins l Trial Export Profile 1: Basic Process Flow in Teaching File and Clinica Figure 17.4.1- ], [RAD and transactions is not specified; these -52] [RAD Note 1: In Figure 17.4.1 -1, the sequence of the [RAD -50 -51] transactions may overlap or occur in any order. 3775 -1, the [RAD -50] transaction may be elided if the Export Manager is grouped with the Image Note 2: In Figure 17.4.1 Manager/Archive. The following use cases are not intended to be exhaustive nor in any way to constrain the manner e of scenarios from simple to in which the profile is implemented. Rather they illustrate a rang 3780 complex that may be satisfied with the same actors and transactions. To provide context, in some use cases, behavior is described that is outside the scope of this profile. Further, they serve to similarities between workflows for teaching files and clinical trials. illustrate the differences and ____________________________________________________________________________ 184 Rev. 1 7.0 – Final Text 201 8-07-27 : IHE International, Inc. Copyright © 2018

185 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Teaching File Use Cases 17.4.1 The teaching file is a vital tool in medical education. Traditionally assembled from collections of 3785 images. Digital media enables film, teaching files now need to be constructed from digital 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 3790 on the Acquisition Modality. Relevant images, series or studies are often identified whilst the n; hence need to be flagged for later authoring. author is engaged in other tasks such interpretatio Enterprises frequently restrict access to information containing a patient’s identity on systems on authored; hence the images and related information may need which teaching files are typically -ide to be de ntified before transfer to the authoring system. Distribution of teaching files beyond -identification. 3795 an institution always involves de – Images Selected for Teaching File During Reporting, Review Use Case 1 17.4.1.1 or Acquisition User Actions: erforming diagnostic reporting of possibly many studies for different patients A radiologist is p during the course of the day. Alternatively, the radiologist is consulting on a study received from 3800 -guided biopsy on an a referral patient on CD. Or, the radiologist is performing an image acquisition device. Images from a particular patient are noted to be of special interest and potentially suitable for teaching. 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 3805 -modality fusion may be required. No studies, such as when later 3D reconstruction or multi additional information is entered at this time since the radiologist is busy. the radiologist will access his teaching file collection and use a teaching file later, Sometime -media teaching file. The manner in authoring program on his personal computer to create a multi which the teaching file is authored and distributed is beyond the scope of thi s profile. 3810 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 outside facility or if the clinical and teaching networks are not connected). Implementation: The radiologist is viewing images on an Image Display grouped with an Export Selector. The 3815 Image Display is also participating in the Portable Data for Imaging Profile in the case of the he radiologist is working on an Acquisition Modality grouped review of the referral CD. Or, t with an Export Selector. The Export Selector allows one or more images from current and prior studies to be selected, and then to be “exported for teaching”. 3820 ____________________________________________________________________________ 185 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

186 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ red to know that the images are already stored on an The Export Selector may be preconfigu Image Manager/Archive with which the Export Manager is grouped; in such a case no Store -50] -50] transactions are required. In the media case, Store Instances [RAD Instances [RAD transactions would be required. The user action triggers a Store Export Selection [RAD -51] transaction to the Export Manager. 3825 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 sel ected, 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 3830 allow the user to identify which teaching file the images are intend ed for, a free text field or a pre -configured pull down list is provided, which is encoded as the disposition in the text value of the Key Object Selection document. g File No additional content was entered at the time of selection, so no Store Additional Teachin -52] transaction is sent. Information [RAD 3835 If the Export Manager is not grouped with an Image Manager/Archive that already has the -50] transaction, the Export images, upon receiving the images via the Store Instances [RAD Manager stores them internal ly. When the Export Manager receives the Store Export Selection [RAD -51] transaction, and all the images referenced therein are available, the collection is queued for pseudonymization and 3840 export. fication from the image attributes as The Export Manager automatically removes all patient identi well 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 erts new dummy patient identification and other text attributes so as not to pixel data, and ins 3845 -identification is invalidate compliance of the instance with the IOD. Note that the extent of de -identification is to be performed in the teaching file authoring system configurable, and if de later, may not be performed by the Export Manager at all. This may be the case when the patient’s identity is required by teaching file authoring system to allow the user to search for other clinical and historical information. If the Export Manager supports the De 3850 -identify Pixel Data Option, any of the images likely to contain 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. 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 the 3855 -53] transaction. appropriate Receiver using an Export Instances [RAD The Receiver may be the enterprise’s central teaching file authoring system. Upon receiving the est from images and the manifest, it extracts the identity of the radiologist who created the manif the Person Observer Identifying Attribute template encoded within the Key Object Selection ____________________________________________________________________________ 186 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

187 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 3860 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 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. Use Case 2 – Com plete Teaching File Authoring During Reporting with 3865 17.4.1.2 Multiple Instance Types and Multiple Export Targets User Actions: A radiologist is performing diagnostic reporting. Images from a particular patient are noted to be of special interest and potentially suitable for teaching. In addition to having the clinical report for the current case that has just been created, the radiologist has also queried for prior reports, 3870 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, as 3875 well as several evidence documents and the surgical pathology report, and decides to create a teaching file. - The workstation then prompts the radiologist to enter additional information according to a pre defined 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 3880 ell as selecting editing capability to cut and paste from the various reports into the template, as w organ system, anatomy and diagnoses from pick- lists of codes. Upon completion, the user instructs the workstation to release the case, which is then made with a available throughout the enterprise on the PACS and electronic medical record systems pseudonymous identification in the departmental teaching collection folder, as well as via the web both inside and outside the enterprise. 3885 Implementation: The radiologist is viewing images on an Image Display grouped with an Export Selector, as wel l as 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 the 3890 Consistent 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”, 3895 together with the additional information. ____________________________________________________________________________ 187 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

188 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ l Teaching File -50] transactions, Store Additiona The user action triggers Store Instances [RAD -51] transactions -52] transactions and multiple Store Export Selection [RAD Information [RAD to the Export Manager (one for each Receiver). The manifest is encoded as a Key Object Selection document. The additional information is 3900 encoded as a Structured Report according to a pre -defined template. -identifies the image, reports, evidence documents, The Export Manager de -identifies and re presentation states and additional information with pseudonymous values as in Use Case 1. then sends the pseudonymized DICOM instances, the pseudonymized The Export Manager 3905 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 53] transactions. [RAD- 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 3910 m, and another Receiver that is a portal to a central -based teaching file distribution syste own web 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: st is performing diagnostic reporting. Images from a particular patient are noted to be A radiologi 3915 of special interest and potentially suitable for teaching. The radiologist selects several relevant -identified and saved to his t eaching file collection. images from the current study to be de 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” 3920 modifier to the “export for teaching” action. Implementation: The implementation proceeds as in Use Case 1. The Key Object Selection document, in addition to having a Document Title that indicates that the case is for teaching file export, also has a coded Concept Modifier indicating “Delay for 3925 histopathology report”. When the Export Manager receives the Store Export Selection [RAD -51] transaction, and all the images referenced therein are available, the collection is queued. However, since the Export -configured rules within the Export Manager Manager supports the Delay for Reason Option, pre 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 3930 -identifying and pseudonymizing 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 and outside the scope of this profile, but it must be re -encoded in a DICOM Structured Report ____________________________________________________________________________ 188 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

189 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ plain text) for export to the Receiver, and a reference to it included in a revised (perhaps as 3935 manifest. 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 syst -center trials. ems, and other organizations in the case of multi During export, images need to be de specific identifiers inserted in -identified and trial- 3940 accordance with local or national policy and the rules of the trial protocol. The following use cases serve to illustrate the differences and similarities between workflows for teaching files and clinical trials. Use Case 4 – Series or Studies Selected for Clinical Trial from Referring 17.4.2.1 User’s Workstation or Acquisition Modality 3945 User Actions: center clinical trial undergoes an examination, the images of which olled in a multi- A patient enr require review by a central facility. Though the patient has given their informed consent to - es that the images be de release their identification (PHI) to the central facility, site policy dictat identified first regardless. The managers of the trial supply replacement identifiers to be used. 3950 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 the relevant study, or selected series from the study, for export to the central facili ty. 3955 Implementation: In this case, the user is viewing images on an Image Display or Acquisition Modality grouped with an Export Selector. The Export Selector allows images, series and studies to be selected, and then to be “exported for clinical trial”. Th e 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 3960 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 intended for, a one trial, hence to allow the user to identify which clinical trial the images are 3965 free text field or a pre- configured pull down list is provided, which is encoded as the disposition in the text value of the Key Object Selection document. -identifies the image, reports, evidence doc The Export Manager de uments, -identifies and re 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 specific identifiers, both as replacements for the conventional patient the images with the trial- 3970 ____________________________________________________________________________ 189 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

190 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 subject enrollment list). The Export Manager inserts replacement patient identification and clinical trials attributes obtained from its mapping table. 3975 The Export Manager Actor then sends the pseudonymized DICOM images and an updated manifest to a Receiver as in Use Case 1. W -configured or hich Receiver to send to may be pre 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 consideratio ns, typically it will use a secure Internet channel, 3980 such as a VPN, TLS (SSL) or SSH tunnel. The security mechanism is beyond the scope of this profile. Or, the Receiver could be grouped with a Portable Media Creator, as described in Use Case 1, in which c ase CDs would be burned and mailed to the central review facility. This use case is distinguished from the teaching file use cases in that: 3985 Selection is usually at the study or series level, and rarely at the image level • t identifiers is defined in the Export Manager -defined replacemen A mapping to pre • • 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 3990 The selection of instances or entire studies for research purposes shares many similarities with use cases for teaching files and clinical trials. The studies generally remain in circulation for clinical use, as well as being “copied” into separate “folders” in the clinical Image identification Manager/Archive or copied to a separate research Image Manager/Archive. De- may not be required for local research collections, but for those maintained centrally (outside the 3995 enterprise) , remapping of identifiers to predefined pseudonyms is often required. A specific Document Title of “For Research Collection Export” is provided for such use cases, ses in which are otherwise no different from the foregoing teaching file and clinical trial use ca terms of user actions, actors or sequencing of transactions. Publication Authoring Use Cases 17.4.4 4000 The selection of instances for use in a publication shares many similarities with use cases for identification of the DICOM Header and the pixel data is required. The teaching files. De- 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, 4005 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 Figure 17.4.1- 1. ____________________________________________________________________________ 190 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

191 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ .b) (XDS-I -Enterprise Document Sharing for Imaging Cross 18 Integration Profile The Cross- Enterprise Document Sharing for Imaging (XDS -I) 4010 IMPORTANT NOTE : nd here) has been deprecated and is replaced by a Integration Profile (originally fou functionally equivalent profile called Cross -Enterprise Document Sharing for Imaging (XDS - ection. I.b), which is des cribed in the remainder of this s -Enterprise Document Sharing (XDS.b) Profile in the IHE IT Infrastructure Domain The Cross provides a solution for sharing (publishing, finding and retrieving) documents across a group of 4015 affiliated enterprises . The XDS for Imaging (XDS -I.b) Profile, defined here, extends and y XDS.b to support imaging “documents”, specifically specializes the mechanisms defined b including the following: Imaging studies that include images acquired on a broad range of different modalities, as • 4020 well as evidence documents (e.g., post -processing measurements/analysis outcome), and presentation states. Diagnostic reports resulting from the interpretation of one or more related imaging • display form -for- studies provided in a ready A selection of diagnostically significant images associated with the report content. • These document types along with the actor capabilities required to share them are defined by this 4025 profile. 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 Dom ain, submission set, etc.) the reader of XDS -I.b is expected to have read and understood the XDS -1: 10). The XDS 4030 Profiles (See ITI TF -I.b specification does not repeat requirements and text for -defined Actors Document Repository, Document Registry, and Document Consumer, the XDS and does not place any new requirements on these actors. -I.b) Integration Profiles are not intended to address Both the XDS.b and XDS for Imaging (XDS -enterprise EHR communication needs. Many scenarios may require the use of other all cross IHE Integration P rofiles, such as Patient Identifier Cross -Referencing (PIX), Audit Trail and 4035 Node Authentication (ATNA), Enterprise User Authentication (EUA), Cross -Enterprise User y Authentication (XUA) and Retrieve Information for Display (RID). Other scenarios may be onl partially supported, while still others may require future IHE rofiles, which will be Integration P defined 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 s ecurity model be 4040 put in place. It is expected that a range of security models should be possible. Although -I.b Integration Profile is not intended to include nor require any specific security the XDS -I.b a model, it is required that XDS ctors with actors -I.b implementers shall gr oup XDS from the IHE Audit Trail and Node Authentication and will need an Access Control Integration -enterprise environment. New IHE capability that operates in such a cross 4045 s have been identified as candida Profile tes (e.g., Public Key Infrastructure, Access ____________________________________________________________________________ 191 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

192 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. -I.b do not address transactions for the management or configuration of an XDS and XDS 2. XDS Affinity Domain. For ex ample, the configuration of network addresses or the 4050 definition of what type of clinical information is to be shared is specifically left up to the policies established by the XDS Affinity Domain. -I.b do not specifically address the patient inf XDS and XDS 3. ormation 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 4055 -1: Appendix G. discussion of some of these issues see RAD TF 4. -I.b do not directly address the rendering and display of the documents d XDS XDS an retrieved by the Document and Imaging Document Consumers. Users wishing to achieve -defined level of display/ rendering capability simply need to request systems that a well combine the XDS -I.b Imaging Document Consumer Actor with an Image Display Actor 4060 from the appropriate Profile (e.g., Mammography Image, NM Image, Basic Image ). Review, etc. -I.b do not directly address the rendering and display of the documents XDS and XDS 5. ed by the Document and Imaging Document Consumers. Users wishing to achieve retriev -defined level of display/ rendering capability simply need to request systems that a well 4065 -I.b Imaging Document Consumer Actor with an Image Display Actor combine the XDS from the a ppropriate Profile (e.g., Mammography Image, NM Image, Basic Image Review, etc. ). Actors/ Transactions 18.1 Figure 18.1- 1 shows the actors directly involved in this profile and the transactions between 4070 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/XOP -I.b Profile 1. The XDS ed actors are not listed in Table 18.1- . As a result, the shad Transaction) 4075 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. ____________________________________________________________________________ 192 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

193 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Registry Stored Query [ITI - 18] ← Document Registry Document Consumer (XDS.b) (XDS.b) Document Imaging ↑ Register Consumer 42 - b – Document Set ] [ITI Retrieve D ocument Provide Register Imaging & [ITI ] 43 Set - [RAD Document Set MTOM/XOP - 68 ] – ← → Document Repository (XDS.b) - WADO Retrieve [ RAD 55] ← Imaging Document 69 Retrieve Imaging Document Set [RAD - ← ] Source RAD - 16] ← Retrieve Images [ RAD - 17] ← Retrieve Presentation States [ 27] RAD Retrieve Reports [ ← - RAD - 31] ← Retrieve Key Image Note [ - Retrieve Evidence Documents [ RAD 45] ← ocument Sharing for Imaging Diagram Enterprise D Figure 18.1- 1: Cross- -Enterprise Table 18.1- 1 lists the transactions for each actor directly involved in the Cross Document Sharing for Imaging (XDS -I.b) Profile. In order to claim support of this integration 4080 profile , an implementation shall perform the required transactions (labeled “R”). Transactions . A complete list of options defined by this integration profile labeled “O” are optional is listed in n Section 2.4. Section 18.2. Note the grouping of actors described i ____________________________________________________________________________ 193 Copyright © 2018 Rev. 1 7.0 – Final Text 201 : IHE International, Inc. 8-07-27

194 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -enterprise Document Sharing for Imaging Integration Profile - Actors 4085 Table 18.1- 1: Cross and Transactions Actors Transactions Optionality TF Reference 4.16 Retrieve Images [RAD -16] O (note 1) Imaging Document RAD TF -2: Consumer -17] O RAD TF -2: 4.17 Retrieve Presentation States [RAD Retrieve Reports [RAD O (note 1) RAD TF -2: 4.27 -27] Retrieve Key Image Note [RAD -31] O RAD TF -2: 4.31 Retrieve Evidence Documents [RAD O (note 1) RAD TF -3: 4.45 -45] -55] O (note 1) RAD TF -3: 4.55 WADO Retrieve [RAD -69] -3: O (note 1) RAD TF Retrieve Imaging Document Set [RAD 4.69 Imaging Document 4.68 Provide and Register Imaging Document -3: RAD TF R (note 2) Source -68] – MTOM/XOP [RAD Set Retrieve Images [RAD -16] R (note 3) RAD TF -2: 4.16 RAD TF R (note 3) -17] Retrieve Presentation States [RAD 4.17 -2: -27] R (note 3) RAD TF -3: 4.27 Retrieve Reports [RAD Retrieve Key Image Note [RAD -31], R (note 3) RAD TF -3: 4.31 R (note 3) Retrieve Evidence Documents [RAD -45] 4.45 -3: RAD TF 4.55 WADO Retrieve [RAD -55] R (note 3) RAD TF -3: RAD TF -3: Retrieve Imaging Document Set [RAD -69] R (note 3) 4.69 ection 18.4 for additional Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to S on the Imaging Document Consumer. requirements Note 2: Support of at least one of the four 18.2 is required. document types described by the options in Section Note 3: These transactions are only required if the Imaging Document Source supports the ‘Set of DICOM Instances’ 4090 as described in Table 18.2 -1. Option 18.2 Integration Profile Options Options that may be selected for this integration profile are listed in Table 18.2- 1 along with the Actors to which they apply . Dependencies between options when appli cable are specified in notes. 4095 Table 18.2- 1: Cross -enterprise Document Sharing for Imaging - Actors and Options TF Reference Actor Options -1: 18.2.1 Set of DICOM Instances RAD TF Imaging Document Source (Note 1) PDF Report (Note 1) -1: 18.2.2 RAD TF ® 3 RAD TF Wrapped Text -1: 18.2.3 CDA Report (Note 1) CDA Imaging Report -1: 18.2.4 RAD TF with Structured Headings (Note 1) 3 is the registered trademark of Health Level Seven International. CDA ____________________________________________________________________________ 194 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

195 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Reference Options Actor No options defined - Imaging Document Consumer options is required Note 1: At least one of these four 18.2.1 Set of DICOM Instances Option This option requires the Imaging Document Source to create a DICOM manifest that references 4100 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 a published manifest are available to be retrieved. For details of the transaction affected by this -3: 4.68.4.1.2.1. option, refer to RAD TF 18.2.2 4105 PDF Report Option aging Report in This option requires the Imaging Document Source to provide and register an Im a PDF format to the Document Repository. The published report may contain embedded images -DICOM format. The Imaging Document -computed links that reference images in a non or pre Source is required to ensure that image references are valid l inks. For details of the transaction affected by this option, refer to RAD TF -3: 4.68.4.1.2.2. 4110 CDA Wrapped Text Report Option 18.2.3 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 4115 This 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 Flow The sharing of imaging related information among different health professionals and facilities, even across administrative and geographic boundaries can lead to a large variet y of information 4120 flows. Typical imaging information sets used in healthcare settings are well known, but the challenge is to distill the “exchange” scenarios to drive the sharing of imaging information across enterprises distributed over a community, region or nation. 18.3.1 Overview of Imaging Information Sharing Use Cases The following use case scenarios express the core imaging information sharing common to most 4125 . They cover: clinical settings Routine imaging referral 1. . The referring physician in his office requests that a patient have an examination done at an imaging facility . The physician expects to have electronic ____________________________________________________________________________ 195 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

196 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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. 4130 Course of Treatment Consult 2. . 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 hospita l for advice on a course of . For this, the surgical specialist accesses the images and preliminary report and action 4135 reviews them in order to propose, on the phone, a course of action for the patient. This use case is further analyzed in this profile. . A general practitioner performs a routine imaging referral, reviews the ical Consult 3. Clin shared imaging report and chooses to send the patient for evaluation by a specialist (e.g., . The specialist needs access to the imaging report and full image set an oncologist) produced at the imaging facility where the patient had been sent by his general 4140 practitioner to perform the examination. This use case is further analyzed in this profile. 4. . hysician . A patient relocates or decides to change her p General imaging record access 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 a patient is admitted for an emergency and timely access to the patie 4145 nt’s past information is required, 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 -CR) for sharing across enterprises as longitudinal patient’s imaging diagnostic documents (EHR -LR). The policies or administrative details regarding the sharing of patient care records (HER 4150 imaging information are for the most part not explicitly discussed so as not to obscure clinical . Administrative variations between countries and regions are expected, and can be added needs -sharing context. or modified without losing the clinical information Since the focus is on the sharing and access to patients imaging records rather than the entire kflow in which such information sharing takes place, other activities are described as though wor they are being done by telephone, paper mail, fax, etc . In an integrated electronic environment 4155 these other activities may be more automated, but those details ar e separate from the records s. access/sharing and are to be addressed by separate integration profile 18.3.2 Assumptions The imaging information needs to be shared between multiple care delivery organizations . The point of 4160 (information sources and consumers), each (typically) with its own RIS and PACS service (“POS”) for physicians may be supported by a variety of systems: hospital EMR, physician practice system, PACS viewers, EHR web application, etc. The concept of sharing information across enterprises that have agreed to join in such a health information network is based on basic design principles that can be summarized in the following 4165 points: ____________________________________________________________________________ 196 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

197 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ A group of healthcare enterprises have agreed to work together using a common set of 1. policies and to share a common infrastructure of repositories and a registry for an affinity domain. 2. Information sources (e.g., EHR, lab system, PACS) select the “documents” they wish to share. 4170 nt, a 3. Documents may include any information in an agreed format (e.g., a PDF docume DICOM manifest, etc.) . Documents are stored in multiple document repositories. 4. Shared documents are registered with a central service called a document registry that tracks only indexing information and the location from which documents may be 4175 ved. retrie Information consumers may query this well 5. -defined unique/singular indexing service (document registry) to find the document index information for any patient and the location from which documents may be retrieved (document repositories). ources remain the owner of the documents shared in repositories and, Information s 6. 4180 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 that participa te in a single “Affinity Domain” have agreed upon mechanisms to address: Governance: operational structure, data stewardship, etc. • • Privacy: consent management and data masking controls ils, etc. 4185 Security: Authorization and authentication, network security, audit tra • • 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 4190 This scenario describes imaging information sharing in a typical patient referral and reporting use case where: An examination is performed upon the request of a referring physician: • The referring physician accesses the regional health information network and reviews the • ly access the full image set that made report along with the key images and may optional 4195 the study. This scenario is characterized by all the information being provided for sharing at one time, as a single logical unit, when the imaging study is completed by the radiology enterprise (i.e., a single ent submission set”). “docum ____________________________________________________________________________ 197 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

198 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Process Flow 18.3.3.1.1 1 highlights the people and systems participating in this regional health Figure 18.3.3- 4200 information network, including: : A referring physician working out of a private office with a physician • Physician Office practice sys tem for access to information • RIS/PACS Enterprise A : A radiology enterprise with modality equipment and a 4205 RIS/PACS to manage report and imaging information: Radiology Enterprise A : Another radiology enterprise with a RIS/PACS to manag e report RIS/PACS Enterprise B • and imaging information: Radiology Enterprise B • : A document registry that serves as the information index for the Document Registry regional health information network In the process flow description, steps that pertain to information sharing are shown in bold (and 4210 numbered). In contrast, the steps that do not pertain to the focus of information sharing are shown in italic (and not numbered). These steps are expressed to ensure a more complete context. for this process flow. 2 shows the transaction diagram Figure 18.3.3- 4215 Exam is ordered The Referring Physician orders the examination and the patient goes to the Imaging Department: Radiology Enterprise A. This is well- understood workflow that may be executed using any combination of paper, faxes, 4220 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 of imaging of information. Step 1: Obtain Relevant Prior Imaging Information • The PACS at Radiology Enterprise A, where the acquisition and reporting is performed, 4225 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 the consumer and not the registry. • The PACS at Radiology Enterprise A retrieves prior imaging information from a 4230 repository in another radiology enterprise within the regional health network: Radiology Enterprise B, in preparation for study acquisition and subsequent reporting ____________________________________________________________________________ 198 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

199 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Radiology Enterprise B Query document Prior imaging studies Prior imaging studies Registry Query document Query document Provide Imaging Information for sharing Imaging Study Physician Office Radiology Enterprise A Affinity Domain Figure 18.3.3- 1: Data Flow within the Regional Health Network for a Routine Imaging Referral 4235 Exam is Acquired and Reported Images are sent from the modality to the PACS. This is well- understood workflow described in the SWF Profile . The study is reported. This is well understood workflow that is managed by systems within Radiology Enterprise A 4240 Step 2: Share Imaging Information within the Regional Health Network (Affinity Domain) • The PACS at Radiology Enterprise A, serving as a “Imaging Document Source”, provides imaging information to the document repository, which register the document in the registry, for sharing, including: 4245 Acquired DICOM study • Final report • • Key images along with annotations Step 3: Obtain and Display Study Results ____________________________________________________________________________ 199 7.0 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 Rev. 1

200 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 4250 A physician practice system in the Physician’s office, serving as a document consumer, • ork. This query may be queries the Document Registry in the regional health netw triggered by the patient’s next appointment, a call from the patient to the physician’s secretary, an electronic notification that the examination’s result is available (using the IHE ITI Notification for Document Availability Profil e), etc. • The physician practice system presents a list of imaging information available for the 4255 patient • The referring physician selects the study results and relevant prior studies and reports • office, serving as an Imaging Document The physician practice system in the Physician’s Consumer, retrieves the selected documents from the RIS/PACS Document Repositories 4260 in the regional health network and displays them to the referring physician. Referring Physician reviews the results The Referring Physician reviews the results of the examination: the report and images from the RIS/PACS in Radiology Enterprise A, and the results of prior examinations: reports and images from the RIS/PACS in Radiology Enterprise B 4265 Document Consumer Radiology Enterprise B Radiology Enterprise A Radiology Enterprise A Radiology Enterprise A Document Registry (Physician Office) (Document Repository) (Document Consumer) (Document Source) (Document Repository) 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 - Query for Exam Step 3 - Retrieve Final Report and Images, Relevant prior images and reports Routine Imaging Referral Use Case -2: Process Flow – 18.3.3 Figure Course of Treatment Consult Use Case 18.3.3.2 This scenario is a variation on the routine imaging referral use case in that an addendum is 4270 generated after completion of the final report. As such, this scenario is characterized by information being provided for sharing at two separate times while ensuring that the initial information is supplemented by the addendum report. on The use of addendum reports is commonly encountered in a course of treatment consultati where: ____________________________________________________________________________ 200 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

201 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 4275 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 and • annotations. • e request of the ER physician, reviews the A remotely located surgical specialist, at th report along with key images and the full study, and provides a consult to the ER 4280 physician (this use case does not constrain the method for communicating the results of the consult, e.g., phone, fax, etc. ). adiologist identifies additional information and completes an addendum to the initial • The r report. 4285 Note that the scenario where the radiologist seeks an opinion from a more senior radiologist is similar to this use case. Process Flow 18.3.3.2.1 The process flow description and steps are as for the routine imaging referral, but with the following variations (shown in bold): 4290 Exam is ordered Step 1: Obtain Relevant Prior Imaging Information Exam Acquisition and Reporting Step 2: Share Imaging Infor mation within the Regional Health Network (Affinity Domain) • The PACS at Enterprise A, serving as a “Imaging Document Source”, provides imaging information to the document repository, which register the document in the registry, for 4295 sharing, including: ired DICOM study • Acqu Report • Key images along with annotations • 4300 Step 3: Obtain and Display Study Results ER Physician reviews the results Step 4: Share Addendum to Report within the Regional Health Network (Affinity Domain) Sometime later on, the radiologist creates an addendum to the initial report. This • addendum is transcribed into the RIS at Enterprise A and signed off by the radiologist. 4305 This addendum must now supplement the initial report. The RIS at Enterprise A performs a document query of the document registry for the first • submission set . ____________________________________________________________________________ 201 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

202 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • The RIS at Enterprise A, serving as a “Imaging Document Source”, provides the addendum for sharing to the document registry including the content of the first 4310 submission set and declaring the new document as an addendum to the initial report. 3 shows the transaction diagram for this process flow. Figure 18.3.3- Rad. Enterprise A: RIS Rad. Enterprise A: PACS Rad. Enterprise A Rad. Enterprise A Rad. Enterprise B Orthopaedic Centre Document Registry Document Repository ( ( Document Consumer ) (Document Source) ( Document Source) ) (Document Repository) (Document Consumer) Step 1 - Query or relevant prior exams Step 1 - Retrieve relevant prior images and reports Step 2 - Share images and Initial Report Step 2 - Register images and report (Submission Set 1) 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) 3: Process Flow – Figure 18.3.3- Course of Treatment Consult Use Case Clinical Consult Use Case 18.3.3.3 4315 This scenario is an extension of the routine imaging referral use case in that a consult report is generated based from the original imaging exam and radiologist report. As such, this scenario is characterized 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 the 4320 reports are generated by different people and registered by different systems. eatment. As such, the The generation of consult reports is commonly encountered in cancer tr following clinical consult use case is used to describe the scenario: • A general practitioner performs a routine imaging referral (as per Use Case 1). 4325 In reviewing the imaging exam report from the radiologist, the practitioner chooses to • send the patient to an oncologist for a consultation. The oncologist, located at a Cancer Center, reviews the report along with key images, the • full study, and past imaging information records for the patient ____________________________________________________________________________ 202 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

203 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • t that is made available to the general The oncologist generates an additional repor 4330 practitioner • The general practitioner reviews the oncologists report and takes appropriate treatment action 18.3.3.3.1 Process Flow 4 highlights the people and systems participating in this regional health Figure 18.3.3- informa tion network. These are the same as for the routine imaging referral but with one 4335 additional participant: Physician Office • RIS/PACS Enterprise A • • RIS/PACS Enterprise B Document Registry • 4340 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 for reviewing imaging information within the regional health network. The EHR application has DICOM Viewing capabilities 4345 ____________________________________________________________________________ 203 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

204 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Radiology Enterprise B Physician’s Office Prior imaging studies Prior imaging Query Query studies document document Registry Prior imaging studies New Exam Query document Provide Imaging Information for sharing Provide Imaging Information for sharing ry document Que Imaging Study Radiology Enterprise A Cancer Center Affinity Domain 4: Data Flow within the Regional Health Network for a Clinical Consult Figure 18.3.3- 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). 4350 In contrast, the variations that do not pertain to the focus of information sharing are shown in italic (and not numbered). Exam is ordered Obtain Relevant Prior Imaging Information Step 1: Exam Acquisition and Reporting Share Imaging Information within the Regional Health Network (Affinity Domain) Step 2: 4355 Step 3: Obtain and Display Study Results (General Practitioner) • This is identical to Step 3 in the routine imaging referral use case ioner determines that a consult with an Based on the radiology report, the general practit • oncologist is required Step 4: Obtain and Display Study Results (Oncologist) 4360 ____________________________________________________________________________ 204 – Final Text 201 : IHE International, Inc. Copyright © 2018 Rev. 1 7.0 8-07-27

205 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The EHR application in the oncologist’s office, serving as a document consumer, queries • k. This query is triggered by a consult the document registry in the regional health networ 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, 4365 ted at Radiology Enterprise A including the most recent exam comple • 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 4370 • The oncologist reviews the images using image manipulation tools such as window level, zoom, pan, invert, measurement, etc. The oncologist may also a pply 3D rendering such as multi- planar reformatting Oncologist Generates Consult Report The oncologist reviews the results of the examination along with prior exams • 4375 The oncologist generates a consult report • Share Consult Report within the Regional Health Network (Affinity Domain) Step 5: 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 has ng the consult. reference to the original imaging exam, which was used duri 4380 5 shows the transaction diagram for this process flow. Figure 18.3.3- Cancer Centre Cancer Centre Rad. Enterprise A Rad. Enterprise A Rad. Enterprise A Rad. Enterprise B GP Office Document Registry (Document Source) Document Consumer ) ) (Document Source) ( Document Repository ( Document Consumer ( ) ) Document Repository ( (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 Step 3 - Query Images and for new exam FInal Report Step 3 - Retrieve new exam Step 4 - Query for new exam and relevant priors Step 4 - Retrieve new exam & relevant priors Step 5 - Query new exam (associated submission set) Step 5 - Share Consult Report Step 5 - Register consult report Clinical Consult Use Case 5: Process Flow – Figure 18.3.3- ____________________________________________________________________________ 205 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

206 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Queries 18.3.4 4385 As presented in the use cases, human or machine users may query the Registry in order to retrieve 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 attributes and values. The following query attributes are relevant (but not exhaustive): 4390 – The patient is expected to be identi • fied by Patient ID Patient Identity – The physician is looking for a specific exam. The attributes used to • Exam Identity identify the exam may include one or more of the following: • Date • 4395 Modality • Body part/anatomical region • Document type – images, diagnosis, progress repor t, 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 4400 The metadata in the query response needs to be sufficient to allow the system consumer to parse the response and identify relevant priors. Relevant metadata includes (but is not limited to): Exam date • Modality • Body part/anatomical region • Procedure code • 4405 18.4 Consumer Processing Consumer Processing – 18.4.1 Set of DICOM Instances When the Imaging Document Consumer retrieves a manifest from the Document Repository, it is expected 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 4410 M objects using DICOM retrieve or WADO. It should not make any assumptions about DICO whether one or more studies are referenced within the Key Object Selection Document. Patient Information Reconciliation 18.5 ppendix G. These considerations can be found in A ____________________________________________________________________________ 206 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

207 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 4415 rity considerations Secu 18.6 from -I.b actors shall be grouped with either a Secure Node or Secure Application Actor All XDS ITI ATNA Profile. These actors shall also support the Radiology Audit Trail Option. the This grouping is required to provide the capability f or security auditing, for establishing a trust relationship between systems exchanging information, and to enable secure data exchange. Some 4420 care sites may use alternate mechanisms for providing equivalent security. nd in A Other security considerations can be fou ppendix H. ____________________________________________________________________________ 207 8-07-27 Rev. 1 7.0 : IHE International, Inc. Copyright © 2018 – Final Text 201

208 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Mammography Image Integration Profile 19 The Mammography Image Profile specifies how DICOM Mammography images and evidence objects are created, exchanged and used. It describes how Acquisition Modalities transfer Full hy (FFDM) Images, how CAD systems act as Evidence Creators, and Field Digital Mammograp 4425 how Image Displays should retrieve and make use of images and CAD results . It defines the basic display capabilities Image Displays are expected to provide, and which attributes should be to implement those capabilities. used Managing the process of creating, storing and using Mammography Image content is similar to workflow for other image content (e.g., see Scheduled Workflow and Post 4430 -Processing Workflow Profiles). ile is designed to provide faithful and complete storage and The Mammography Image Prof retrieval of Mammography data and sufficient display functionality to allow adequate review of current and prior images and CAD results for the purpose of primary interpretation by 4435 . It should also be sufficient for secondary review for referring physicians. It does not radiologists address the use of other modalities appropriate for breast imaging such as MR or US. Actors/ Transactions 19.1 raphy Image Integration Profile 1 shows the actors directly involved in the Mammog Figure 19.1- and the relevant transactions between them. 4440 ____________________________________________________________________________ 208 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

209 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ reator Eviden ce C Imag e Dis play mmitment [10] ge Co Stora ↓ ce Document Eviden ↓ Query I mage s [14] ↓ Stored [43] s [16] Retrie ve Image ↓ nce Docu Query Evide ment s [44] ↓ ments [45] nce Docu Retrie ve Evide ↓ e e Imag Imag Manager Archive s ality Image Mod Stora ↑ mmitment [10] ge Co ↑ Stored [8] sition Mod ality Acqui Compo Print ser ↓ -23] ith Presentation LUT Prin t Reque st w [RAD Print Server Figure 19.1- 1: Mammography Image Profile Actor Diagram Table 19.1- 1 lists the transactions for each actor directly involved in the Mammography Image , an implementation must perform the file. In order to claim support of this integration profile Pro required transactions (labeled “R”). Transactions labeled “O” are optional 4445 . A complete list of and that implementations may choose to support is options defined by this integration profile listed in Section 19.2. Actors and Transactions Table 19.1- 1: Mammography Image Integration Profile - Actors Transactions Optionality TF Reference Modality Images Stored [RAD -8] R Acquisition Modality RAD TF -2: 4.8 Storage Commitment [RAD -10] R RAD TF -2: 4.10 RAD TF Evidence Creator Evidence Document Stored [RAD -43] R 4.43 -3: -10] R RAD TF -2: 4.10 Storage Commitment [RAD Image -2: RAD TF 4.8 -8] R Modality Images Stored [RAD Manager/Archive Evidence Document Stored [RAD -43] R RAD TF -3: 4.43 Storage Commitment [RAD -10] R RAD TF -2: 4.10 4.14 Query Images [RAD -14] R RAD TF -2: -16] Retrieve Images [RAD 4.16 -2: RAD TF R ____________________________________________________________________________ 209 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

210 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Reference Actors Transactions Optionality -3: Query Evidence Documents [RAD-44] R RAD TF 4.44 -3: RAD TF 4.45 Retrieve Evidence Documents [RAD - R 45] 4.14 Query Images [RAD -14] R RAD TF -2: Image Display Retrieve Images [RAD -16] R RAD TF -2: 4.16 RAD TF 4.44 -3: Query Evidence Documents [RAD-44] R -3: 4.45 RAD TF R - Retrieve Evidence Documents [RAD 45] Print Request with Presentation LUT -2 : 4.23 Print Composer RAD TF R [RAD -23] Print Server Print Request with Presentation LUT R RAD TF -2 : 4.23 -23] [RAD 4450 Profile Options Mammography Image Integration 19.2 Options that may be selected for this integration profile 1 along with are listed in the Table 19.2- the Actors to which they apply . Dependencies between options when applicable are specified in notes. Table 19.2- 1: Evidence Documents - Actors and Options Actor TF Reference Options RAD TF -2: 4.8.4.1.2.3.1 Acquisition Modality Partial View Image Archive/Manager No options defined -- Image Display -2: 4.16.4.2.2.1.1.7 RAD TF Partial View 4455 ____________________________________________________________________________ 210 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

211 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Flow Mammography Image Profile Process 19.3 Eviden ce Acqui sition play e Dis Imag Imag e Mana ger/ Cr eator Mod ality ve e Archi Imag stem) ( D Sy CA s ality Image Mod rform Pe Mammo - Stored [8] sition Acqui Images e Storag tme nt [10] mi Com Eviden ce Document Pe rform Stored [43] - CA D CAD Mammo e Storag tme mi nt [10] Com ges [14] Query Ima ges [16] Mammo Imag es - Retr ieve Ima o Pre sent Mamm Images to User dence Doc umen t [44] Query Evi dence Doc - etr ieve Evi umen t [45] R CAD Mammo sent Mamm o Pre Images with CAD User to 1: Basic Process Flow in Mammography Image Profile Figure 19.3- The workflow between the Acquisition Modality and the Evidence Creator that is the CAD 4460 device is currently outside the scope of IHE to define. ____________________________________________________________________________ 211 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

212 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Fusion (FUS) 20 This section intentionally, temporarily left blank. ____________________________________________________________________________ 212 7.0 8-07-27 Copyright © 2018 : IHE International, Inc. Rev. 1 – Final Text 201

213 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 21 Import Reconciliation Workflow (IRWF) 4465 IMPORTANT NOTE: As of June 2012, IHE introduces an updated Import Reconciliation . In addition to the original use cases , several new Profile (IRWF.b) for Trial Implementation 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 . . When that supplement becomes Final Text, the cont ents of this section will 4470 by the IRWF.b be removed . In the interim, new implementations should be based on IRWF.b, found at http://www.ihe.net/Technical_Frameworks/#radiology . The Import Reconciliat ion Workflow Integration Profile (IRWF) specifies both the data and workflow requirements for importing existing Evidence Objects and importing Hardcopy from an external Enterprise. Worklists and Patient Demographics Query are provided as mechanisms 4475 to provide local patient and procedure information to be used in the process of reconciling the imported patient/procedure information. Procedure Step Completed messages enable subsequent workflow steps to occur based on the importation of the Evidence Objects. e.g., Patient Name, Patient ID) and order/procedure Reconciling critical patient demographics ( 4480 Accession Number) is an important part of the importation process since the Information ( e.g., local Enterprise will typically have different identifiers (for patient, orders, etc.) from the Enterprise that created the Evidence Objects or Hardcopy being imported . When the attribute values must be changed, this Profile provides a mechanism to preserve a copy of the original values inside the imported DICOM Composite Objects. 4485 This 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 to -processing and reporting. subsequent workflow steps, such as post Actors/Transactions 21.1 Figure 21.1- tween them. 1 diagrams the actors involved with this profile and the transactions be ____________________________________________________________________________ 213 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

214 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient DSS/Order Filler Demographics Supplier Import PS i ↑ n Progress [RAD - 59 ] ↑ Import PS Completed [RAD - 60 ] → Import PS in Progress [RAD ] 59 - Import PS Completed [RAD ] 60 - → Performed Procedure Image Image Step Manager Archive Manager ↑ ↑ Imported Objects Storage Stored [RAD ] - 10] 61 - Commitment [RAD Import PS in Progress [RAD - 59 ] ← - 60 ] Import PS Completed [RAD ← Importer Patient Demographics Query [ITI - 21] → 5] - Query Modality Worklist [RAD ← 4490 1: Import Reconciliation Workflow Diagram Figure 21.1- 1 lists the transactions for each actor directly involved in the Import Reconciliation Table 21.1- 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” are 4495 optional . A complete list of options defined by this integration profile that implementations may ection 21.2. choose to support is listed in S ____________________________________________________________________________ 214 – Final Text 201 Rev. 1 : IHE International, Inc. Copyright © 2018 8-07-27 7.0

215 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1: Import Reconciliation Workflow Integration Profile - Actors and Table 21.1- Transactions 4500 TF Tran sactions Optionality Actors Reference Department System 4.5 -2: Query Modality Worklist [RAD R RAD TF -5] Scheduler/ -3: RAD TF R -59] Import Procedure Step In Progress [RAD Order Filler 4.59 Import Procedure Step Completed [RAD -60] R RAD TF -3: 4.60 -2 a: 3.21 ITI TF Patient Demographics R Patient Demographics Query [ITI -21] Supplier 4.5 -2: Importer Query Modality Worklist [RAD -5] (Note 1) O RAD TF -2 a: 3.21 Patient Demographics Query [ITI -21] (Note 1) O ITI TF -3: R Import Procedure Step In Progress [RAD -59] RAD TF 4.59 RAD TF R -60] Import Procedure Step Completed [RAD -3: 4.60 -61] R RAD TF -3: Imported Objects Stored [RAD 4.61 Storage Commitment [RAD -10] R RAD TF -2: 4.10 Image Manager/ -3: Import Procedure Step In Progress [RAD -59] R RAD TF Image Archive 4.59 -3: Import Procedure Step Completed [RAD -60] R RAD TF 4.60 -61] RAD TF R Imported Objects Stored [RAD -3: 4.61 Storage Commitment [RAD -10] R RAD TF -2: 4.10 -59] -3: RAD TF R Performed Procedure [RAD Import Procedure Step In Progress Step Manager 4.59 -3: RAD TF R Import Procedure Step Completed [RAD -60] 4.60 Note 1: The Importer shall support at least one of the Query Modality Worklist or Patient Demographics Query transactions. -requisites for this profile Refer to Table 2- 1 for other profiles that may be pre Import Reconciliation Workflow Integration Profile Options 21.2 1 along with 4505 21.2- Options that may be selected for this integration profile are listed in the Table . Dependencies between options, when applicable, are specified in the Actors to which they apply notes. 4510 ____________________________________________________________________________ 215 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

216 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Actors and Options 1: Import Reconciliation Workflow - Table 21.2- Option Actor TF Reference No options defined - Department System Scheduler/ Filler Order -1: 21.2.1 Scheduled Import ( Note 1) RAD TF Importer Unscheduled Import ( Note 1) RAD TF -1: 21.2.2 -3: 4.60 Billing and Material Management RAD TF - No options defined Image Manager/ Image Archive No options defined Performed Procedure Step Manager - ptions. Note 1: The Importer shall support at least one of the Scheduled Import or Unscheduled Import O 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 4515 Conformance Statement. 21.2.1 Scheduled Import Option Importers claiming the Scheduled Import Option are required to support the Query Modality -2: 4.5) to obtain import worklists and use the patient and see RAD TF Worklist transaction ( procedure information provided to reconcile the imported data. 4520 -3: 4.59.4.1.2.3.1. For further details of this option, refer to RAD TF Unscheduled Import Option 21.2.2 Importers claiming the Unscheduled Import Option are required to support the Patient Demographics Query transaction (See ITI TF -2a : 3.21) to obtain patient demographics for reconciling the imported data. 4525 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 to be consistent with those that would be obtained using SWF transactions. This is necessary to ensure the synchronization of the Patient Demographics from both sources. 4530 21.3 Integration Workflow Process Flo w This section describes the workflow related to importing DICOM data or importing hardcopy Import Reconciliation Workflow uses many transactions from created external to the Enterprise. . In most cases there are no chan Scheduled Workflow (See Section 3.3) . ges in these transactions See Appendix C for an overview of the information exchange between the Department System 4535 Scheduler/Order Filler and Image Manager. Once the desired information has been imported into the local Enterprise it is up to the local titution to determine the retention policies for physical media associated with the import ( ins e.g., films, CDs, DVDs) and the imported data itself. ____________________________________________________________________________ 216 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

217 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 21.3.1 Import Process Flow This section describes the typical process flow for managed importation. This profile onl y 4540 applies to data from patients that have been registered and assumes that the patient demographics . If the Patient is not registered, information is known and available to the local system and user the data is imported and needs to be reconciled by other mechanisms such as PIR. Use Cases 21.3.1.1 The primary use cases for importing radiology information are: 4545 External Acquisition or Read: An institution has referred the patient to an external facility 1. quired study on media from for acquisition, or for reading . The institution receives the ac the external facility and imports it to the local archive. External Priors: The institution receives media containing prior images and/or reports for 2. 4550 h the . The data is imported to the local archive and associated wit a current patient patient’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 i mported to the local archive and 4555 associated 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 lo cal procedure information. 2. Unscheduled Import: The institution does not electronically schedule the import task and 4560 instead relies on the Importer to obtain local demographics from a Demographics Supplier. nt has been registered so that locally correct In either case it is a prerequisite that the patie demographic information for the patients is available . Importation of “locally unknown” patients followed by Patient Information Reconciliation is not covered by this integration profile . 4565 Im portation 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 . This profile does not dictate a (films, prints), media (CDs, DVDs) or simple network trans fer particular transport mechanism. For any import, there may exist information in addition to the media, which will be taken into 4570 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: • Administrative information like checklists, importation rules, workflow codes or billing items. ____________________________________________________________________________ 217 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

218 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Clinical information like lab reports, discharge summaries, ECGs, potentially as PDI web 4575 • data. Note that the person importing the Evidence Objects or Hardcopy can be assumed to have the most comprehensive and complete information available for the importing task. In case of exceptions, the import may need to be aborted ( -3: 4.60.4.1.2.2 for Exception see RAD TF Management). 4580 After the importation is done and the imported evidence objects are available through the Image Manager/ Image Archive (which may be indicated by an Instance Availability Notification), the enterprise m ay schedule subsequent steps like reading or reporting. Scheduled Import Process Flow 21.3.1.2 4585 associated with an external acquisition or read. An enterprise internally schedules an import, e.g., 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 external Enterprise. 4590 e.g., Clinical information may be received in addition to the DICOM information, • 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- procedure, conjunction with a current etc. ). • The importation scheduling information may include instructions, e.g., which studies, 4595 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 the scheduled procedure step . Note that the Patient Registration and Procedure Ordering all 4600 use the Scheduled Workflow Profile (See Sections 3.3.1, 3.3.2, 3.3.3). • edure step can be scheduled to Depending on the type of media to be imported, the proc e.g., Film Scanner, PDI Workstation). the appropriate Importing device ( • 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 Patient ID) using the Modality Worklist Query . The resultant DICOM objects are stored in the 4605 PACS. • Errors and exceptions during import are handled by using Exception Management described in RAD TF -3: 4.60.4.1.2.2. Subsequent steps may be • 4610 ection 3.3.5); -processing (see S ormed, such as implicit post perf • ____________________________________________________________________________ 218 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

219 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • scheduled for a Post -Processing or Reporting Workflow, probably involving the otification Option. Availability N s) be scheduled This process flow requires that the Patient be registered and that procedure step( . Associated Patient Registration Scheduling, and subsequent Availability or for the importation Notification transactions are part of the Scheduled Workflow (See Section 3.3) . The following 4615 sequence of steps describes the typical process fl ow for the scheduled import of patient data. Importer Image Department System Manager/ Scheduler/ Order Image Filler Archive Query Modality 5] - Worklist [RAD rocedure Step Import P Import P rocedure Step ] In Progress [RAD 59 - In Progress [RAD 59 ] - Perform ed Objects Import Import ] Store d [RAD - 61 Import Procedure Step Procedure Step Import - ] leted [RAD Comp 60 Completed [RAD - 60 ] Storage Commitment - 10] [RAD 1: Scheduled Import Reconciliation Workflow Process Flow Figure 21.3.1- 4620 ____________________________________________________________________________ 219 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

220 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 tre ated differently than prescribed in Scheduled Workflow. The Study UID provided by the Modality Worklist shall be ignored and the reconciliation rules 4625 shall be followed. As part of the import process, the Importer reconciles the patient data as . See RAD TF needed (e.g. -2: , to change the recorded Patient ID to the local Patient ID) 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 the importing enterprise will determine Birth Date, Patient Sex) 4630 e.g., • if demographics from the Import Data can be used ( -specific codes in the imported data are coerced or ignored whether or how enterprise • Unscheduled Import Process Flow 21.3.1.3 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 is no scheduled procedure to trigger the importation. The actual task of importation may be a 4635 batched process that does not schedule individual importations. • 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. 4640 The following steps can be identified in this process flow: • lm scanner is used to digitize a fi e.g., The User does the import at an appropriate device ( films, a workstation with PDI capabilities is used to import PDI media). The UNSCHEDULED IMPORT Option is used to retrieve the Patient Demographics • 4645 .g., to information, import the Evidence Objects and to reconcile the patient data (e change 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 -3: 4.60.1.2.2. described in RAD TF 4650 • The Evidence Objects are available from the PACS and may be used in subsequent scheduled or unscheduled steps, or at a later time. This process flow requires that the Patient be registered. Associated Patient Registration, and bility or Notification transactions are part of the Scheduled Workflow (See subsequent Availa . The following sequence of steps describes the typical process flow for the Section 3.3) unscheduled import of patient data. 4655 ____________________________________________________________________________ 220 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

221 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Department System Demographic Image Scheduler/ Order Supplier Manager/ Importer Filler Image Archive Patient Demographic Query [ITI - 21] rocedure Step Import P rocedure Step Import P 59 - ] In Progress [RAD In Progress [RAD 59 - ] Perform Imported Objects Import Stored [RAD ] 61 - Procedure Step Import Import Procedure Step Completed [RAD - 60 ] 60 Completed [RAD - ] Storage Commitment - [RAD 10] 2: Unscheduled Import Reconciliation Workflow Process Flow Figure 21.3.1- ____________________________________________________________________________ 221 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

222 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 4660 Unscheduled Import Data Reconciliation 21.3.1.3.1 As part of the import process, the Importer reconciles the patient data as needed (e.g., to change l DICOM object identifiers must be the recorded Patient ID to the local Patient ID) . The origina maintained in the imported DICOM Composite Objects in order to maintain the relationship of the Images within the Study (See RAD TF -2: Appendix A.5). The policies of the importing enterprise will determine 4665 whether demogra e.g., Birth Dates, Patient Sex) phics from the Import Data can be used ( • whether or how enterprise • -specific codes in the imported data are coerced or ignored 21.3.2 Import Exception Management Workflow Exception management Workflow is required for Import Reconciliation Workflow. This case addresses the need to manage errors generated through the Import Reconciliation Workflow such 4670 as: Selection of the incorrect Scheduled Procedure Step from the Modality Worklist • rom the Patient Demographics List • Selection of the incorrect Patient Demographics f The inability to support the DICOM Composite Objects to be imported • 4675 Equipment Failure • Bad media • Some of these exception cases are addressed using required functionality for IHE actors in the and Scheduled Workflow Profiles, while others make use of the Import Reconciliation Workflow . The following -3: 4.60.4.1.2.2) IMPORT PPS EXCEPTION MANAGEMENT (See RAD TF numbered items list exception cases that shall be supported by the actors listed in each item. 4680 ____________________________________________________________________________ 222 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

223 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Radiation Exposure Monitoring (REM) Integration Profile 22 This integration profile specifies how details of radiation exposure resulting from imaging procedures are exchanged among the imaging systems, local dose information management tional systems such as dose registries. The data flow in the profile is -institu systems and cross intended to facilitate recording individual procedure dose information, collecting dose data 4685 related to specific patients, and performing population analysis. Use of the relevant DICOM -Ray Dose SR) is clarified and objects (CT Dose SR, Projection X constrained. . A proper radiation The Profile focuses on conveying the details of individual irradiation events 4690 exposure management program at an imaging facility would involve a medical physi cist and define 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 or processing, or in itself constitute a radiation exposure management program. - The Profile addresses dose reporting for imaging procedures performed on CT and projection X 4695 . It does not currently address procedures such as nuclear ray systems, including mammography 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 the procedure ordered/scheduled appropriate for the indications (appropriateness criteria)), or QA of the operational process (were any differences between the procedure scheduled and the 4700 procedure performed justified by the situation/equipment/patient and appropriately approved). Background In the va st majority of medical procedures involving radiation, the potential benefit to the -off should not be overlooked, and patients’ health far outweighs the potential risk, but the trade ade- technological mechanisms can facilitate a conscious evaluation of that tr 4705 off. Estimating radiation dose delivered to patients for medical purposes can facilitate a number of : important activities • 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 how 4710 changes in techniques and protocols impact radiation dose as well as image quality. This tient doses As Low As Reasonably Achievable will enable them to maintain pa (ALARA). • For patients’ physicians, overall data provided from monitoring such exposures can help 4715 them determine (in consultation with the imaging physician) if the benefit from the diagnostic information provide d by an individual examination (or additional examinations) outweigh any small risk that may be associated with the imaging exam. ____________________________________________________________________________ 223 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

224 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -procedure information available for individual For medical physicists, having such post • -specific dose estimates for pregnant patients may help them make essential patient 4720 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 review ing radiation dose related guidelines and regulations . Many such 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 found it prohibitively difficult to collect such data 4725 . • For physicists and physicians, this kind of data can be vital to answering some of the fundamental 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. 4730 However, it is important to understand the technical and practical limitations of such dose monitoring and the reasons why the monitored values may not accurately provide the radiation nt: dose administered to the patie 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 4735 . Therefore, CTDI should not be represented as the dose Plastic is not human tissue received by the patient. • For planar or projection imaging, the recorded values may be exposure, skin dose or some 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 of • 4740 the body into a single cumulative value. Despite such limitations, interest in monitoring radiation dose estimates is clearly expressed in such documents as the European directive Euratom 97/43 and the American College of [1] Radiology Dose Whitepaper . DICOM, with advice from the IEC, AAPM, ACR, NCRP and others, developed DICOM Dose objects appropriate for radiation dose monitoring By profiling automated methods of distribution, dose information can be collected and evaluated 4745 nificant administrative burden on staff otherwise occupied with caring for without imposing a sig patients. 22.1 Actors/ Transactions Figure 22.1- 1 shows the actors directly involved in the Radiation Exposure Monitoring 4750 . Other actors that may be hem Integration Profile and the relevant transactions between t indirectly involved due to their participation in other relevant transactions are not necessarily shown. ____________________________________________________________________________ 224 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

225 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Dose Register 63] Submit Dose Information - [RAD ↑ Dose Info Reporter Query Dose Information ] 64 - [RAD ↓ 65 ormation Retrieve Dose Inf ] - RAD [ ↓ ] Query Dose Information 64 - [RAD ← Dose Info Image Image Retrieve Dose Information ] 65 - RAD [ ← Manager Archive r Consume ↑ [RAD - 62] Store Dose Information ↑ [RAD - 10] Storage Commitment Acquisition Modality - → 62] Store Dose Information [RAD 4755 Monitoring Figure 22.1- 1: Radiation Exposure - 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 Section 22.2. 4760 Table 22.1- 1: Radiation Exposure Monitoring – Actors and Transactions Transactions Optionality TF Reference Actors 4.62 -3: RAD TF R -62] [RAD Store Dose Information Acquisition Modality [RAD -10] R RAD TF -2: 4.10 Storage Commitment [RAD Image 4.62 Store Dose Information -62] -3: R RAD TF Manager/Archive Storage Commitment [RAD -10] R RAD TF -2 : 4.10 4.64 -3: RAD TF R -64] [RAD Query Dose Information ____________________________________________________________________________ 225 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

226 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Transactions Optionality TF Reference Actors [RAD -65] R RAD TF Retrieve Dose Information 4.65 -3: Dose Information Query Dose Information [RAD -64] 4.64 R RAD TF -3: Reporter [RAD Retrieve Dose Information -65] R RAD TF -3: 4.65 -63] R RAD TF -3: 4.63 [RAD Submit Dose Information Store Dose Information [RAD -62] R RAD TF -3: 4.62 Dose Information -3: RAD TF Query Dose Information [RAD -64] R 4.64 Consumer -65] [RAD Retrieve Dose Information 4.65 -3: RAD TF R [RAD -62] R RAD TF -3: 4.62 Store Dose Information -63 Dose Registry Submit Dose Information [RAD R RAD TF -3: 4.63 An Acquisition Modality in this profile might not necessarily generate the irradiation itself . An Acquisition Modality 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 4765 it can do so completely and correctly. Actors are encouraged to describe in their DICOM Conformance St atement additional details of e.g., how they implement specific DICOM -based transactions ( the time frame in which an Acquisition Modality is able to store a Dose object relative to the completion of the irradiation event). 4770 g Integration Profile Options 22.2 Radiation Exposure Monitorin are listed in the Table 22.2- 1 along with Options that may be selected for this integration profile the Actors to which they apply . Dependencies between options when applicable are specified in notes. Curren tly there are no options defined in this profile. 4775 Table 22.2- 1: Radiation Exposure Monitoring – Actors and Options Actor TF Reference Options No options defined - - Acquisition Modality No options defined Image Manager/Archive - - Dose Information Reporter No options defined - - - - No options defined Dose Information Consumer No options defined Dose Registry - - 22.3 Radiation Exposure Monitoring Process Flow This Profile addresses the flow of dose information from the source, through the organization It does not mandate, but is intended to facilitate the ability to do things like: and beyond. 4780 ____________________________________________________________________________ 226 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

227 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • view the estimated dose a patient (or particular organs) received for a certain exam r physician regularly determine if the estimated dose for a given procedure, system o • exceeds some reference level, policy trigger or is otherwise an "outlier" requiring further investigation • 4785 compute the population "dose summary" for a specific exam in a certain hospital or region for a certain pathology or indication compute the population "dose summary" • compare exam -specific "dose summaries" against other sites/regions, against local policy • targets or against standards of practice eporter needs to know such To summarize dose for a specific exam type or pathology, the Dose Information R Note: 4790 . IHE has required that such information be provided in the dose objects as coded details for each dose object If consistent codes are present in the dose objects, they can simply be values so they will be machine readable. -1 Appendix I.1.1 Code Set Management) . Alternatively a Dose or mapped by a lookup table (See RAD TF sorted Information Reporter might be grouped with a DSS/Order Filler so such details could be obtained for each 4795 . In either case, a critical task for s ites wishing to do such analysis is to choose a set of codes for Accession # . exam 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 Image 4800 Manager/Archive. In many organizations, a Dose Information Reporter will collect Dose objects covering a nth), analyze them, compare to site policy and today, this week or last mo e.g., particular period ( generate summary reports . All, or a sampled subset of the Dose objects might be submitted to a National Registry to 4805 . Such Dose objects will generally facilitate composing population statistics and other research -identification process prior to submission. undergo a configurable de ____________________________________________________________________________ 227 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

228 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acquisition Acquisition Acquisition Acquisition Modality 2 Modality 1 Modality 2 Modality 1 Acquisition “Image” Acquisition Dose (CT) (XR) (CT) (XR) Modality 1 Dose Register Modality 2 Information Mgr/Archive Reporter (XR) (CT) Perform Store Dose Information (XR) Study Storage Commitment Store Dose Information (CT) Perform Study Storage Commitment . . . Initiate Weekly Query Dose Information Report Task Retrieve Dose Information Generate Weekly Reports . . . Prepare Monthly Query Dose Information Submission Retrieve Dose Information Select and De identify - Reports Submit Dose Information Perform Population Analysis 1: Radiation Exposure Monitoring Figure 22.3- 4810 – General Case 22.3.2 Real -World Use Cases he following use cases To provide additional context for the General Case process flow, t describe real -world applications of the dose information. Use Case: Department QA (Process Control) Data will generally be continuously collected and evaluated on all procedures. Process control 4815 -ray equipment, operators, l variations attributable to x and data analysis would focus on loca For example: procedures and ordering physicians. 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 4820 -ray procedure is -area product of each x evaluated for each room . No significant variation of the average is found over the last 6 or different performing radiologists over months. Another report compares average dose f ____________________________________________________________________________ 228 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

229 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. It becomes clear that for a certain interventional procedure a newly arrived radiologist tends 4825 to generate 2 to 3 times the dose -area product of his colleagues, whose averages are in a -total in -area product sub narrow cluster well below the newcomer . While the dose fluoroscopy is similar among the radiologists (and is consistent with the average fluoroscopy -area product for the acquisition time of the report), there is a significant discrepancy in dose sub- total. The number of acquired images (higher than the departmental average) also 4830 corroborates this. The medical physicist writes a memo to the d epartment 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, the 4835 radiologists agree that the acquisition, although moderately useful, probably does not bring any 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 that the results show all radiologists now have similar dose -area product for that procedure. Hospitals generally have policies relating to patient radiation dose, often benchmarking . Policies (and reference levels) are performance estimates against published reference levels 4840 often broken down by procedure, patient age group, and perhaps weight group, or gender. Analysis tools can help sites monitor whether policies are being followed, and measure progress . While image quality generally sets the low side limit on dose (too toward improvement targets low and the images are unacceptable to the radiologists), QA programs can be an effective way 4845 to counter dose creep, establish upper trigger levels and encourage lower values . Patient Impact Evaluation Use Case: 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 4850 received by the uterus in the course of the CT exam. ata for the study in question, and The medical physicist retrieves the images and dose d determines 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 weight n the dose and image objects to estimate the total dose to the uterus. of the patient contained i 4855 How the information is recorded and distributed will vary, but in this particular hospital, the dose it in the RIS, estimate is then provided to the clinical coordinator of the department, who enters appending a statement to the report (which had already been signed off), and demoting the status of the study to "pending signature". Before signing off the report, the radiologist completes the 4860 addendum with her estimate of the risk to the fetus given the dose measurement, and communicates this result by phone to the referring physician, who also receives the written . addendum electronically signed by the radiologist a few days later ____________________________________________________________________________ 229 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

230 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: Population Dose and Dose Indicators Organizations wishing to assess Population Dose and Dose Indicators 4865 will often set up a Dose . A sampling of dose estimates with reasonable accuracy are collected from a number of Registry clinical 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 and get each submitting site to follow the same regimen for selecting procedures to submit. 4870 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. ee RAD TF -1: Appendix I – Deployment of Dose Registries. For further discussion, s Dose Reference Levels Use Case: Quantitative Dose Guidelines are often distributed in the form of Dose Reference Levels for 4875 typical procedures for groups of patients of different characteristics ( e.g., a target dose level to stay below for adult head studies). ning Such guidelines are often the logical result of analyzing Population Dose or other data mi performed by a professional society or regulatory body. 4880 Use Case: Site Benchmarking Imaging facilities may find it useful to compare their dose profile by modality, exam type, and pathology to other facilities of the same type, facilities in the same region, and to the nation as a whole. A national radiation dose registry might provide facilities submitting data with reports comparing them to regional and national benchmarks. Population Epidemiology Use Case: 4885 To analyze certain population epidemiology questions, e.g., the occupational hazards of being a radiologist, 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 a complete radiation history of each such patient. Because of long latent periods, data must be archived in a manner that makes it both physically readable and dosimetrically intelligible years, 4890 . or decades, after it is written Use Case: Clinical Trials . For example, a trial of a e can be an important component of a clinical trial The radiation dos proposed low -dose CT lung screening procedure would benefit from being able to collect dose - . Co off analysis data to balance against the resulting detection rates for a proper trade- 4895 submission of image and Dose objects could facilitate this. ____________________________________________________________________________ 230 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

231 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Use Case: -realtime) Procedure Operational Awareness (Quasi be displayed on fluoroscopy systems within sight of Some regulations already require that K a,r . This permits the operator to factor radiation effects into the continuous the primary operator clinical benefit -risk analysis occurring during any procedure (keeping in mind that K 4900 is not the a,r same as cumulative skin dose) . Such direct display can be handled by the modality and has no need of the transactions provided by this profile Use Case: Clinical Management Dose estimates and dose estimate maps can facilitate planning for subsequent procedures (such as deciding how much time to allow for tissue to heal, or deciding what direction to image from 4905 . Particularly for interventional fluoroscopy, the dose distribution to avoid damaged tissues) delivered by each procedure should be part of the patients’ medical record. Longitudinal Patient Dose Record Use Case: ceived by a patient can be stored and retrieved from a longitudinal The lifetime radiation dose re 4910 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 to the -making with respect appropriateness 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 applied to stored dose information. This and quantifying cancer risk, these can be retrospectively 4915 use 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 ep isodes of care and multiple sites. This use case necessarily requires support of acquisition and collation of dose information from multiple acquisition sites, since a patient may be provided healthcare at many sites over their entire life time. 4920 REM Profile Deployments Example 22.3.3 These examples are intended to illustrate a few ways the Radiation Exposure Monitoring Profile might 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 4925 Appendix I. 22.3.3.1 A Hospital Scenario The Radiology PACS would perhaps implement the Image Manager/Archive in this profile and rofiles. also the PIR, SWF P The RIS might implement the Dose Information Reporter in this profile and be grouped with a 4930 rofiles. DSS/Order Filler supporting the SWF and PIR P A Dose Mapping Workstation might implement both the Dose Information Consumer (to obtain Dose objects) and the Evidence Creator (to submit new ones). ____________________________________________________________________________ 231 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

232 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ logy has a separate PACS which also implements an Image Manager/Archive for Perhaps Cardio . The Dose Information Reporter (in the Radiology RIS) could query the cardiology modalities both Archives and manage dose for the hospital in one place. 4935 22.3.3.2 An Imaging Clinic Scenario 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. The Office Management System or a standalone workstation could implement the Dose 4940 Information Reporter, and takes advantage of its ability to receive Dose objects directly from the local modalities. A Longitudinal Patient Record Scenario 22.3.3.3 including hospitals and imaging clinics, implement Acquisition Modalities and/or Multiple sites, 4945 Image Manager/Archives that provide information in response to queries from a local Dose Information Reporter. -identified) dose The local Dose Information Reporter transmits identifiable (as opposed to de information to a remote Dose Register nominated by the patient to act as their lifetime repository of longitudinal dose information. Each local site may use different forms of the patient’s name and different domains for pati 4950 ent identifier, and accordingly the Dose Information Reporter should 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 to resolve identities. See also the issues raised in the Multiple Image mechanism Manager/Archive (MIMA) Trial Implementation supplement. 4955 If the remote Dose Register is grouped with its own Dose Information Reporter Actor , then given y the patient, another local site with a Dose Consumer Actor the appropriate authorization b may access the information to make clinical decisions. Additionally, if remote Dose Register and/or Dose Information Reporter is also capable of nformation, it may want to receive and store modeling effective dose using organ segmentation i the images reconstructed from the irradiation events described in the dose objects, and hence to 4960 . be grouped with a remote Image Manager/Archive Actor 22.4 Radiation Exposure Monitoring Profile Security Consider ations Dose Objects have the same security considerations as images. Security and Privacy policies may require the de -identification of some or all of the PHI details -3: 4.63.4.1.2.1) prior to the submission or use of Dose Objects ( 4965 -identification . De see RAD TF behavior may need to vary by destination due to differences in PHI exposure risk and the need to retain some details, such as approximate patient age or weight, when performing Radiation Dose analysis. ____________________________________________________________________________ 232 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

233 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 22.5 Relation to Other Profiles 4970 Several synergies and interactions of the Radiation Exposure Monitoring Profile with other profiles are specifically called out here. Radiology Profiles 22.5.1 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 4975 the study data to provide a “complete package”, or on their own as a way of conveying Dose objects to a patient, another organization or a dose registry. 22.5.1.2 Patient Identification Reconciliation (PIR) An Image Ma nager/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 a 4980 patients’ study. This is highly desirable. Teaching Files and Clinical Trials Export (TCE) 22.5.1.3 As DICOM objects, the Dose objects can be referenced in a TCE manifest and processed along . This could allow submitting dose details in clinical trials where with other objects from a study such information is relevant, or including dose details in a teaching file, perhaps one specifically addressing protocol dose and the effects on image quality. 4985 ITI Profiles 22.5.2 -referencing (PIX) 22.5.2.1 Patient Identity Cross ient dose records across The PIX Profile could clearly be useful if there is a need to collate pat . It could also be useful if a single Dose Information Reporter is multiple Patient ID Domains 4990 querying multiple Image Manager/Archives in different Patient ID Domains. 22.5.2.2 -Enterprise Document Sharing (XD*) Cross -I, jects are normal DICOM SR objects, the collection of XDS Profiles (XDS, XDS Since Dose ob XDR, XDM, etc.) can be used to distribute or access dose records across multiple sites . Consistent Time (CT) 22.5.2.3 Consistent Time is particularly useful if a gantry and re 4995 ader are trying to compose a Dose object by synchronizing study details based on timestamps. Audit Trail and Node Authentication (ATNA) 22.5.2.4 -3: Table Audit events relevant to the transactions of the REM Profile are identified in RAD TF 2 in the Ra 5.1- diology Audit Trail Option. 5000 ____________________________________________________________________________ 233 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

234 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Mammography Acquisition Workflow (MAWF) 23 This section intentionally, temporarily left blank. 24 MR Diffusion Imaging (DIFF) This section intentionally, temporarily left blank. 25 CT/MR Perfusion Imaging with Contrast (PERF) 5005 on intentionally, temporarily left blank. This secti 26 Basic Image Review (BIR) This section intentionally, temporarily left blank. -Ray CAD Display (CXCAD) Chest X 27 This section intentionally, temporarily left blank. 5010 ____________________________________________________________________________ 234 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

235 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Imaging Object Change Management (IOCM) 28 Object Change Management Integration Profile (IOCM) specifies how one actor The Imaging 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 5015 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 te these changes. requirements. It defines how changes are captured and how to communica -1: IHE Scheduled Workflow Profile defines an PPS Exception Management Option (RAD TF -2: 4.7.4.1.3.1) which specifies how to correct the incorrectly selected worklist 3.3.4 and RAD TF 5020 ogress transaction has been issued but entry after the Modality Performed Procedure Step In Pr before the Modality Performed Procedure Step Completed transaction is issued. This Imaging addresses the use case in which the incorrect modality Object Change Management Profile worklist selection is detected after the Modality Performed Procedure Step Completed transaction is issued. 5025 The required workflow steps for the DSS/OF and the actors grouped with Change Requester are specified in the Scheduled Workflow Profile. Actors/ Transactions 28.1 1 shows the act ors directly involved in the Imaging Object Change Management Figures 28.1- Integration Profile and the relevant transactions between them. Other actors that may be 5030 indirectly involved due to their participation in Scheduled Workflow, Consistent Presentation of Images, etc. are not necessarily shown. ____________________________________________________________________________ 235 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

236 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Change Requester - ↓ Rejection Note Stored [RAD 66] acement Instances Stored [RAD 74 ] - ↓ Repl - Query Images [RAD  14]  16] - Retrieve Images [RAD 30] - Query Key Image Notes [RAD  Retrieve Key Image Notes [RAD  31] - Image Image Image Display Archive Manager 1: Imaging Object Change Management Actor Diagram related to SWF Figure 28.1- 5035 1 lists the transactions for each actor directly involved in the Imaging Object Change Table 28.1- , an implementation Management Profile. In order to claim support of this integration profile d “R”). Transactions labeled “O” are optional. A must perform the required transactions (labele complete list of options defined by this integration profile and that implementations may choose to support is listed in Section 28.2. 5040 Table 28.1- 1: Imaging Object Change Management Integr ation Profile - Actors and Transactions Actors Transactions Optionality TF Reference RAD TF -66] R Change Requester [RAD -3: 4.66 Rejection Note Stored [RAD -74] R Replacement Instances Stored RAD TF -3: 4.74 [RAD Image Manager / 4.66 Rejection Note Stored -66] -3: R RAD TF Archive [RAD -74] R Replacement Instances Stored -3: 4.74 RAD TF Image Display Query Images [RAD -14] R RAD TF -2: 4.14 Retrieve Images [RAD -16] R RAD TF -2: 4.16 [RAD Query Key Image Notes 4.30 -2: RAD TF R -30] ____________________________________________________________________________ 236 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

237 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Reference Optionality Actors Transactions R RAD TF -2: 4.31 Retrieve Key Image Notes [RAD -31] 28.2 Imaging Object Change Management Integration Profile Options are listed in the Table 28.2- 1 along with Options that may be selected for this integration profile the Actors to which they apply. Dependencie s between options when applicable are specified in notes. 5045 - Actors and Options Table 28.2- 1: Imaging Object Change Management TF Reference Actor Options Change Requester No option defined - No option defined - Image Manager / Archive option defined No Image Display - Imaging Object Change Management Integration Profile Actor 28.3 Groupings and Profile Interactions 5050 Imaging Object Change Management builds upon the underlying Actor transactions defined in actors shall be grouped with actors from other Profiles. For this reason, certain IOCM Profile other Profiles as defined in Table 28.3- 1. Table 28.3- - Actors and 1: Imaging Object Change Management Integration Profile Transactions Integration Comments Grouped With Actor Profile Profile Actor Support Acquisition Scheduled Imaging Object Change Requester communication of Modality Workflow Change (see note 1) procedure steps and Management storage commitment Scheduled Creator Evidence when Change Workflow Requester is grouped with Acquisition Modality, Image Manager/Image Archive or Evidence Creator. Image Manager/ Defines how Image Scheduled Workflow Manager/Image Image Archive Archive can obtain scheduled worklist in order to correct the modality worklist selection of the acquired instances. ____________________________________________________________________________ 237 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

238 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Integration Grouped With Comments Actor Profile Actor Profile Image Manager/ Support Image Scheduled Image Manager/ Workflow Manager to Image Image Archive Image Archive Manager change management if Multiple Patient Identity Resolution Option is supported. Scheduled Image Display Image Display SWF defines message Workflow semantics for query - retrieval Change Requester Patient PIR defines the Acquisition n Informatio Modality patient information (see note 1) Reconciliation reconciliation mechanisms that shall Patient Image Manager/ be supported by these Information Image Archive actors. IOCM shall Reconciliation not be used as an Image Manager/ Patient Image Manager/ alternative Information Image Archive Image Archive mechanism for Reconciliation handling patient information reconciliation use cases. 5055 18.4 for additional Note 1: At least one of the optional retrieve transactions is required to be supported. Refer to Section requirements on the Imaging Document Consumer. 28.4 Imaging Object Change Management Process Flow Imaging Object Change Management covers the following use cases: • Data Retention Expiration • 5060 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 foll -imaging objects owing use cases generally apply to all imaging objects as well as non including Grayscale Softcopy Presentation State (GSPS), Key Object Selection Document (KOS), Structured Report (SR), etc. although the examples may focus on the images themselves 5065 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 that has been grouped with the Change Requester (either an Acquisition Modality or an Evidence 5070 Creator). The Procedure Step transactions, Storage Commitment transaction, Query Modality Worklist transaction and the Query/ Retrieve Images transactions in the following diagrams are part of ____________________________________________________________________________ 238 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

239 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Radiology Scheduled Workflow as an example IHE Workflow Profile. They are not part of the Imaging Object Change Management Profile and are only included in the diagrams for illustration. 5075 Technical Framework that are also designed to manage Note: There are existing profiles defined in the Radiology changes in different aspects of imaging objects (e.g., Patient Information Reconciliation, Import Reconciliation Workflow, etc.) Vendors should continue to follow those integration profiles for their re spective use cases. Use Case: Data Retention Expiration 28.4.1 Instances may be deleted to comply with data retention policies. 5080 A local Image Manager / Archive, supporting the Multiple Identity Resolution Option in • to a centralized Image Manager / IHE Scheduled Workflow Profile, stores instances Archive for long term storage (IHE Radiology Supplement ). 70] RAD- MIMA [ • Later, according to the data retention policy of the local Image Manager / Archive, 5085 selected studies are deleted internally. Archive has implemented the Change Requester Actor of the The local Image Manager / • 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 ith a Selection Document Title of “Data Retention Object Selection (KOS) instance w Policy Expired” that lists the deleted instances, and sends this to the centralized Image 5090 transaction, followed by Storage Commitment 66] Manager / Archive using the [RAD- . 71] [RAD- ager / Archive receives the deletion requests and deletes the The centralized Image Man • referenced studies accordingly. 5095 The healthcare provider is responsible for drafting and implementing appropriate data retention policies (see Section 28.4). ____________________________________________________________________________ 239 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

240 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Local Centralized Archive Image Manager / Manager / Archive / / Archive Change Requester - Image Manager Instances Stored [RAD 70 ] Select expired images to be Rejection N ] 66 - ote Stored [RAD deleted Delete rejected 71 Image Manager Storage Commitment [RAD ] - images (for KOS) 5100 Figure 28.4.1 -1: Process Flow for handling expired studies 28.4.2 Use Case: Image Rejection for Quality Reasons Instances may be deleted for quality reasons. The Change Requester may be grouped with an Actor Actor , an Evidence Creator Acquisition Modality nager / Archive Actor , , or an Image Ma 5105 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 for clinical 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 ma rk these images as "rejected" so that other systems correctly handle the rejected images according to local 5110 policies. The procedure step has already been completed, and all images, including the rejected ive. images, have been stored to the Image Manager / Arch 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 / 5115 d then applies internal rules to fulfill Archive gets all images as well as change information, an site policies. ____________________________________________________________________________ 240 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

241 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Manager/ Image Display/ DSS OF / Evidence Creator / Image Archive Change Requester Select 20 ] Creator PS In Progress [RAD - images to Creator PS In Progress [RAD - ] 20 step: reject ( ) s image be rejected ) s ( image step: reject - ] 21 Creator PS Completed [RAD Creator PS Completed [RAD - 21 ] step: reject image s ( ) image s ) ( step: reject Rejection Note Stored [RAD ] 66 - Provide or hide rejected images Storage Commitment [RAD - 10] as configured (for the KOS) 1: Process Flow for handling rejected images Figure 28.4.2- A user marks certain images of insufficient quality as "Rejected for Quality Technical aspect: 5120 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 20] Title of “Rejected for Quality Reasons” and the reason. It creates a Creator PPS [RAD- , sets . It 21] it COMPLETED (including a reference to this KOS) and sends it to the DSS/OF [ RAD- also stores the KOS to the Image Manager / Archive [ 5125 , and then uses the Storage 66] RAD- Commitment [RAD- transaction. 10] The Image Manager / Archive can be configured to provide such rejected images or to hide them from subsequent query/ retrieve responses. An Image Display, when receiving a "Rejected for -16, per Quality Reasons" KOS, will display the images and / or KOS, or will hide both (RAD 5130 . configuration) Instead of an Evidence Creator being the Change Requester, an Image Manager is the Variant: Change Requester. The only difference will be that the Image Manager acting as the Change or an MPPS Requester does not have to create an MPPS referencing the Rejection Note referencing the corrected images. Use Case: Image Correction for Patient Safety Reasons 5135 28.4.3 Instances may be corrected (deleted and replaced) for patient safety reasons. The Change , or an , an Evidence Creator Actor Requester may be grouped with an Acquisition Modality Actor Image Manager/Archive, depending on whether such QA happens on the modality, a separate workstation, or an image manager. 5140 Clinical aspect: The Technologist takes a left breast cranial caudal view (LCC), and didn’t he defaults were set for a right breast (RCC) view, thus the view is labeled realize that t incorrectly. The acquisition has been set completed and images were sent to the PACS. 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, ____________________________________________________________________________ 241 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

242 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5145 laterality) and "update" the images in the PACS. For correct interpretation and diagnosis, the Radiologist 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. This is a patient safety issue; the incorrect image does not provide additional clinical information but d any more. may be harmful, so it is not to be use 5150 The RIS may be notified about such changes, e.g., for logging or informing a user. Image Manager/ Acquisition DSS/ OF Modality / Image Archive Change Requester Acquire images of es Stored [RAD Modality Imag 8] - LCC view MPPS Completed [RAD 7] - MPPS Completed [RAD 7] - MPPS In Progress [RAD - 6 ] Correct ] 6 MPPS In Progress [RAD - step: correct ( LCC to RCC image) step: correct ( image) view/ image ] 66 - Note Stored [RAD Rejection For Processing/ Presentation images) marks incorrect ( cement Instances Stored [RAD - 74 ] Repla RCC image) correct ( 10] - Storage Commitment [RAD ( ) and KOS RCC image correct - 7 ] MPPS Comp leted [RAD MPPS Completed [RAD - 7 ] image) image) ( ( step: correct step: correct tion Detect correc and hide the LCC image Figure 28.4.3- 1: Process Flow for correction of image labeling Technical aspect: The Acquisition Modality, as a Change Requester, cre ates and stores a Key Object Selection (KOS) with a Selection Document Title of “Rejected for Patient Safety 5155 Reasons” that lists the incorrect instances and sends this using Rejection Note Stored [ . RAD- 66] RAD- 6] , It creates corrected images and stores them [ RAD- 74] . It also creates a Modality PS [ sets it COMPLETED (including references to both the corrected images and this KOS), and RAD- sends it to the DSS/OF [ 7] . 5160 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 Document Title of “Rejected for Patient Safety Reasons”, does not display the KOS and its RAD referenced images [ -16] . ____________________________________________________________________________ 242 8-07-27 7.0 Rev. 1 : IHE International, Inc. Copyright © 2018 – Final Text 201

243 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ the Change Requester, an Image Manager is Instead of an Acquisition Modality being Variant: 5165 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. 28.4.4 Use Case: Object Correction due to Modality Worklist Selection Error A patient arrives at the hospital for a scheduled procedure. The Technologist Clinical aspect: 5170 selects a modality worklist entry for the procedure to be performed but mistakenly selects t he wrong entry. The Technologist completes the acquisition step. Image Manager/ DSS/OF Acquisition Modality / Image Archive Change Requester 5] - Query Modality Worklist [RAD Select (wrong) MWL Entry (SPS) Modality Procedure Step Modality Procedure Step In Progress [RAD - 6] 6] In Progress [RAD - isition Perform Acqu Initiated as Modality Images (for wrong MWL entry) Acquisition Stored [RAD 8] - Modality Modality Presentation State - Stored [RAD 9] Modality Procedure Step M odality Procedure Step 7] - Completed [RAD - Completed [RAD 7] Completed (with Completed (with wrong MWL entry) wrong MWL entry) Continue in next diagram 1: Exception Management Workflow (Incorrect Worklist Entry Selected) Figure 28.4.4- Note: Storage Commitment [ -10 ] is not shown in the diagrams above only for simplification of the diagrams. 5175 RAD 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 f ollow: 1. The originally acquired images are relevant to the originally scheduled procedure for the correct patient. 5180 ____________________________________________________________________________ 243 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

244 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2. The originally acquired images are not relevant to the originally scheduled procedure for the correct patient. 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. 5185 The first scenario is 2; the Technologist determines that the acquired illustrated in Figure 28.4.4- images are relevant to the actual scheduled procedure for the correct patient. In this case the Technologist matches the originally acquired images against the originally scheduled procedure for the correct pa tient using Quality Control tools provided by the Modality. 5190 Image Manager/ DSS/OF Acquisition Modality / Image Archive Change Requester Detect that wrong Modality Procedure Step Modality Procedure Step MWL entry has been In Progress [RAD 6] - 6] In Progress [RAD - selected. Begin preparation of (For KOS) (For KOS) Rejection Note. Rejection Notes Stored [RAD 66] - ocedure Step Modality Procedure Step Modality Pr 7] - Completed [RAD Completed [RAD 7] - (For KOS) (For KOS) Select (right) MWL 5] - Query Modality Worklist [RAD Entry (SPS) Initiated as Change Modality Procedure Step Modality Procedure Step Requester Update instances 6] In Progress [RAD 6] - In Progress [RAD - (for right MWL entry) ) ) (For repl. inst. (For repl. inst. Replacement Instances S tored [RAD - 74] (new study) Modality Procedure Step Modality Procedure Step Completed [RAD - 7] - Completed [RAD 7] ) ) (For repl. inst. (For repl. inst. 2: Acquired Images are Relevant to Correct Procedure Figure 28.4.4- ____________________________________________________________________________ 244 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

245 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ RAD Note: Storage Commitment [ -10 ] is not shown in the diagrams above only for simplification of the diagrams. 5195 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 imag es are handled by the Technologist as an unscheduled case. A new procedure is scheduled for the correct patient on the DSS/OF and the originally 2. 5200 acquired images are updated to correspond to the new scheduled procedure obtained from the Modality Worklist. 3 illustrates the correction of the images as an unscheduled case. Figure 28.4.4- The alternative approach of scheduling a new procedure on the DSS/OF is not illustrated here. It rather than would follow the normal Scheduled Workflow sequencing with the exception that acquiring new images, the originally acquired images would be updated to correspond to the new 5205 scheduled procedure obtained from the Modality Worklist. ____________________________________________________________________________ 245 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

246 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Manager/ DSS/OF Acquisition Modality / age Archive Im Change Requester that t wr ong Detec Modality Procedure Step Modality Procedure Step MWL entry has been - 6] 6] In Progress [RAD In Progress [RAD - selected. Begin preparation of (For KOS) (For KOS) Rejection Note. Rejection Notes Stored [RAD - 66] Modality Procedure Step Modality Procedure Step D 7] Completed [RA 7] - Completed [RAD - (For KOS) (For KOS) Created SOP Instances are not relevant to the correct MWL entry Initiated as Change Modality Procedure Step Modality Procedure Step Requester 6] In Progress [RAD - In Progress [RAD - 6] Update instances ) (For repl. inst. ) (For repl. inst. Repl acement Instances Stored [RAD ] 74 - (new study) Modality Procedure Step Modality Procedure Step Completed [RAD - 7] 7] Completed [RAD - ) ) (For repl. inst. (For repl. inst. 3: Acquired Images are Not Relevant to Correct Procedure and are Handled Figure 28.4.4- as an Unscheduled Case 5210 ] is not shown in the diagrams above only for simplification of the diagrams. -10 RAD Note: Storage Commitment [ Technical aspect: The Acquisition Modality creates the originally acquired images with their header s set to the information from the incorrectly selected modality worklist entry. It creates a 5215 RAD -6] , completes and sends it [ RAD- 7] , and stores the images to the corresponding MPPS [ 1). 8] (see Figure 28.4.4- RAD- Image Archive [ ____________________________________________________________________________ 246 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

247 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 2). The Later, the Technologist or the Radiologist detects the mistakes (see Figure 28.4.4- 66] RAD- Acquisition Modality, as a Change Requester, sends a Rejection Note [ KOS which contains references to the rejected SOP instances, the originally acquired images, to the Image Manager. It 5220 -6) referencing this Rejection Note, completes the MPPS also creates a MPPS (RAD RAD- with the reference to the KOS and sends it to the Image Manager / Archive and DSS/OF [ stances 7] . The Image Manager receives the Rejection Note and makes all the referenced SOP in unavailable. The technical aspects then vary depending upon whether or not the originally acquired images 5225 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 le the study is still worklist entry [ RAD- 5] and updates the originally acquired images (whi -acquisition) with the correct information. The available at the Acquisition Modality without re corrected images are assigned new SOP Instance UIDs so that they can be distinguished from the 5230 dy been exported. If the correct modality worklist originally acquired images which have alrea entry is not readily available, the Acquisition Modality queries the DSS/OF again, as illustrated 2. In order to communicate the corrected images to other systems, the in Figure 28.4.4- , as a Change Requester, creates a new MPPS with the correct information Acquisition Modality RAD- 5235 5] . It then stores the new set of corrected images to the Image from the modality worklist [ RAD- 7] . , and completes the MPPS and sends it [ Manager [ RAD- 74] 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 the images as if they belong to an unscheduled procedure, or a ne w 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, 5240 then there is no modality worklist entry to associate the originally acquired images with. The images would thus require manual cor rection on the Acquisition Modality. The corrected images are assigned new SOP Instance UIDs so that they can be distinguished from the originally acquired images which have already been exported. In order to communicate the corrected images to other syste ms, the Acquisition Modality, as a Change Requester, creates a new MPPS. 5245 It then stores the new set of corrected images with manually corrected headers to the Image Manager [ 7] . RAD- 74] , completes the MPPS and sends it [ RAD- 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 5250 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 the Modality Worklist. Note: -1:3.3.4 and RAD TF - IHE Scheduled Workflow Profile defines an PPS Exception Management Option (RAD TF 2:4.7.4.1.3.1) which specifies how to correct the incorrect ly selected worklist entry after the Modality Performed 5255 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 sit uation since the acquired images usually have not been shared prior to MPPS complete or discontinued. ____________________________________________________________________________ 247 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

248 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Instead of an Acquisition Modality being the Change Requester, an Image Manager is Variant: received procedure information the Change Requester. In this case, the Image Manager uses the RAD- 13] 5260 to choose the correct RAD- from Procedure Scheduled [ 4] and Procedure Updated [ modality worklist, updates the images and creates a new set as described above. The Image Manager does not have to create an MPPS referencing the Rejection Note or an MPPS referencing the corrected images. Instead of selecting an incorrect modality worklist entry, the Technologist forgets to Variant: 5265 s complete the previous worklist entry before starting the new acquisition. The acquired image are incorrectly appended to an existing study of a different patient for a different procedure. As a result, the resulting study becomes partially incorrect. Only the incorrect images and/or presentation states are required to be corrected. t Change Management Security Considerations Imaging Objec 28.5 5270 The section describes the policies for reducing risks after correction or rejection at the Change Requester. Images that are marked as "rejected" for quality reasons (see Section 28.4.2) may or may not inically relevant information. They may be useful in certain situations. Sites may contain cl decide to provide them regularly as part of a Study or may hide them at the Archive or at 5275 Workstations. IHE supports such policies by defining configurable behavior at the I mage Manager/ Image Archive for storage and at the Image Display for presentation. Incorrectly labeled images (see Section 28.4.3), e.g., containing a wrong patient orientation or tient. For patient laterality, may mislead image interpretation and thus may be harmful to a pa safety reasons, they are marked in order to not be used later; an Archive hides such images and -defined query and retrieve transactions. does not provide them in IHE 5280 as a specific trigger to the IHE defines a Key Object Selection document with a special title code Image Manager for hiding incorrect instances (different from general Key Image Note use, RAD TF -1: 8). Note that a central correction mechanism at the Image Manager/ Image Archive decreases the 5285 risk for harmful or misleading us e 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 receive and present inconsistent, incomplete or wrong information. 5290 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 . In addition, the Image implements the corresponding Actors from this integration profile Manager/ Archive and Displ ays need to be configured in a way that meets the department or enterprise policies. 5295 ____________________________________________________________________________ 248 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

249 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The correction and rejection mechanisms are capable of deleting or changing evidence of a performed 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 the Referenced Instance Sequence (see RAD TF 5300 -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 5305 rejection of instances referenced in the received KOS if and only if the KOS is sent from the same DICOM Application Entity as the original instances. ____________________________________________________________________________ 249 7.0 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 Rev. 1

250 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -I) -Community Access for Imaging (XCA Cross 29 -Community Access for Imaging (XCA -I) Integration Profile specifies actors and Th e Cross -relevant medical imaging data being held by other transactions to query and retrieve patient communities. 5310 inical information via an Within a community, a group of facilities/enterprises shares cl -I (in which case the community can be referred to as an established mechanism such as XDS XDS Affinity Domain) . This profile addresses sharing between such communities. -I Profile extends the IT Infrastructure XCA Profile The XCA . XCA provides access to 5315 I provides access to the imaging objects . XCA- Diagnostic reports and Imaging Manifests referenced in the Manifests -I is expected to have read and understood the . The reader of XCA ommunity, homeCommunityId, etc. XCA Profile, including the meaning of terms such as C Actors/ Transactions 29.1 -Community Access for Imaging (XCA -I) Figure 29.1- 1 shows the actors defined in the Cross Profile . 5320 and the transactions between them lustrate the full set of The shaded actors are NOT included in this profile but are shown to il actors that play a role other endpoint of transactions that ARE part of the profile (e.g., the ransaction) . As -18] t Document Registry Actor is an endpoint for the Registry Stored Query [ITI a result, the shaded actors are not listed in Table 29.1- 1. 5325 5330 5335 ____________________________________________________________________________ 250 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

251 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5340 ty Initiating Community Responding Commun i Document XDS.b XDS.b Document XDS.b Document XDS.b Document Repository Registry Registry Repository Retrieve  Retrieve  Registry Stored  Registry Stored  Document Set Document Set Query [ITI 18] - Query [ITI -18] - 43] [ITI [ITI -43] 5345 Cross Gateway Query [ITI -38]  Registry Stored XCA XCA XDS.b Query [ITI  -18] Initiating Cross Gateway Responding Document Gateway Retrieve Retrieve [ITI - 39]  Gateway Consumer d Query Registry Store Document Set  -18] [ITI [ITI -43]  Imaging Initiating Responding Document Imaging Imaging Consumer Cross Gateway Retrieve 5350 Gateway Gateway Imaging Document Set Retrieve Imaging Document Set [RAD  ] -75 69] ↓ - [RAD -69] Retrieve Imaging Document Set [RAD  Imaging Document Source 5355 Actor Diagram Community Access for Imaging 1: Cross- Figure 29.1- 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”). ptions defined by this integration Transactions labeled “O” are optional . A complete list of o and that implementations may choose to support is listed in Section 29.2. 5360 profile -Community Access for Imaging Integration Profile 1: Cross Table 29.1- - Actors and Transactions TF Actors Optionality Transactions Reference RAD TF Retrieve Imaging Document Set R Imaging Document Consumer -3: 4.69 [RAD -69] Retrieve Imaging Document Set -3: 4.69 Imaging Document Source R RAD TF -69] [RAD Initiating Imaging Gateway Retrieve Imaging Document Set -3: 4.69 RAD TF R -69] [RAD Cross Gateway Retrieve Imaging R RAD TF -3: 4.75 Document Set [RAD -75] -3: 4.75 RAD TF R Responding Imaging Gateway Cross Gateway Retrieve Imaging -75] Document Set [RAD ____________________________________________________________________________ 251 – Final Text 201 7.0 Rev. 1 Copyright © 2018 8-07-27 : IHE International, Inc.

252 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ TF Transactions Optionality Actors Reference R Retrieve Imaging Document Set -3: 4.69 RAD TF [RAD -69] 29.1.1 Actor Requirements The Responding Imaging Gateway shall support the use of Asynchronous Web Services 5365 Methods (see ITI TF transaction. -2x : Appendix V) for the [ RAD- 75] The Initiating Imaging Gateway is required to support Asynchronous Web Services Exchange for t he [ RAD- 69] t ransaction. -I Profile Options 29.2 XCA Options that may be selected for this integration profile 29.2- 1 along with 5370 are listed in the Table . Dependencies between options when applicable are specified in the Actors to which they apply notes. 1: Cross Table 29.2- Actors and Options -Community Access for Imaging - Options TF Reference Actor RAD TF Imaging Document Consumer Asynchronous Web Services -3: 4.69.4.3 Initiating Imaging Gateway Asynchronous Web Services RAD TF -3: 4.75.4.2 4.69.4.3 -3: RAD TF Responding Imaging Gateway - No options defined Imaging Document Source Asynchronous Web Services RAD TF -3: 4.69.4.3 29.3 -I Process Flow XCA The XCA -I Profile addresses sharing image data sets between communities. 5375 29.3.1 Use Case – Image set sharing between communities Assume a geographically dispersed region, such as Southeast Wisconsin, with several healthcare communities (or XDS Affinity Domains). One community provides image sharing services for . Greater Milwaukee region and one for Kenosha region 5380 -SP) provides: In each community, a Health Information Exchange Service Provider (HIE • 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. ____________________________________________________________________________ 252 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

253 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5385 In each community, Diagnostic Imaging Service Providers provide access to locally • stored images through transactions defined by the XDS -I.b Integration Profile. • Two communities agree to share pa tient 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 5390 Milwaukee region for business. While visiting Milwaukee, patient X is admitted to the versity Hospital (MUH) for urgent care Milwaukee Uni . The attending physician places an imaging procedure order . -I.b Imaging Document Consumer, performs an automated The local PACS, acting as an XDS he Kenosha region through query for relevant priors within the Greater Milwaukee region and to t 5395 -SP’s Initiating Gateway. an XDS.b Stored Query transaction to the local HIE The Initiating Gateway in Greater Milwaukee queries both the local Document Registry and the Responding Gateway for Kenosha n Kenosha and in the South . Relevant priors are located i . The South Milwaukee Diagnostic Imaging Center shares Milwaukee Diagnostic Imaging Center -I.b as part of the Greater Milwaukee region images using XDS . The MUH PACS, acting as an XDS -I.b Imaging Document Consumer, directly acces 5400 ses images from the South Milwaukee Diagnostic Imaging Center via their XDS I.b Imaging Document Source . -I -SP’s XCA Images from the Kenosha region are retrieved through the Greater Milwaukee HIE Initiating Imaging Gateway, retrieving the images from the K -SP’s XCA enosha HIE -I . The Kenosha HIE -SP XCA -I Responding Imaging Gateway, in 5405 Responding Imaging Gateway turn, retrieves the images from Imaging Document Source imaging repositories in the Kenosha region. 29.3.2 Detailed Interactions The following diagram presents a high level view of the interactions between actors when both . Details on each -I.b Affinity Domains initiating and responding communities are XDS 5410 interaction follow the diagram. ____________________________________________________________________________ 253 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

254 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -I Detailed Interactions 1: XCA Figure 29.3.2- initiates Qu ery across Local Community A and Remote Community: Document Consumer a Registry Stored Query request by patient id 5415 – the Document Consumer initiates the initial transaction 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. 5420 – The Initiating processes Registry Stored Query by patient id request Initiating Gateway Gateway receives a Registry Stored Query by patient id and must determine Which Responding Gateways this request should be sent to a) b) What patient id to use in the Cross Gateway Queries . Detailed specification of these steps is . Combination of this profile with other existing not in the intended scope of this profile profiles (e.g., XCPD, PIX/PDQ), future profiles or configuration mechanisms is possible 5425 . ____________________________________________________________________________ 254 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

255 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ for possible use XCA and Patient Identification Management Please refer to ITI TF -2x: E.7 of existing ITI PIX and PDQ Profiles . 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 5430 Document Registry. – The Responding Gateway processes Cross Gateway Query by patient id Responding Gateway processes the Cross Gateway Query by initiating a Registry Stored Query to the local Document the response from the Document Registry to ensure Registry . The Responding Gateway updates that the homeCommunityId is specified on every applicable element. This updated response is 5435 sent as the response to the Cross Gateway Query. Initiating Gateway processes Cross Gateway Query by p atient id responses – The Initiating . For each response it Gateway collects the responses from all Responding Gateways it contacted . Once all responses verifies that the homeCommunityId is present in each appropriate element eway consolidates all updated response data into one response to are received the Initiating Gat the Document Consumer 5440 . The Initiating Gateway returns to the Document Consumer the same homeCommunityId attribute values that it received from Responding Gateway(s). receives Registry Stored Query by patient id response Document Consumer – The Document Consumer receives the results of the query from the Initiating Gateway and must account for three unique aspects of the response; namely that a) the homeCommunityId attribute will be specified , b) the Document Consumer may not be able to map the repositoryUniqueId value 5445 , and c) the Document directly to a Document Repository located in a remote community Consumer may not be able to understand the terminology used in the response . For exampl e, if the initiating and responding community have common Requested Procedure vocabularies , then the Initiating Gateway will respond to the Document Consumer’s request using the common he coding/vocabulary scheme . The Document Consumer retains the values of t 5450 homeCommunityId attribute for future interaction with the Initiating Gateway. Retrieve Image Manifest and Reports from local Community A & Remote Community B: If the Document Consumer issued a – Document Consumer initiates a Retrieve Document Set Regist ry Stored Query, the response to the Registry Stored Query by patient id includes a) the . The 5455 Id b) the repositoryUniqueId, and c) the homeCommunityId attribute document unique Document Consumer shall specify these three parameters in its Retrieve Document Set transaction to the Initiating Gateway. processes Retrieve Document Set Initiating Gateway – The Initiating Gateway determines which Responding Gateway(s) to contact by using the homeCommunityId to obtain the Web way(s) . If the homeCommunityId represents the local 5460 Services endpoint of the Responding Gate community local , the Initiating Gateway will initiate a Retrieve Document Set to the indicated Document Repository . The Retrieve Document Set may contain more than one unique Initiating Gateway may have to initiate requests to more than one homeCommunityId so the . The Initiating Gateway specifies the Responding Gateway, and consolidate the results 5465 homeCommunityId in the Cross Gateway Retrieve transaction. The homeCommunityId identifies the community associated with the Responding Gateway. ____________________________________________________________________________ 255 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

256 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ – The Responding Gateway within an processes Cross Gateway Retrieve Responding Gateway XDS Affinity Domain processes the Cross Gateway Retrieve initiating a Retrieve Document Set transaction to the Document Repository UniqueId within the request . identified by the repository , UniqueIds If the Cross Gateway Retrieve requests multiple documents with different repository 5470 the Responding Gateway will contact multiple Document Repositories and consolidate the responses. Retrie ve Image Set from Remote Community B Imaging Document Consumer . The request initiates a Retrieve Imaging Document Set includes UniqueIds a) the repositoryUniqueId identifying the Imaging Document Source, b) the document 5475 ICOM SOP Instance UIDs) within the Imaging Document identifying the imaging documents (D 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. 5480 The Initiating Initiating Imaging Gateway – processes Retrieve Imaging Document Set Imaging Gateway determines which Responding Imaging Gateways to contact by using the . yId to obtain the Web Services endpoint of the Responding Imaging Gateway homeCommunit 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 5485 . The Initiating Imaging Gateway specifies the g Gateway, and consolidate the results Imagin homeCommunityId in the Cross Gateway Retrieve Imaging Document Set transaction. The homeCommunityId identifies the community associated with the Responding Imaging Gateway . Gateway Responding Imaging processes Cross Gateway Retrieve Imaging Document Set – The Responding Imaging Gateway within an XDS Affinity Domain processes the Cross Gateway 5490 Retrieve Imaging Document Set request by initiating a Retrieve Imaging Document Se t within transaction to the Imaging Document Source identified by the repositoryUniqueId the request . If the Cross Gateway Retrieve Imaging Document Set requests multiple documents with tact multiple Imaging repositoryUniqueIds, the Responding Imaging Gateway will con different Document Sources and consolidate the responses. 5495 Retrieve Image Set from Local Community A Imaging Document Consumer initiates a Retrieve Imaging Document Set – The request UniqueId identifying the Imaging Document Source, b) the includes a) the repository identifying the documents (DICOM SOP Instance UIDs) within the Imaging document UniqueIds Document S ource c) list of one or more DICOM transfer syntax UIDs, d) Study Instance UID, e) 5500 Series Instance UID f) th e 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.b and XDS.b integration profiles for enabling munity uses the XDS I presumes the com 5505 Imaging Document Set behavior . The I defines no required grouping with any actor . XCA- ____________________________________________________________________________ 256 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

257 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ implemente r may consider grouping actors as needed. For example, an Image Document Source may choose t o 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 I Responding Imaging Gateway and XCA Responding Gateway pair. 5510 XCA- e requires that the Initiating and Responding Imaging Gateways that are used in -I Profil The XCA conjunction 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 5515 nalysis for XCA enumerates assets, threats, and mitigations The risk a . The complete risk data is stored and maintained in a central location . The complete risk data is stored and available from 4 IHE . RAD- and [ 69] RAD- The risks associated with the data content and protocols of [ are a subset 75] XCA Profile . 5520 of those identified for the transactions in the ITI 29.4.2 Requirements/Recommendations -I actors The following mitigations shall be implemented by all XCA . These mitigations moderate all high impact risks. M1 : All actors in XCA -I shall be grouped with an ATNA Secure Node or Secure Application 5525 . Actor and a CT Time Client Actor : An Imaging Document Source shall include a SHA1 hash of the image document content in M2 . The Imaging Document Consumer shall have response 68] the Document metadata of the [ RAD- the ability to verify the SHA1 hash of the image document with the SHA1 hash in the metadata. M3 : Imaging Document Consumer implementations shall handle overloading through excessive volume of response data by dis 5530 continuing the read on the socket and closing it . The Initiating and Responding 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, 5535 depending on local policy . This applies to patient identifiers that are properly formatted or . By not using an error code indicating that the ide improperly formatted ntifier is ill formatted, . you are able to reduce the ability of applications to fish for data 4 The risk analysis data may be found at: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr5 -2007- 2008/Technical_Cmte/Pr ofile_Work/XC/XCARiskAnalysis.xls ____________________________________________________________________________ 257 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

258 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The following mitigations address the risk of a document being maliciously changed. This 5540 mitigation is optional. : Documents may be digitally signed using th M5 ) Profile DSG e ITI Digital Signature ( The following mitigations are transferred to the vendors, XDS Affinity Domains, and enterprises. T1 : Backup systems for registry metadata, repository documents, and gateway configuration are 5545 recommended. : All implementations are recommended to ensure that all received data is propagated T2 appropriately (i.e., without corruption and complete results) or an error is presented. : Network protection services are recommended to be sufficient to guard against denial of T3 5550 service attacks on all service interfaces. : A process that reviews audit records and acts on inappropriate actions is recommended. T4 T5 : It is recommended that service interfaces be implemented with a good design to guard against corruption and denial of service attacks Policy Choices 29.4.3 5555 Security and privacy policy choices will not be addressed by this profile . Each community may . The profile has been designed with this fact in mind have different security and privacy policies and an understanding of enough variety of policies so that any reasonable policy can be implemented without violating the profile. 30 Post Acquisition Workflow (PAWF) 5560 This section intentionally, temporarily left blank. 31 Imaging (XDR- -Enterprise Reliable Document Interchange – Cross I) This section intentionally, temporarily left blank. Stereotactic Mammography Image (SMI) 32 5565 This section intentionally, temporarily left blank. Management of Radiology Report Templates (MRRT) 33 This section intentionally, temporarily left blank. flow.b (SWF.b) Scheduled Work 34 This section intentionally, temporarily left blank. ____________________________________________________________________________ 258 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

259 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Invoke Image Display (IID) 5570 35 This section intentionally, temporarily left blank. Temporarily left blank 36 This section intentionally, temporarily left blank. ____________________________________________________________________________ 259 Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1 : IHE International, Inc.

260 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 37 Digital Breast Tomosynthesis (DBT) 5575 The Digital Breast Tomosynthesis (DBT) Profile specifies the creation, exchange and use of DBT images. It defines basic display capabilities that Image Displays are expected to provide, images (FFDM). especially simultaneous review of DBT and conventional 2D mammography The Digital Breast Tomosynthesis Profile is designed to provide faithful storage and retrieval of 5580 DBT images. Furthermore, sufficient display functionality to allow adequate review of current ntional 2D mammography images is defined. and prior studies consisting of DBT and/or conve The support for CAD is out of the scope for this profile. 37.1 DBT Actors, Transactions, and Content Modules This section defines the actors, transactions, and/or content modules in this profile. 5585 1 sho Figure 37.1- ws the actors directly involved in the Digital Breast Tomosynthesis Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes. ____________________________________________________________________________ 260 Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc.

261 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Evidence Creator Image Display ↓ Creator Images Stored RAD 14] - ↓ Query Images [ - 10] ↓ Storage Commitment [R AD 18] - AD [R Retrieve Images [ ↓ - 16] RAD Im age Image Manager Archive - 10] ↑ Storage Commitment [ RAD Modality Images Stored [ ↑ 8] - AD R Acquisition Modality Print Composer Print Request with Presentation LUT ↓ [RAD - 23] Print Server 5590 1: DBT Actor Diagram Figure 37.1- Table 37.1- 1 lists the transactions for each actor directly involved in the Digital Breast Tomosynthesis Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). 1: DBT Profile - Actors and Transactions 5595 Table 37.1- Transactions Referenc Optionality TF Actors e Modality Images Stored [RAD -8] R Acquisition Modality RAD TF -2: 4.8 Storage Commitment [RAD -10] R RAD TF -2: 4.10 Evidence Creator Creator Images Stored [RAD -18] -2: 4.18 R RAD TF -10] R RAD TF -2: 4.10 Storage Commitment [RAD Image Manager/Archive Modality Images Stored [RAD -8] R -2: 4.8 RAD TF -10] R RAD TF -2: 4.10 Storage Commitment [RAD Query Images [RAD -14] R RAD TF -2: 4.14 -2: 4.16 RAD TF Retrieve Images [RAD -16] R -2: 4.18 RAD TF R -18] Creator Images Stored [RAD ____________________________________________________________________________ 261 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

262 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Actors Optionality TF Referenc e Transactions -14] Query Images [RAD -2: 4.14 RAD TF R Image Display -16] R RAD TF -2: 4.16 Retrieve Images [RAD Print Composer 4.23 -2: RAD TF R Print Request with Presentation LUT -23] [RAD 4.23 Print Request with Presentation LUT R RAD TF -2: Print Server -23] [RAD Descriptions and Actor Profile Requirements 37.1.1 Actor Most requirements are documented in Transactions (Volume 2 and 3). This section documents any additional requirements on this profile’s actors. 5600 37.1.1.1 Acquisition Modality The Acquisition Modality Actor acquire -Ray images and generates s breast projection X tomosynthesis images. The Acquisition Modality can optionally acquire conventional 2D mammography images or generate a 2D image mathematically from tomosynthesis data. Creation and storage of in 5605 conventional 2D mammography images is facilitated by grouping the Acquisition Modality the DBT Profile with an Acquisition Modality from the Mammography Image Profile (see Section 19). In order to generate and store additional derived tomosynthesis reconstructions (e.g., slabs), the reator Actor. Acquisition Modality can be grouped with an Evidence C 5610 37.1.1.2 Image Manager/Archive The Image Manager/Archive Actor receives breast tomosynthesis images, conventional 2D mammography images, 2D images generated mathematically from tomosynthesis data from the reator Actor, responds to query requests, and stores Acquisition Modality or an Evidence C requested image data to an Image Display. 5615 37.1.1.3 Image Display The Image Display Actor retrieves breast tomosynthesis images as well as 2D images generated mathematically from tomosynthesis data and/or conventional 2D mammography images from the current and prior exams and displays them. The Image Display can be grouped with an Evidence Creator Actor in order generate derived tomosynthesis reconstructions (e.g., slabs). 5620 37.1.1.4 Evidence Creator e Creator Actors generate derived tomosynthesis reconstructions (e.g., slabs). The Evidenc Evidence Creator can be grouped with the Acquisition Modality or the Image Display in order to -alone system, the workfl access the images. If the Evidence Creator is a stand ow to get access to ____________________________________________________________________________ 262 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

263 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ the images is out of scope for this profile. The Evidence Creator uses the Creator Images Stored -2: 4.18.4.1.2.5). 5625 [RAD- 18] transaction to store these reconstructions (see RAD TF 37.1.1.5 Print Composer Print Composer Actors as semble film sheets of the selected key images and send print requests to a Print Server. A Print Composer can be grouped with an Image Display in order to get access alone system, the workflow to get acce to the key images. If the Print Composer is a stand- ss to 5630 the key images is out of scope for this profile. 37.1.1.6 Print Server The Print Server Actor processes the print requests from a Print Composer Actor. 37.2 DBT Actor Options Actors and Options Table 37.2- 1: DBT - Option Name TF Reference Actor Partial View Acquisition Modality RAD TF -1: 37.2.2 Media Creation RAD TF -1: 37.2.6 -- Evidence Creator No options defined RAD TF Key Images Image Manager/Archive 37.2.1 -1: RAD TF -1: 37.2.5 User Annotation Image Display Key Images RAD TF -1: 37.2.1 37.2.2 Partial View RAD TF -1: RAD TF 37.2.5 -1: User Annotation Media Creation RAD TF -1: 37.2.6 No options defined Print Composer -- No options defined Print Server -- 5635 37.2.1 Key Images Option or frames of a breast tomosynthesis The Key Images Option enables users to mark key images image by attaching a Key Image Note and provide them for display. The functionality is defined -1:8); therefore this functionality is achieved by in the Key Image Note Profile (RAD TF 5640 he Key Image Note Profile: grouping with relevant actors from t Image Displays that support creation of Key Image Notes shall be grouped with an • Evidence Creator in the Key Image Note Profile and shall be able to create and store Key 1. -2: Table 4.16.4.1.3.7- Image Notes for one or more of the SOP classes in RAD TF ____________________________________________________________________________ 263 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

264 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Image Displays that support rendering of Key Image Notes shall be grouped with an • Image Display Actor in the Key Image Note Profile and shall be able to query, retrieve 5645 RAD TF -2: Table and render Key Image Notes for one or more of the SOP classes in 1. 4.16.4.1.3.7- Image Manager/Archives that support storage and retrieval of Key Image Notes shall be • grouped with an Image Manager/Archive Actor in the Key Image Note Profile to enable 5650 t. storage/retrieval of the Key Object Selection Documen 37.2.2 Partial View Option The Partial View Option addresses the creation and display of mosaic images. It defines additional attributes which the Acquisition Modality includes in the image headers in order to indicate whether an image is part of a mos aic and which part of the set the image 5655 represents as defined in RAD TF -2: 4.8.4.1.2.7.1 Partial View Option. . Furthermore, it defines how Image Display Actors make use of this information to annotate the 16.4.2.2.1.3.7 Partial View Option. -2: 4. images in the viewport as defined in RAD TF -Ray Images Option 37.2.3 For Presentation Breast Projection X This option remains in Trial Implementation. Please refer to the DBT Extensions Trial Implementation Supplement for details. 5660 37.2.4 For Processing Breast Projection X -Ray Images Option This option remains in Trial Implementation. Please refer to the DBT Trial Implementation Supplement for details. 37.2.5 User Annotation Option 5665 The User Annotation Option allows users to perform annotation on key images or frames of a breast tomosynthesis image, store it as a Grayscale Softcopy Presentation State, and provide it for display. The functionality is defined in the Consistent Presentation of Images Profile (RAD -1:5); therefore this functionality is achieved by TF grouping with relevant actors from the Consistent Presentation of Images Profile: 5670 Image Displays that support creation of Grayscale Softcopy Presentation State objects • shall be grouped with an Evidence Creator in the Consistent Presentation of Images Profile and shall be able to create and store GSPS objects for one or more of the SOP -2: Table 4.16.4.1.3.7- 1. Classes in RAD TF Image Displays that support rendering of Grayscale Softcopy Presentation State objects • in the Consistent Presentation of Images 5675 shall be grouped with an Image Display Actor Profile and shall be able to query, retrieve and render GSPS objects for one or more of the SOP Classes in RAD TF -1. -2: Table 4.16.4.1.3.7 Image Manager/Archives that support storage and retrieval of Grayscale Soft • copy Presentation State objects shall be grouped with an Image Manager/Archive Actor in the ____________________________________________________________________________ 264 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

265 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5680 Consistent Presentation of Images Profile to enable storage/retrieval of the Grayscale Softcopy Presentation State objects. 37.2.6 Media Creation Option The Media Creation Option allows users to export breast tomosynthesis studies to external see Section 15); media. The functionality is defined in the Portable Data for Imaging Profile ( 5685 therefore this functionality is achieved by grouping with relevant actors from the Portable Data for Imaging Profile: Acquisition Modalities or Image Displays that support creation of external media shall be • grouped with a Portable Media Creator Actor in the Portable Data for Imaging Profile. The Portable Media Creator shall be capable of encoding on the media all of the SOP • 5690 Classes that are required to be supported by the Digital Breast Tomosynthesis Profile (which are defined in the Modality Images Stored and Retrieve Images transactions). he Portable Media Creator shall be capable If the Key Images Option is also supported, t • of encoding on the media instances of the Key Object Selection Document Storage SOP Class. • If the User Annotation Option is also supported, the Portable Media Creator shall be 5695 capable of encoding on the media inst ances of the Grayscale Softcopy Presentation State Storage SOP Class. If a viewer is added to the media in addition to the breast tomosynthesis study, the viewer shall fulfill the Image Display requirements defined in RAD TF -2: 4.16.4.2.2.1.3.11. 37.3 DBT 5700 Required Actor Groupings An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the transactions required for the grouped actor (Column 2). profile, and actors from this profile are grouped with actors from a workflow If this is a content or transport profile, the Content Bindings reference column references any specifications for 5705 mapping data from the content module into data elements from the workflow or transport transactions. In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential 5710 s situation. grouped actors. Notes are used to highlight thi Section 37.5 describes some optional groupings that may be of interest for security considerations and Section 37.6 describes some optional groupings in other related profiles. ____________________________________________________________________________ 265 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

266 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Required Actor Groupings 1: DBT - Table 37.3- Actor to be Content Bindings Reference DBT Actor grouped with Reference Image Manager/Archive Image 19.1 -1: -- RAD TF Manager/Archive in the Mammography Image Profile Image Display Image Display in the -- RAD TF -1: 19.1 Mammography Image Profile -- Acquisition Modality RAD TF -1:19.1 Acquisition Modality in the Mammography Note 1) (see Image Profile Note 1: Acquisition Modalities that generate conventional 2D mammography images shall be grouped with an Acquisition 5715 Modality in the Mammography Image Profile. 37.4 DBT Overvie w The Digital Breast Tomosynthesis (DBT) Profile specifies the creation, exchange and use of DBT images. It defines basic display capabilities that Image Displays are expected to provide, y images (FFDM). especially simultaneous review of DBT and conventional 2D mammograph 5720 The Digital Breast Tomosynthesis Profile is designed to provide faithful storage and retrieval of DBT images. Furthermore, sufficient display functionality to allow adequate review of current and prior studies consisting of DBT and/or conventional 2D mammography images is defined. The support for CAD is out of the scope for this profile. 37.4.1 Concepts The Mammography Image Profile provides functionality for faithful storage, retrieval and 5725 display of conventional 2D mammography images and associated CAD results. The DBT Profile extends this functionality to support breast tomosynthesis images and images derived from them. 37.4.2 Use Cases 37.4.2.1 Use Case #1: DBT Screening 5730 This use case addresses the basic mammography screening workfl ow, which includes creation, storage and retrieval of breast tomosynthesis images and optionally conventional 2D mammography images. 37.4.2.1.1 DBT Screening Use Case Description This use case encompasses a group of scenarios which vary in the number and type of images 5735 that are created at the modality and whether a current study only or a current and a prior are reviewed. Each study, current or prior can include one or multiple views of each breast, where one view may contain a set of: Tomosynthesis slices • ____________________________________________________________________________ 266 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

267 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • Tomosynthesis slabs • 5740 Conventional 2D mammography images • Generated 2D images derived from tomosynthesis data During the review of a study the radiologist can utilize the available display options, such as contrast adjustments, image sizing changes, etc. The goal for this use case is to support fast reading of the data, which includes: 5745 Instantaneous scrolling through slices • • Instantaneous switching between images (different views, different image types, prior images) . Instantaneous switching to the next case • 37.4.2.1.2 DBT Screening Process Flow 5750 Acquisition Image Manager/ Image Display Modality Archive Create images Modality Images -8] Stored [RAD Storage Commitment [RAD 10] - Query Images [RAD 14] - Retrieve Images [RAD -16] Display images ____________________________________________________________________________ 267 Rev. 1 : IHE International, Inc. 7.0 – Final Text 201 8-07-27 Copyright © 2018

268 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1: Process Flow in DBT Screening Use Case Figure 37.4.2.1.2- 37.4.2.2 Use Case #2: Additional reconstructions During review of a study, the radiologist requests another DBT image (reconstruction). This may volume of the acquired DBT data. result in a complete volume or a sub- 5755 37.4.2.2.1 Additional Reconstructions Use Case Description While reviewing the study, the radiologist identifies the need for additional DBT images using different reconstruction parameters. This can be triggered by the lesion type, by the character of the breast tissue (e.g., fatty or dense), any other clinical information (medication, hormone e. Using the functionality of their status), or just by the image impression of the first DBT imag 5760 workstation the radiologist creates the additional DBT image(s) (e.g., using a different slice thickness for reconstruction) either covering the complete volume or a sub- volume. The CS. additional images are stored in the PA 37.4.2.2.2 Additional Reconstructions Process Flow Image Manager/ Image Display/ Evidence Creator Archive Query Images 14] [RAD - Retrieve Images [RAD -16] Identify need for additional reconstructions Perform additional reconstruction Creator Images -18] Stored [RAD Storage Commitment [RAD -10] 5765 ____________________________________________________________________________ 268 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

269 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 1: Process Flow in Additional Reconstructions Use Case Figure 37.4.2.2.2- 37.4.2.3 Use Case #3: DBT in Diagnostic Mammography This use case descri bes acquisition and display of additional DBT images for diagnostic purposes based on the findings in the screening exam. 37.4.2.3.1 DBT in Diagnostic Mammography Use Case Description 5770 Based on findings (e.g., suspected mass, asymmetry) in a conventional 2D mammography or DBT screening study or a palpable finding in the patient, a DBT diagnostic study may be ordered. Exaggerated, rolled, 90- degree (LM, ML) and/or spot compression views are acquired using DBT acquisition or combination 2D/DBT acquisition. 5775 The diagnostic study may contain one or more diagnostic views of a single breast or both breasts, each of which may include a set of: • Tomosynthesis slices • Tomosynthesis slabs Conventional 2D mammography images • Generated 2D images derived from tomosynthesi s data • 5780 During the review of a study the radiologist can utilize the available display options, such as contrast adjustments, image sizing changes, etc. ____________________________________________________________________________ 269 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

270 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 37.4.2.3.2 DBT in Diagnostic Mammography Process Flow Image Display Acquisition Image Manager/ Archive Modality Acquire additional diagnostic views Modality Images -8] Stored [RAD Storage Commitment 10] - [RAD Query Images - 14] [RAD Retrieve Images [RAD -16] Display original study, prior study and diagnostic views. Figure 37.4.2.3.2- 1: Process Flow in DBT for Diagnostic Mammography Use Case 5785 37.4.2.4 Use Case #4: Key Images in DBT Screening r further review This use case addresses flagging of key images or frames in the DBT image fo (e.g., by the referring physician or when asking for a second opinion). 37.4.2.4.1 Key Images in DBT Screening Use Case Description Due to the size of the DBT image, it is helpful to flag key frames for subsequent reviews (e.g., 5790 for a second opinion, for a referring physician or even when reviewed as a prior) in order to find relevant frames faster and not miss key frames while scrolling rapidly. While reviewing a screening exam, the radiologist identifies a lesion that she/he would lik e a second opinion on. She/he flags the frame which best represents the finding for a secondary review by a colleague. She/he stores the information about the key frame in the Key Image Note 5795 and sends it to the PACS. ____________________________________________________________________________ 270 7.0 : IHE International, Inc. Rev. 1 Copyright © 2018 – Final Text 201 8-07-27

271 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ and the Key Image Note on the workstation and opens The second reader retrieves the images them. By selecting the Key Image Note, the relevant frame is displayed right away for review. Starting from the flagged images she/he reviews surrounding frames and provides feedback to 5800 gist. the other radiolo 37.4.2.4.2. Key Images in DBT Screening Process Flow Image Manager/ Image Display Image Display/ Archive Evidence Creator Review study and flag key images/frames Key Image Note 29] Stored [RAD - Storage Commitment - [RAD 10] Query Images 14] [RAD - Retrieve Images -16] [RAD Query Key Image 30] Notes [RAD - Retrieve Key Image 31] - Notes [RAD Review Key Images Figure 37.4.2.4.2- 1: Process Flow in Key Images in DBT Screening Use Case ____________________________________________________________________________ 271 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

272 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5805 notation in DBT studies 37.4.2.5 Use Case #5: User an This use case addresses how to store user annotations on DBT images and make them available for review at a later point in time. 37.4.2.5.1 User annotation in DBT studies Use Case Description ogist identifies a lesion that she/he would like a second While reviewing a DBT image, the radiol opinion on. She/he marks the region on the relevant frame for review by a colleague. She/he 5810 stores the user annotation information in a Grayscale Softcopy Presentation State object and he PACS. sends it to t The second reader retrieves the images and the Grayscale Softcopy Presentation State object on the workstation and opens them. By selecting the user annotation, the annotated frame is 5815 displayed right away for review showing the marks of the initial reader also applying any zoom and window/level settings stored in the Grayscale Softcopy Presentation State object. ____________________________________________________________________________ 272 8-07-27 Rev. 1 7.0 : IHE International, Inc. Copyright © 2018 – Final Text 201

273 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 37.4.2.5.2 User annotation in DBT studies Process Flow Image Manager/ Image Display Image Display/ Archive Evidence Creator Review study and perform user annotations Creator Presentation State -19] Stored [RAD Storage Commitment 10] - [RAD Query Images - 14] [RAD Retrieve Images [RAD -16] Query Presentation [RAD s State 15] - Retrieve Presentation - State s [RAD 17] Review annotated images Figure 37.4.2.5.2- 1: Process Flow in User Annotation in DBT studies Use Case 5820 37.4.2.6 Use Case #6: Printing of selected DBT Frames This use case addresses printing of selected frames from a DBT study. inting of selected DBT Frames Use Case Description 37.4.2.6.1 Pr During reviewing a DBT study, the clinician selects particular frames (with or without annotation) and wants to format them for printing. Options for printing are either in True Size or in Same Size. 5825 ____________________________________________________________________________ 273 8-07-27 – Final Text 201 Rev. 1 : IHE International, Inc. Copyright © 2018 7.0

274 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 37.4. 2.6.2 Printing of selected DBT Frames Process Flow Print Server Image Manager/ Image Display / Archive Print Composer Query Images 14] - [RAD Retrieve Images -16] [RAD Review DBT and select images for printing frames Print Request with -23] Presentation LUT [RAD 1: Process Flow in Printing of Selected DBT Frames Use Case Figure 37.4.2.6.2- 37.5 DBT Security Considerations N/A 5830 37.6 DBT Cross Profile Considerations SWF – Scheduled Workflow The main focus of the Digital Breast Tomosynthesis Profile is to define creation and review of digital breast tomosynthes is studies including DBT images and conventional 2D mammography 5835 images. The scheduling workflow is addressed in the Scheduled Workflow Profile. M MAWF - ammography Acquisition Workflow The main focus of the Digital Breast Tomosynthesis Profile is to define creation and review of digital breast tomosynthes is studies including DBT images and conventional 2D mammography ion handling scenarios, e.g., converting a screening images. The workflows addressing except 5840 procedure into a diagnostic procedure, are defined in the Mammography Acquisition Workflow ____________________________________________________________________________ 274 : IHE International, Inc. 8-07-27 Copyright © 2018 7.0 Rev. 1 – Final Text 201

275 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Profile. The workflows defined in that profile are independent of the type of images acquired and y to studies including DBT images as well. therefore appl Basic Image Review BIR - The Basic Image Review Profile clearly states that specialty viewing (like Mammography) is outside the scope of that profile. Therefore review of DBT images in the BIR Profile is confined 5845 to partial (display – only) support. Specific viewer requirements are addressed in Section 37.2.6. Web -based Image Capture (WIC) 38 This section intentionally, temporarily left blank. - 39 Clinical Decision Support – Order Accountable Tracking (CDS O AT ) 5850 on intentionally, temporarily left blank. This secti – Nuclear Medicine (REM Radiation Exposure Monitoring 40 -NM) This section intentionally, temporarily left blank. 41 -WD) (XRR Cross -Enterprise Remove Reading Workflow Definition - 5855 This section intentionally, temporarily left blank. 42 Intentionally Left Blank This section intentionally, temporarily left blank. Standardized Operational Log Events (SOLE) 43 This section intentionally, temporarily left blank. 5860 Management of Acquisition Protocols (MAP) 44 This section intentionally, temporarily left blank. 45 Results Distribution (RD) This section intentionally, temporarily left blank. 46 Intentionally Left Blank 5865 is intentionally left blank. This section -based Imaging Workflow (EBWI) Encounter 47 This section intentionally, temporarily left blank. ____________________________________________________________________________ 275 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

276 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5870 ____________________________________________________________________________ 276 Rev. 1 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc. 7.0

277 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Clarification of Accession Number and Requested Appendix A: 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. 5875 Structure of an Order for Imaging Service A.1 There are multiple information systems involved in the fulfillment of the request directed to the imaging department, such as a Radiology Information System (RIS) and a Picture Archiving and . Communication System (PACS) 5880 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 imagi ng department environment, the procedures (procedure steps) that have Order Filler also identifies the set of procedures and sub- to be performed in the process of fulfilling the order. Each procedure step is performed using a tation). In the process of scheduling the order fulfillment, the single device (modality, works 5885 Order Filler identifies the type of device and either a specific device or group of devices (for example, 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 commonly ated with the . Correspondingly, it will assign a Filler Order Number associ used in DICOM) 5890 order. 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: ther efore IHE recommends that the Accession Number rather contains no value than an unreliable value, in order to give a human user the -2: Appendix A). opportunity to timely correct this missing value (see also the Tables in RAD TF Each Filler Order may contain one or more Requested Procedures. Each Requested Procedure is 5895 identified by a Requested Procedure ID that needs to be unique only within the scope of the Filler Order Number/Accession Number. A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance 5900 of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. d by the imaging service provider on the basis of the Procedure This Procedure Plan is define 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 the on of a report. Each report is one of the results produced to satisfy the order. For example, creati -ray examination of a patient daily at 8 am for the next three days, 5905 in a case of the order for an X tic report; hence each of them will each of the daily examinations will require a separate diagnos be 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 gl obally unique identifier for each Requested Procedure. ____________________________________________________________________________ 277 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

278 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5910 This identifier will be used to identify all generated images and other DICOM objects related to this Requested Procedure. ne Procedure Performance of one instance of a Requested Procedure is specified by exactly o Plan. Each Requested Procedure may contain one or more Scheduled Procedure Steps that are to be performed according to the Protocols specified by a Procedure Plan. Type and number of 5915 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 the -modalit y examination (such as ones common in Requested Procedure may identify multi Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on a single modality. 5920 The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled A.1 depicted in a Figure -1. Names of entities are represented by names in Procedure Step is bolded 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 2 Requested Procedure 3 [Requested Procedure ID] [Requested Procedure ID] [Requested Procedure ID] [Study Instance UID] [Study Instance UID] [Study Instance UID] Scheduled Scheduled Procedure Procedure Step 1 Step 2 Scheduled Procedure Scheduled Procedure [Scheduled [Scheduled Step 1 Step 1 Procedure Procedure [Scheduled Procedure [Scheduled Procedure Step ID] Step ID] Step ID] Step ID] 5925 -1: Hierarchy of Components of an Order A.1 Figure ____________________________________________________________________________ 278 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

279 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Topics for Standards Corrections or Supplements Appendix B: HL7 Topics B.1 5930 Version 2.5 B.1.1 The IHE Radiology Technical Framework is primarily based on the version 2.3.1 of the HL7 see RAD TF standard ( -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, the RAD- uses the SIU^S12 message first defined in HL7 Appointment Notification [ 48] transaction 5935 Version 2.4 in order to take advantage of the additional scheduling information not available in previous versions. Likewise, IHE has had to provide temporary solutions in custom segments where definitions e not existed RAD- which 13] transactions hav 4] and [ . An example is the definition of the [ RAD- include a ZDS Segment as a temporary solution for handling Study Instance UID. A definition 5940 for the Study Instance UID did not exist until HL7 version 2.5 when definitions were added to the OMI (Imaging Order) message. HL7 Conformance B.1.2 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 HL 7- based transactions using such mechanism. Note that HL7 conformance profiles are not related to 5945 Integration P rofile s and will be used only for purpose of better documentation of IHE IHE requirements DICOM Topics B.2 Implementers are expected to keep up with CP's in DICOM as well as in IHE . DICOM CPs may 5950 -status/status.html be found here: http://www.dclunie.com/dicom ____________________________________________________________________________ 279 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

280 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 ange between the Department System Scheduler/Order Filler and the Image Information exch Manager is performed on the intra 5955 -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 5960 The Department System Schedul er/Order Filler is a source of patient information for the Image Manager 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 and corresponding procedures have been scheduled. At this point, the Department System Scheduler/Order Filler will communicate patient information to the Image Manager within 5965 4] Procedure Scheduled. [RAD- ated by the Department System Subsequent updates of patient information are communic RAD- Scheduler/Order Filler to the Image Manager via the [ . transaction Patient Update 12] These changes 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 Image 5970 Manager shall not initiate patient information changes. C.2 Exchange of Visit and Order Information The Department System Scheduler/Order Filler is a source of visit and order information for the mage Manager does not receive information for a particular patient’s visit Image Manager. The I until the first order for a patient originated within such a visit has been submitted to the 5975 department and corresponding procedures have been scheduled. At this point, the Departme nt System Scheduler/Order Filler will communicate visit and order information to the Image Procedure Scheduled Manager within [RAD- 4] Subsequent updates of visit information are communicated by the Department System Patient Update 5980 . These changes will 12] Scheduler/Order Filler to the Image Manager via [RAD- be reflected on the Image Manager and in the images, Grayscale Softcopy P resentation State and Key Image Note objects retrieved from the Image Archive. The Image Manager shall not initiate visit information changes. Technical Framework requires that the order information change will be Because the Radiology ncellation of the order in question and re 5985 performed through ca -order, updates of order information are communicated by the Department System Scheduler/Order Filler to the Image Manager via a sequence of two transactions (conveying order 13] – Procedure Update [RAD- cancel) and Procedure Scheduled [RAD- 4] (conveying new order information). The Image Manager shall not initiate order information changes. ____________________________________________________________________________ 280 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

281 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 5990 Exchange of Procedure Information C.3 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 mage Manager within Procedure Filler will communicate visit and order information to the I [RAD- 4]. 5995 Scheduled -scheduling, change of procedure code, etc.) are Subsequent updates of procedure information (re 13] . [RAD- Procedure Update communicated by the DSS/Order Filler to the Image Manager via Image Manager shall not initiate Requested Procedure information changes. The -2: 4.6.4.1.2.3.4) and Import Reconciliation In the Scheduled Workflow Group Case (RAD TF 6000 1), certain imaging information submitted -2: Table A.5- Workflow Scheduled Import (RAD TF he Image Manager from the Acquisition Modality or the Importer will differ from that to t provided by the Department System Scheduler/Order Filler. This information can include the formed Study Instance UID and the Performed Procedure, Performed Procedure Step and Per Protocol. For these defined cases this imaging information shall not be subject to change by 6005 either the Department System Scheduler/Order Filler or the Image Manager. The behavior for handling the case where the imaging information differs because t he Acquisition Modality does not conform to Scheduled Workflow is not defined. ____________________________________________________________________________ 281 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

282 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ IHE Integration Statements Appendix D: 6010 IHE Integration Statements are documents prepared and published by vendors to describe the intended conformance of their products with the IHE Techni . They identify the cal Framework specific IHE capabilities a given product is designed to support in terms of the key concepts of ). IHE: Actors and Integration Profiles (described in Section 2 Users familiar with these concepts can use Integration Statemen ts as an aid to determine what 6015 level of integration a vendor asserts a product supports with complementary systems and what . Integration Statements are clinical and operational benefits such integration might provide e.g., intended to be used in conjunction with statements of conformance to specific standards ( HL7, DICOM, W3C, etc.). ctors and integration IHE provides a process for vendors to test their implementation of IHE a 6020 interactive testing event called the party s. The IHE testing process, culminating in a multi- profile -a-thon, provides vendors with valuable feedback and provides a baseline indication of Connect the conformance of their implementations . The process is not, however, intended to - In publishing the results of the Connect t compliance. independently evaluate, or ensure, produc a-thon, and facilitating access to vendors’ IHE Integration Statements, IHE and its sponsoring organizations are in no way attesting to the accuracy or validity of any vendor’s IHE Integration 6025 Statemen ts or any other claims by vendors regarding their products . IMPORTANT -- PLEASE NOTE: Vendors have sole responsibility for the accuracy and validity of their IHE Integration Statements . Vendors’ Integration Statements are made available through IHE simply for consideration by parties seeking information about the integration 6030 . IHE and its sponsoring organizations have not evaluated or capabilities of particular products approved any IHE Integration Statement or any related product, and IHE and its sponsoring organizations 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 business interruption and loss of revenue, arising from any use of, or rel iance upon, any IHE Integration Statement. 6035 D.1 Structure and Content of an IHE Integration Statement An IHE Integration Statement for a product shall include: The Vendor Name 1. 2. The Product Name (as used in the commercial context) to which the IHE Integration 6040 Sta tement applies. The Product Version to which the IHE Integration Statement applies. 3. A publication date. 4. The following statement: 5. “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:” 6045 ____________________________________________________________________________ 282 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

283 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ A list of IHE Integration Profiles supported by the product and, for each integration 6. 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 6050 Framework Volume 1. Note: The vendor may also elect to indicate the version number of the Technical Framework r eferenced for each integration . profile 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 6055 actions. trans The statement shall also include references and/or internet links to the following information: The specific internet address (or universal resource locator [URL]) where the vendor’s 1. Integration Statements are posted 2. The specific URL where the ven dor’s standards conformance statements (e.g., HL7, 6060 DICOM, etc.) relevant to the IHE transactions implemented by the product are posted. The URL of the IHE Initiative’s web page for general information on IHE 3. (www.rsna.org/IHE). is not intended to promote or advertise aspects of a product not An IHE Integration Statement directly related to its implementation of IHE capabilities. D.2 6065 Format of an IHE Integration Statement Each Integration Statement shall follow the format shown below . Vendors may add a cover pa ge and any necessary additional information in accordance with their product documentation policies. 6070 6075 6080 ____________________________________________________________________________ 283 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

284 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 12 Oct 2002 Date IHE Integration Statement Version Product Name Vendor IntegrateRAD V2.3 Any Medical Systems Co. This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below: Integration Options Actors Implemented Profiles Implemented Implemented Image Manager/Image Archive None Scheduled Workflow None Image Display Evidence Creator Creator Performed Procedure Step Order Filler PPS Exception Management None Report Creator Simple Image and Numeric Report Internet address for vendor’s IHE information: www.anymedicalsystemsco.com/ihe Standards Conformance Statements for the Implementation Links to www.anymedicalsystemsco.com/hl7 HL7 www.anymedicalsystemsco.com/dicom/integrateRAD.pdf DICOM Links to general information on IHE -europe.net/ In Europe: https://www.ihe -j.org/en/ In Japan: In North America: http://ihe.net https://www.ihe Appendix E: ____________________________________________________________________________ 284 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

285 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Appendix E: Nuclear Medicine Note that the NM Image Profile is undergoing revision, and vendors considering implementation 6085 are advised to include the modifications contained in the trial implementation version “NM Image Profile with Cardiac Option” . For additional information please contact the IHE Radiology Technical Committee at IHE [email protected] -Rad Introduction E.1 This Appendix provides a description of relevant aspects of Nuclear Medicine in the context of 6090 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 of typical NM Images are presented and examples of typical displays of NM Images are provided. . The mapping of workflows to the IHE Model, and This Appendix is informative, not normative other details of NM practice are sufficiently complex and/or misunderstood that this Appendix 6095 . The sensible approaches has been included to clarify such issues and provide examples of some . The mappings to the workflow examples and details here are not intended to be exhaustive model of IHE shown here are valid but do not represent the only valid mappings. NM Workflow Overview E.2 6100 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 6105 • generating images • storing images to the archive • retrieving images for review generating a report • 6110 ... 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 f or NM. ____________________________________________________________________________ 285 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

286 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Injection Steps E.2.1 All nuclear medicine studies depend on the injection of radio- pharmaceutical tracers (although a 6115 . Note that -pharmaceutical injected hours or days earlier) given series may be imaging a radio -pharmaceutical, it may also be given although this document refers to injection of the radio orally or by some other route. pharmaceutical must be ordered from the pharmacy and delivery The required dose of radio- 6120 arranged to coincide with the scheduled patient procedure . Other aspects include upda tes for changed 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 its execution logged and cause time from injection factors in to most protocols and because the drug tracked both be 6125 administration should go into the patient record. As will be discussed in the following section on NM Worklist Guidelines, most of these tasks -to-be-developed profiles relating to Pharmacy and Enterprise would fall in the scope of yet Scheduling but the injection step may fall in the scope of Scheduled Workflow. Time Separated Acquisitions E.2.2 Standard NM clinical practice includes protocols which require the patient to leave the 6130 acquis ition 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 means e imaging system in between parts of the procedure. When the patient that the patient leaves th returns, it is possible that the new acquisitions may be done on a different system based on 6135 availability. Therefore, there can be no assumption that the same acquisition system is involved in all steps of a given procedure. -to- On the other hand, some protocols may involve several acquisition steps done at -once, back back. Reconstruction as a Separate Operation 6140 E.2.3 NM differs from other modalities in the relationship between acquisition and r econstruction 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. For NM studies, the raw projection images 6145 are clinically useful images, and are often exported and viewed using the NM IOD . When these projection images are tomographic ( Image Type = TOMO or GATED TOMO) i.e., tack of they can also be reconstructed into volume images similar to CT or MR images, i.e., a s slices. Although this reconstruction process can be done on the acquisition system as is done in 6150 most modalities, due to the availability of exported tomographic images, it may also be done on ____________________________________________________________________________ 286 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

287 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ rticular vendors reconstruction other workstations depending on site preferences for pa algorithms, processing loads, and other workflow issues. E.2.4 Acquisition Post -Processing In addition to reconstruction, there are a number of other acquisition related processing steps . This incl performed on the acquired images 6155 udes: • 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 th e tracer 6160 Attenuation Correction - • to compensate for photons absorbed within the body to compensate for patient motion during the scan Patient Motion Correction - • Center of Rotation Correction - • to compensate for offsets in the axis of rotation Other possible corrections include deadtime, energy and linearity. 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. 6165 To avoid encouraging potentially incomplete attempts to carry out these corrections away from the modality, the NM IOD intentionally leaves out attributes for attempting to convey all the relevant information. Other steps, although generally performed on the acquisit ion modality, may, like reconstruction, be performed on a separate workstation depending on system capabilities and site preferences. 6170 Clinical Post Processing E.2.5 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. These clinical processing packages too are sometimes available on the acquisition modality but may also be on a separate workstation ike: 6175 . This processing includes things l • Re -orientation of volumes • 2D and/or 3D segmentation (automatic and/or manual) • Calculation of region characteristics Generation of time -plots • 6180 • 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. ____________________________________________________________________________ 287 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

288 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Display and Reviewing E.2.6 Unlike other modalities where the raw acquisition data has little clinical use, for NM images, the 6185 es, and are often reviewed by the reading raw projection images are clinically useful imag radiologist together with processed results. Also, the color presentation of the images is common in Nuclear Medicine and is a clinical necessity for the interpretation of certain images. 6190 E.2.7 Workflow Chaining Due to t he common use of processing workstations and clinical processing before reporting, the work on chained workflows being discussed in the IHE Radiology Technical Committee whitepaper on Departmental Workflow will be of particular interest and relevance to Nuclear Medicine. E.3 6195 NM Worklists The following informative text provides guidance on how NM activities would most logically be mapped to IHE Worklists and the concepts of Scheduled and Performed Procedure Steps. -Processi The Scheduled Workflow Profile and Post ng 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 6200 . There are some situations which can work nd ultimately sites will need to have some flexibility in how equally well with either approach, a 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 that should be considered. After the guide lines are a number of examples of how the guidelines 6205 would be applied to cases taken from typical clinical practice. E.3.1 NM Worklist Guidelines Injections E.3.1.1 pharmaceutical tracer Scheduling, preparing, tracking and delivering the required dose of radio- is the jo b of the pharmacy and it does not make particular sense to include it in the worklists . It would make sense to address this in future 6210 currently managed by the Radiology Profiles Pharmacy and Enterprise Scheduling Profiles which would also handle related is sues, such as changing 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 6215 presence of, or by, the modality operator. As a practical matter, pending development of the above mentioned profiles, it would be useful and 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. ____________________________________________________________________________ 288 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

289 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 6220 Further, the modality could allow the operator to indicate that the injection has been completed . Supporting codes for injections is not a requirement, and generate corresponding MPPS details . Note that the NM Image IOD already has attributes in the NM but would be a useful feature 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 6225 Procedure Step for the acquisition. rformed outside of the acquisition room, some time prior to the data Injections that are pe acquisition, are not particularly appropriate for inclusion in a modality worklist and are out of scope of this discussion. o the technical procedure fee, it -pharmaceuticals are generally built int 6230 While charges for radio pharmaceutical would be appropriate and sometimes useful to include details about the radio- In cases -2: 4.7. dose in the Billing and Material Management Option described in RAD TF cancelled, if an injection was still performed, it where the MPPS indicates the procedure was would be appropriate to include that information in the MPPS. E.3.1.2 Acquisitions 6235 It is suggested that, in general, each acquisition of image data be scheduled as a separate procedure step. at include having the patient leave the acquisition system between Clinical protocols th acquisition steps, must schedule them as separate Scheduled Procedure Steps. However, when several acquisition steps are done at -once, back- 6240 to-back, they can either be scheduled as multiple Scheduled Procedure Steps, or as a single Scheduled Procedure Step with multiple protocol . Scheduling using multiple Scheduled Procedure Steps allows the greatest flexibility in use codes . Of course the acquisitions will of available equipment and the greatest detail in status reporting 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 6245 Procedure is already required in the Scheduled Workflow Profile, but support of multiple . Support for multiple performed protocol codes in the Performed protocol codes is optional Procedure Step is recommended. An issue worth mentioning is that due to studies involving multiple acquisitions, several . While the Study Instance UID is tems may participate in the same study 6250 acquisition modality sys obtained from the Worklist by both modalities and will be correctly included, the rest of the Study level information, such as study date/time, study description, etc., is generally not provided in the Worklist. This means that each modality will generate their own values and include them in the generated images, resulting in Series instances in the same Study which have . It is assumed that the Image different Study level information (except the UID) 6255 Manager/Archive will manage any issues related to this. ____________________________________________________________________________ 289 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

290 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Reconstruction E.3.1.3 It is recommended that the reconstruction of acquired (tomographic) image data be treated as a ssue a Performed separate Performed Procedure Step. That is, the acquisition system should i Procedure Step Complete message when the tomographic acquisition is complete. 6260 Then, whatever system performs the reconstruction of this data, whether it is the original d Procedure Step for the acquisition system, or some other system, should issue a new Performe reconstruction process, related to the same Scheduled Procedure Step. In this way, scheduling of tomographic acquisitions is consistent with other modalities like CT, but allows the 6265 stem. reconstruction to be performed flexibly by any sy -processing, may carried out as explicit workflow by These Reconstruction steps, and other post -Processing Workflow Profile, or may be carried placing them on worklists as outlined in the Post ps should follow acquisition as out as implicit workflow by the operator knowing these ste outlined in the Scheduled Workflow Profile. E.3.1.4 6270 -Processing Acquisition Post -Processing, as described in Section E.2.4, it will almost Due to the nature of Acquisition Post 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 doing these steps with an explicit worklist, the vast majority of sites will do these steps as implicit acquisition post . Further, the workflow 6275 -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. If the processing is performed on the acquisition modality system, which is the most likely, it is 6280 acceptable 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. rformed on a separate workstation the steps should be handled as separate If the processing is pe 6285 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 the steps as additional protocol codes, however it is recommended to handle them as separate 6290 procedures steps. ____________________________________________________________________________ 290 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

291 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ NM Worklist Examples E.3.2 The following are s ome examples of clinical situations and an example of an appropriate way to handle them based on the above guidelines. E.3.2.1 Injection and immediate imaging 6295 Example: Renal scan (Dynamic) The patient is injected under the camera, and imaging is started immediatel y. Use a single SPS which includes protocol codes for the injection and for a single acquisition. Injection and delayed imaging E.3.2.2 Example: Bone scan to assess for malignancy (Static or Whole body) 6300 The patient is injected somewhere (could be in the imaging department or at the patient bedside), and images are obtained several hours later. . The injection details are handled out of Use a single SPS which includes a single acquisition scope. E.3.2.3 Injection with both immediate and delayed imaging 6305 -phase bone scan for infection (Dynamic and Static) Example: 3 . More images are The patient is injected under the camera, and imaging is started immediately obtained several hours later, on the same or a different gamma camera. ocol codes for both the injection and the initial dynamic Use two SPS. The first SPS includes prot and static acquisitions. The second SPS is for the second static acquisition. Images acquired from 6310 the second SPS must be in a different Series from those from the first SPS. Injection and immediate E.3.2.4 imaging, with possible further imaging Example: Renal scan to evaluate for obstruction, with possible second diuretic acquisition (Dynamic) 6315 . The results will The patient is injected under the camera, and imaging is started immediately re imaging is needed . determine whether mo Schedule two SPS as in E .3.2.3. The images from the first SPS can be read, and then a determination can be made as to whether or not the second acquisition is required. If it is not needed, then the second SPS can be cancelled at the modality by issuing an MPPS aborted message. 6320 Injection and very delayed imaging E.3.2.5 : I-131 whole body imaging (Whole body) Example The patient dose is given, and images obtained days later. ____________________________________________________________________________ 291 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

292 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ . An SPS he imaging suite Optionally schedule one SPS for the injection if it is performed in t would be scheduled for the acquisition. 6325 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 oncol ogy department for the purpose . Several days later, imaging is performed for evaluation purposes. of therapy 6330 A single SPS is used for the image acquisition. E.3.2.7 Two isotope examination, with two imaging times Example -99m Sestamibi “stress” images] Tc -201 “rest” images & : Dual isotope [Thallium myocardial perfusion study (Gated Tomo) 6335 . A second isotope (possibly under The first isotope is injected followed by image acquisition 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 first acquisition. The second SPS contains protocol codes for the second injection and acquisition. 6340 Each of these two acquisitions constitutes a separate Series. . Sites will It should be noted that these are simply suggestions of one approach that makes sense of 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 6345 implementations are currently unlikely. Two isotope examination, with single imaging time E.3.2.8 Example 111 labeled White blood cell “infection” images & Tc : Dual isotope [In- -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 6350 isotope is injected 30 minutes before the acquisition step which images both isotopes. 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 was 6355 vis CT was done as only one imaging step. This is sort of like the case where an abdomen and pel a single acquisition, and then read by the same person, but billed as two "studies" ( i.e., the PGP Profile). ____________________________________________________________________________ 292 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

293 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ E.3.2.9 Acquisition and Reconstruction on the Acquisition Modality Example : Cardiac Tomographic acquisition followed by basic corrections, reconstruction and re - 6360 orientation to align the volume with the cardiac Short Axis. 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 cre ated tomographic images. The modality then does corrections and reconstruction of the tomographic data, appends a new 6365 MPPS and reports it complete, without referencing the intermediate image data. ac Short Axis images and the modality oriented into cardi Finally, the reconstructed data is re- -oriented appends a third MPPS to report the reformatting processing, and referencing the re . slices -oriented slices are stored to the Image The initial tomographic images and the final re Manager/Archive. 6370 . MPPS transactions should only include e raises a sometimes overlooked point This exampl references to series/images which will be (or have been) sent to the Image Manager/Archive. The ger/Archive. implication of including the references is that they will be sent to the Image Mana Correspondingly, the Image Manager/Archive will be waiting for all referenced images and may . Thus, referencing images which will continue to consider the study incomplete until they arrive 6375 not be sent can have the effect of derailing the work flow. Re -orientation on an Evidence Creator with Implicit Workflow E.3.2.10 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. 6380 is created which calls for one cardiac tomographic acquisition. The modality A single SPS 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 com plete. The initial tomographic images are stored to the Image Manager/Archive and the reconstructed 6385 slices are stored to the Evidence Creator workstation. The workstation re -orients the reconstructed data into cardiac Short Axis images and sends a new MPP S to the PPS Manager . The SPS and patient references in the created images and MPPS are copied from the information in the received slice images. The Evidence Creator stores the final re- oriented slices to the Image Manager/Archive. E.3.2.11 and Post -orientation -Processing on an Evidence Creator with 6390 Re Explicit Workflow Example: Same as the previous case, but the work is placed on a Post -Processing Worklist and the Evidence Creator also performs post -processing that produces some Result Screens. ____________________________________________________________________________ 293 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

294 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ PS is created on the Post A single S -Processing Worklist with codes for Re -orientation and Clinical Result Processing. 6395 When the task is selected and the inputs are available on the Evidence Creator, the re -orientation is performed followed by Clinical Result Processing . The Evidence Creator sends an MPPS Complete for the two codes . oriented slice images and result screens are stored to the Image Manager/Archive. The re- -Processing Worklist is not discussed here as that is the The timing of placing the SPS on the Post 6400 topic of an IHE Radiology Technical Committee whitepaper on Departmental Workflow and is still under discussion. In the above two cases, data was considered to be pushed from the Acquisition Modality to the it should be noted that the mechanism for this is Evidence Creator . This is a typical practice, but 6405 . The processing system may retrieve the images from the acquisition not specified by IHE modality, the acquisition modality may push them to the processing system, or the Image . d as a common storage and retrieval point Manager/Archive could be use -processing often need to identify specific related Also, applications that perform clinical post series to use as inputs for processing (for example the corresponding stress and rest series for a 6410 . The software should look to the DICOM fields to determine the patient state and cardiac study) . The information in the fields may be utilized automatically by the software or type of Image may be presented to the user for manual selection. NM Data E.4 The NM Image IOD (refer to DICOM PS 3.3 C.8.4) supports several NM Image Types as 6415 indicated by the code contained in Value 3 of the Image Type (0008,0008) attribute. The currently allowed Image Types are: STATIC - Simple projection image containing one or more frames (e.g., individual views of the lungs ). WHOLE BODY - Projection image where each frame spans the length of the body an (e.g., 6420 ). anterior and/or posterior view of the body Projection image containing a series of frames typically showing the same DYNAMIC - anatomy 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 gated interval .g. , a beating view of the heart ). (e 6425 TOMO - Projection image with frames take from various angles as the detector rotates about the . Generally used to reconstruct volume slices. patient Reconstructed image with frames corresponding to cross RECON TOMO - -sectional slices covering a volume . Created by reconstructing TOMO image frames. OMO, except each angle has multiple frames representing the - Similar to T GATED TOMO . Generally used to reconstruct gated volume slices. phases over a gated interval 6430 ____________________________________________________________________________ 294 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

295 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ -sectional Reconstructed image with frames corresponding to cross RECON GATED TOMO - slices covering a volume at each phase of a gated interval , created .g. , a beating heart volume (e by 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 6435 data at several locations, there will be separate detector description for each position. Because of this, 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 these modalities may contain considerably more logical detectors in cases where the acquisition 6440 system is moved or rotated about the patient. Study UIDs and Series UIDs E.4.1 -2: delines for creating Study, Series and SOP UIDs are provided in RAD TF The basic gui 4.8.4.1.1.1. While the decision as to what constitutes a new Series is traditionally left to the modality, it can 6445 single procedure step on a be said that a series contains images that represent the output of a . In practice, the series has frequently single piece of equipment with a single patient positioning -frame IODs such as the CT slices making up a volume. been used to collect a group of single frame IODs such as NM, this In multi- is not necessary, as related frames are generally already grouped together in the multi -frame IOD. Therefore, it is strongly recommended that each 6450 separate acquisition should become a new Series. otentially of hours, should be separate Stress and rest cardiac exams separated by a time delay, p Series since they may be scheduled separately, could be performed on different acquisition systems, and may not be able to position the patient identically. -processing steps must be different Series if they are done on Similarly, reconstruction or post different workstations. For consistency, it is required here that they always be placed in different 6455 Series. It is also recommended that when new results are produced by doing the same processing on the same 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. Processing functions that produce multiple Images from a single processing step (for example, 6460 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 that . In particular the value should would indicate to users the nature of the contents of the object . The Series Description is reasonably well help in differentiating Series in the same Study 6465 supported by PACS systems, while image level fields are less widely supported. ____________________________________________________________________________ 295 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

296 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ NM Image IOD: Multi- Frames and Vectors E.4.2 It is important to understand that although single -frame DICOM images are most common in current use in other modalities, the DICOM Nuclear Medicine Image IOD is a multi- frame . This means typically an Image will contain multiple 2 -D pixel arrays called Frames . 6470 image Refer to DICOM PS3.3 C.8.4.8 for details. The object becomes more complex due to the fact that each frame is indexed according to a . Each number of acquisition “dimensions” such as Energy Window, Detector, Angle and Phase dimension by a “Frame Pointer” vector. frame is indexed in each An example of the Frame Increment Pointer vectors for a Dynamic Image is shown here (taken 6475 from DICOM PS3.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 1 1 1 1 1 1 1 1 1 1 Energy Window # 1 1 1 1 1 2 1 1 1 1 1 1 2 2 2 2 2 2 Detector # 1 Phase # 1 1 1 1 1 2 2 1 1 1 1 2 2 1 2 1 5 2 4 3 2 Time Slice # 1 1 2 3 4 5 and the four vectors would be defined as: 6480 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,2 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 Each vector attribute has a matching “Number Of” attribute indicating how many values are 6485 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 dard specifies the frame increment pointers which For each NM Image Type, the DICOM stan must be present and the order in which the pointer vectors are stored. Typically the last vector . The NM Image Type is stored in Value 3 of 6490 will vary most rapidly, although exceptions exist the Image Type attribute (0008,0008). Typical NM Data Dimensions E.4.3 Typical sizes of NM Image frames and NM Image vectors are provided in the following table. ____________________________________________________________________________ 296 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

297 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Table E.4- 1: NM Image Characteristics 6495 Typi Frame cal Typical Image Type Matrix Increment Pointer # [ i.e., vectors] Size 128 x 128 STATIC Energy Window (0054,0010) 1 - 2 256 x 256 1 - 2* Detector (0054,0020) [Total Frames] 1 - 12* WHOLE BODY 1024 x 1 - 2 Energy Window (0054,0010) 256 Detector (0054,0020) 1 - 2 1024 x [Total Frames] 1 - 4 512 1 - 2 DYNAMIC 64 x 64 Energy Window (0054,0010) 128 x 128 Detector (0054,0020) 1 - 2 1 - 3 Phase (0054,0100) Time Slice (0054,0030) 1 - 120 1 - 1440 [Total Frames] GATED 1 Energy Window (0054,0010) 64 x 64 128 x 128 Detector (0054,0020) 1 Interval (0054,0060) R-R 1 Time Slot (0054,0070) 8 - 32 8 - 32 [Total Frames] 64 x 64 TOMO Energy Window (0054,0010) 1 128 x 128 Detector (0054,0020) 1 Rotation (0054,0050) 1 Angular View (0054,0090) 30 - 128 [Total Frames] 30 - 128 Energy Window (0054,0010) 1 GATED TOMO 64 x 64 128 x 128 1 Detector (0054,0020) 1 Rotation (0054,0050) R-R Interval (0054,0060) 1 Time Slot (0054,0070) 8 - 16 - 128 Angular View (0054,0090) 30 - 2048 240 [Total Frames] 64 x 64 RECON TOMO Slice(0054,0080) - 128 12 128 128 x 64 x 64 GATED RECON R-R Interval (0054,0060) 1 TOMO 128 x 128 8 - 16 Time Slot (0054,0070) Slice (0054,0080) 12 - 24 - 384 96 [Total Frames] * Note that although the number of physical detectors is generally 1 or 2, the object may potentially contain a separate E.4 above. logical detector for each frame in the image as described in the last paragraph of Section ____________________________________________________________________________ 297 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

298 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ E.5 NM Display E.5.1 NM Intensity and Color Mapping 6500 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. . Bone In CT images are characterized by the fact that the pixel values represent Hounsfield units . Soft tissues are represented -known value plus or minus a typical range is represented by a well 6505 . In this space it makes sense to provide by another well -known value plus or minus a range controls for selecting a Window Center and a Window Width. . Due to differences in In NM images, the pixel values typically represent radioactivity “counts” radiopharmaceutical type, dose, time between injection and imaging, length of scan, overlying abolic processes and many other things, the pixel values cannot be considered tissue density, met 6510 . Further, the image is often characterized by very high intensity “hot spots” strictly quantitative evel of where a very high concentration of tracer may have accumulated; and by a low l background activity (“noise”) from non . For such images, it is -specific uptake and scatter appropriate to provide a control that would allow setting a threshold level to cut out the low level background, and another threshold to cut off the high le vel hot spots which might otherwise obscure mid- range intensities. 6515 . These Control of NM display intensities is therefore based on Upper and Lower Window Levels 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 6520 ½ Window Width Window Lower = Window Center - Or conversely, 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 and 6525 lower window values be displayed in the interface. . To display the images, it is generally Some NM datasets may contain very high pixel values necessary to map the NM Image pixel values into the range of grey levels which can be grey levels than there are displayed by the hardware (most displays have much fewer discernible 6530 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 is preferred, 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 to 6535 display multiple color scales (see below) at the same time. ____________________________________________________________________________ 298 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

299 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ rst loaded then the presence of a small If the mapping is done only once when the image is fi 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 6540 each Window Level adjustment, or to provide a way to control the maximum pixel value used . A similar problem (and solution) occurs when switching between examining bone for mapping oft tissue windows in a CT image. and s 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 als o map to Upper and Lower Window values as described above. 6545 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 the values store d in the Window Center (0028,1050) and Window Width (0028,1051) attributes of the image data. 6550 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 maxim um pixel value of the frameset. Typical Nuclear Medicine clinical practice also differs from CT and MR in the prevalence of -scales” to the grayscale data during review -color lookup tables or “color applying pseudo . This is done to enhance particular featu res of the data in certain ways . 6555 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 NM review stations to have dozens of color studies . It is not unusual for -scales available. The ability for users to edit and/or create new pseudo- color lookup tables on the Image Display 6560 is occasionally useful but not required. Far more useful is the ability to install a preferred -scales on the system collection of color . The Society of Nuclear Medicine (SNM) has plans to -scales. act as a repository for a collection of common and popular color o Since exported Result Screens in NM almost always contain image data, many users will want t be 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 6565 lly be acceptable . It may be unavoidable and would genera which have a modality type of NM that this could change the display values for any included graphics and annotations. E.5.2 NM Image Resizing NM Images typically range in size from 64x64 to 512x1024 with the majority of the frames at images must be enlarged on the display to be the smaller end of the spectrum 6570 . Such small . A common clinically useful, adding unnecessary steps to the reading radiologists’ workflow mistake of general purpose display systems is to initially display these 64x64 frames at “full resolution” which resul ts in a screen of “postage stamps”. ____________________________________________________________________________ 299 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

300 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Correspondingly, Whole body Image frames should generally not be scaled down for initial display, unless such scaling is needed to fit the whole body frame onto the screen. 6575 The following table provides some guidelines on appropriate default zoom factors for various . These are intended to simply provide a starting point for systems without frame sizes sophisticated layout algorithms. Table E.5 -1: Frame Zoom Guidelines Default Cine Size Default Display Size Actual Frame Size Cine at 4x 32x32 to 63x63 Display at 4x Cine at 4x Display at 3x if 12 or fewer frames 64x64 to 100x100 Display at 2x if greater than 12 frames Cine at 3x Display at 2x if 12 or fewer frames 101x101 to 200x200 Display at 1x if greater than 12 frames 201x201 to size of display area Cine at 2x (if display area permits) Display at 1x Cine at 1x otherwise Shrink to fit in display area Greater than display area Shrink to fit in display area 6580 are not required to be so, and it would be Note that while NM images are generally square, they appropriate to use just the larger of the x and y dimensions when deciding the zoom factor. Obviously there is interplay between the number of frames to display, frame size, zoom factor, xample, increasing the zoom from 2X to 3X will result in fewer rows . For e and display layout and columns of frames available for display at a given time 6585 . Image Displays are encouraged to . Note that horizontal scrolling is preferable to scrolling make intelligent use of display space both vertically and horizontally. With the above table as a starting point, most users will want to have a way of selecting the . . A simple selection of 2X, 3X or 4X zoom may be sufficient display size for the frames 6590 ormat (such as 2x2, 8x8, 4x1, etc.) is also acceptable, though a Alternatively, selecting a display f much 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 t he 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 -ray, one might magnify a portion of the screen to just see the hip 6595 For example, on a femur bone x portion of the femoral bone, in order to see it at greater resolution. Such magnification is rarely . Such Whole used in nuclear medicine, with the possible exception of the Whole Body images Body images are typically 1024 pixels in height, and may not fit on the screen if a larger zoom is . In such cases, it may be necessary to magnify the contents of the frame instead, and employed ____________________________________________________________________________ 300 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

301 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 6600 allow the user to designate in some manner the portion of the frame he wants to center on as the mag nification is increased. E.5.3 NM Display Examples Example Layouts E.5.3.1 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. 6605 Grid Display A A A A A A A A 3 4 1 5 6 7 2 8 ... ... ... ... ... ... ... A 9 ... ... ... ... ... ... ... ... ... ... ... ... A ... ... ... 32 ... Comparison Display (2 Framesets) 6610 A A A A A A A A 5 6 4 3 7 2 8 1 B B B B B B B B 8 6 4 7 3 2 5 1 or alternatively, A A A A A A A A 5 4 3 6 2 7 1 8 ... ... ... ... A A ... ... 9 16 ____________________________________________________________________________ 301 7.0 : IHE International, Inc. – Final Text 201 8-07-27 Copyright © 2018 Rev. 1

302 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ B B B B B B B B 3 1 4 5 6 2 7 8 ... ... ... ... B ... B ... 9 16 Whole body Display (2 Framesets, 2 Frames each) 6615 A B A B 2 1 2 1 Fit Display (3 images, from 3 series with two frames each) B A B A 1 2 2 1 C C 1 1 6620 a supplied or generated MIP cine display) MPR Display (one transaxial volume, with ____________________________________________________________________________ 302 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

303 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Sagittal Transaxial Coronal MIP (cine) Note that the MIP is not strictly part of the MPR display, but since it is frequently useful, some vendors provide it. 6625 or alternatively, Coronal Coronal Coronal y - 1 y y + 1 Axial Axial Axial z z - 1 z + 1 Sagittal Sagittal Sagittal n + 1 n n - 1 Cine Display (three images from 3 series, each cycling synchronously) B C A 1-32 1-32 1-32 ____________________________________________________________________________ 303 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

304 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 6630 Clinical Examples E.5.3.2 This section provides examples and clarifications on typical patterns of display for NM Images. This section should not be considered as an attempt to address hanging protocols . This is a complex topic which DICOM is working on. Once that work is complete, NM and Radiology in general would benefit from that work being included in the IHE Framework . This section is not intended to supplant that. 6635 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. Example 1: Cardiac Study The user selects a Tomo stress series, several static result screens (secondary captures), another . -frame secondary capture) Tomo rest series, and a dynamic result screen (multi 6640 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. 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 Multi- 6645 Frame Secondary Capture image without a cine module). . It is useful to be able The user would also like to review the dynamic result screen in cine mode 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 6650 . The user would like to see all 8 The user selects 4 Static series containing a total of 8 frames frames in a Fit Display (preferably with the frames resized to 25 6x256) Example 3 -Perfusion Study : Ventilation The user selects the (several) series corresponding to lung perfusion imaging, and the (several) . The user expects to be able to review the series corresponding to a lung ventilation imaging fusion frames together in a Fit Display 6655 . The user may wish to adjust each ventilation and per series’ intensities and the zoom factor. It may be useful to select several series and adjust the intensities together. -intestinal Bleed Study Example 4 : Gastro phase 90 The user selects 2 dy namic images containing anterior and posterior frames from a two- 6660 -intestinal bleeding exam, with a grand total of 300 frames . The user expects to be minute gastro mall) in a able to page through the frames (showing them all at once would make the frames too s . Grid Display The user would also expect to select one or other view, or one of the phases and view the frameset in a Grid Display . ____________________________________________________________________________ 304 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

305 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Finally the user would view a cine (perhaps two cines, one anterior frameset and one posterior 6665 frameset, or a s ingle cine that allows the user to cine one view or the other independently). Example 5: Renal Study The user selects a dynamic study . The user expects to see a Grid Display to page through the frames and to be able to cine the time vector. 6670 When more than one phase is present, it is useful to be able to control the upper and lower levels of the phases separately . A user may wish to select a frame set corresponding to the first phase of a Dynamic Image, which represents the flow portion of the exam, and low er the Upper Window Level to increase the visibility of these “low -count” frames . The second phase frame set, which contains 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: 6675 STATIC: Simple display. Typically several images displayed at once (for example in a Fit . While the default order of frames in the object is sorted by Energy Window then display) Detector, it is generally more useful to present them in Detector/Energy Window order or sorted by acquisition time. Example: 12 view static 6680 the Whole body display). i.e., WHOLE BODY: Side by side display of two rectangular images ( nergy window, in DYNAMIC: Cine through all frames of all phases from one detector and one e order. It is also useful to display in a Grid or Row display. Generally a different window level ) includes plotting time activity applies to each phase. Processing (not required by the NM Profile through user selected areas of the image. GATED: Cine through the frames from one detector/energy window, in time order. Processing 6685 ) can include time activity curves, heart wall edge detection and (not required by the NM Profile . Typically several images displayed at once. motion tracking, etc 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 6690 forward cine. RECON TOMO: Display all slices in spatial order. T ypical display actions can include . Processing (not required by the NM Profile ) can reorientation to other viewing planes (MPR) include oblique reorientation to cardiac relative views, creation of MIP images, etc. Example: Stress -Rest in a Row Layout displ ay, or a single dataset in an MPR Display. 6695 GATED TOMO: Cine all frames (angular views) from one energy window, one (logical) -R interval, and one Time Slot, or all Time Slots from one energy detector, one rotation, one R -R inte window, detector, rotation, R rval, and Angular View. Some users do not review these images unless data acquisition problems are suspected. GATED RECON TOMO: Cine all frames from one R -R Interval and one Time Slot. Typical us special cardiac processing includes all functions done to RECON TOMO images, pl 6700 -eye plot creation. processing such as bull’s ____________________________________________________________________________ 305 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

306 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 the 6705 patient 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. The Nuclear Medicine Accreditation Committee of the ACR has further required that laterality and orientation information also be provided. Security Environment Considerations Appendix F: 6710 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 -1: 9) provides one component of this Trail and Node Authentication (ATNA) Profile (ITI TF solution. 6715 IHE assumes that actors will be installed on nodes with the following characteristics: 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 to an access control procedure in which the user/application will be authenticated. • All required audit trail events are captured and recorded. 6720 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 use of other monitored area. This is normally the case with modality equipment beca 6725 patient safety, privacy, and operational concerns. Similarly, the HIS systems and various archives are normally protected. Equipment like PACS workstations are ff sometimes placed in unprotected areas, but it is usually located where hospital sta . It assumes that the threat of equipment modification is monitors and limit access protected against by means of the physical security mechanisms. 6730 The network equipment that connects the computers is also assumed to be physically • protected against unaut horized connections and unauthorized modifications . In the treatment 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 activit y is taking place. 6735 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. ____________________________________________________________________________ 306 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

307 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ ffices, are not physically protected. Other means Remote locations, especially home o • 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 a 6740 complete replacement for physical securit y but may be part of an overall protection system. • The home computer that is used for both personal and professional purposes is difficult to protect. It will be protected from inadvertent modification by malicious 6745 software or its use will be prohibited. • Network Security Environment 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. 6750 be: The threat profile is assumed to • 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 not expert at the internal structure of the syste ms. 6755 • Random untargeted abuse, such as from an Internet hacker. The threat profile also assumes that the following threats are either not present or otherwise protected. Individual abuse by a system administrator, system developer, or other expert. • • Military or hostile government action Organized criminal attack 6760 • 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, vi rus infection, etc. IHE does not mandate the use of encryption because the performance impact of current encryption algorithms is excessive. Most hospital networks provide adequate security through 6765 ance penalty for encryption is not physical and procedural mechanisms. The additional perform justified for these networks. The profiles permit the use of encryption so that it can be used as part of an overall security plan. ____________________________________________________________________________ 307 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

308 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Patient Information Reconciliation for XDS -I.b 6770 Appendix G: (INFORMATIVE) Patient Information Reconci liation (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 of managing patient information within the XDS Document Registry and synchronizing data between the document sources, repository and registry. 6775 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 profile s 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 considered 6780 imaging information content does not introduce any informative and serves to demonstrate that new or imaging information content specific PIR issues. Context and Assumptions G.1 XDS Affinity Domain Assumptions G.1.1 • 6785 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 to • realize normalized patient IDs. The XDS Affinity Domain must have a Patient Identity Source Actor • e nomenclature for the XDS Affinity To simplify description in this section, th 6790 • Domain will be “XAD”. • A Document Source is responsible for obtaining the XAD patient ID for registering the . The XAD patient ID that is obtained is only used for this document within the registry purpose and is not used to update any patient ID’s within the document . Patient ID’s 6795 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 docum ent 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: 6800 • Query the XAD Patient Identity Source to see if the XAD patient ID exists – not supported at this time ____________________________________________________________________________ 308 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

309 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 6805 The Registry cannot accept a document with an OID that is alread y registered • If a document is submitted that has the OID of a document already registered, the • Registry will reject the submission -submitted and, thereby, is identical to a document already If a document is re • submitted, the Registry will reject the submis 6810 sion Meta G.1.2 Registry data in the Document • The XAD patient ID is the only piece of metadata that can be reliably used to query for a patient • The Registry maintains supporting patient information such as Name, Sex, DoB, etc. but 6815 is NOT obligated to ensure the referential integrity of this data. Therefore: • This information is NOT used for query matching (but is only used for audits and potential verification of Document Consumers) -data There is no requirement for the XDS Document Registry to verify that the meta • in 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 query 6820 matching Patient Identity Management in the XDS Registry G.1.3 • The Registry keeps a list of known XAD patient IDs • The Registry associates documents with the patient IDs 6825 The Registry receives patient “merge” notifications from the XAD Patient Identity • Source • The Registry is responsible for updating XAD patient IDs associated with documents egistry does not update metadata nor document content • The R • If the clinical content of a document has changed, the Document Source is responsible for updating the Document Repository and Document Registry 6830 Expected Implementation Models for Patient Identity Manag ement G.1.4 In a cross enterprise scenario, we assume that there are multiple patient identity domains Local patient identity domains that support one or more enterprises. These pertain to • Document Sources and Document Consumers Affinity Domain patient identity domain • 6835 ____________________________________________________________________________ 309 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

310 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. ross A participating enterprise may deploy a Patient Identifier C -Referencing (PIX) Manager to -map Patient ID in the local domain to Patient ID in XAD domain. In such cases, the Cross cross 6840 Reference Manager will interact with the Affinity Domain Patient Identity Source. Document sources and consumers are required t o obtain a normalized XAD patient ID. The mechanism for achieving this is dependent on the implementation of patient identity feeds and patient identity cross -reference manages within the Affinity Domain. For example, where local domains have Patient Ident ity X -ref managers, the document sources and consumers obtain the -ref 6845 normalized XAD patient ID from the Affinity Domain patient identity source via the X managers. The document sources and consumers can also obtain the XAD patient ID using other methods s uch 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 X 6850 ref manager. with other -I.b Further information on integrating Source and Consumer actors in XDS and XDS ctors for exchanging patient identifying data across identity domains can be IT Infrastructure a found in ITI TF -1: E.3, E.4, E.5. (PIR) in an Affinity Domain G.2 Patient Information Reconciliation PIR workflow within a local domain is well understood and addressed within the IHE PIR 6855 Integration Profile. However, within an XDS affinity domain, there is the added complexity of managing patient information within the XDS Re gistry and synchronizing data between the document sources, repository and registry. Patient Merge within XAD Patient Identity Domain G.2.1 6860 XAD patient identity domain merges two patients • • Document sources are unaware of the merge transaction within XAD patient i dentity domain In this situation: • XDS Registry receives a merge notification from the XAD patient identity source and applies merge logic to the registry 6865 Document consumers have continued access to documents pertaining to the patient since • pected to obtain the XAD patient ID for the patient at the time of consumers are ex querying 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: 6870 Consumers have continued access to the document • ____________________________________________________________________________ 310 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

311 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ The document source must query for the XAD patient ID before attempting to • interact 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: • 6875 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 the • old document. From the document source’s perspective, the old document is still 6880 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 has taken place and use the new XAD patient ID to deprecate the old document The process flow is described in more detail as follows: Scenario: • 6885 Key identifier for a patient within the XAD patient identity domain changes, such as health number • The XAD patient identity source merges two patients Process Steps: The XAD patient identity source sends a “merge” notification to the XDS Registry 1. 6890 XDS Registry applies merge logic to the patients within the merge notification 2. • y will be accurate with the exception of the source patient The metadata in the registr ID XAD Domain Patient ID does not change Local Domain Patient Update - G.2.2 6895 • Demographics for the patient change • Local domain patient ID does NOT change • XAD patient ID does NOT change 6900 In this scenario: • 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 ____________________________________________________________________________ 311 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

312 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 6905 The process flow is described in more detail as follows: Scenario: • Patient first name is corrected from “Jamie” to “James” in the local domain patient identity source Process Steps: 6910 ADT) to the 1. Update information flows from the l ocal domain patient identity source ( i.e., document source: image manager/archive. • Document source updates its database to correct demographics Either: Document source does not change the document • 6915 • ory/registry. In this scenario, the The Document Source does not update the reposit B Sex, etc.; in the Document Source do not patient demographics: Name, Do 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 • 6920 2. The Registry takes no action as the XAD patient ID has not changed G.2.3 Local Domain Patient Update - XAD Domain Patient Merge Demographics for the patient change • Local domain patient ID does NOT change • 6925 change and triggers a merge within XAD domain • XAD patient ID does Document sources are unaware of the merge transaction within XAD patient identity • domain In this scenario: 6930 G.2.1 Patient Merge within XAD Patient Identity Domain See Section • The process flow is described in more detail as follows: Scenario: Patient last name is corrected from “Alfonsp” to “Alfonso” within local domain patient • 6935 identity source ____________________________________________________________________________ 312 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

313 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ XAD domain patient identity source merges “Alfonsp: XAD -Pp” into “Alfonso: XAD • - Pa” – patient “Alfonso” was already registered within the XAD domain with patient ID Pa XAD- 6940 Process Steps: G.2.1 Patient Merge within XAD Patient Identity Domain • See Section XAD Domain Patient ID does not change Local Domain Patient Merge – G.2.4 • Demographics for the patient changes 6945 • 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 the • same 6950 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 for the merged patient patient ID The XAD patient ID is the same as already associated with the document: • 6955 • 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 existing document. 6960 The process flow is described in more detail as follows: Scenario: Patient last name is corrected from “Smythe” to “Smyth” • • ADT already has an entry for “Smyth” 6965 • “Smythe” with local domain patient ID D -123 is merged with Smyth with local domain -456 patient ID D XAD Patient Identity Sourc • -456” -123” and “Smyth: D e already recognized “Smythe: D -Px as the same patient and, therefore, assigned each with the same XAD patient ID: XAD ____________________________________________________________________________ 313 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

314 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Process Steps: 6970 1. Update information flows from the local domain patient identity source ( i.e., ADT) to the document source: image manager/archive. • Document source applies merge logic to the database: documents for the merged patient are associated with the new patient ID 2. 6975 Document source queries the XAD patient identity domain to determine whether the XAD patient ID ha s changed for the merged documents. In this case the XAD patient ID does not change 3. Document source updates the demographics of the document • Either: Document source makes no changes to the document – demographics are in the database 6980 d not update the repository/registry. In this scenario, • The Document Source nee 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 • repository/registry with an addendum The Document Source updates the • 6985 The Registry takes no action as the XAD patient ID has not changed 4. XAD Domain Patient Merge G.2.5 Local Domain Patient Merge – • Demographics for the patient changes atient B Local domain patient identity source merges patient A with p • • XAD patient IDs for patient A and patient B are different 6990 Patient A is merged with patient B in the XAD domain patient identity source • There are three situations that can occur: 1. XDS Registry merge prior to Document Source merge • 6995 XDS Registry receives a merge notification from the XAD patient identity source and applies merge logic to the registry Document sources are unaware of the merge transaction that occurred in the XDS • G .2.1) Section registry and do not need to know about this transaction (see 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 time 7000 of querying the Registry ____________________________________________________________________________ 314 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

315 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 7005 The XAD patient ID for the documents has changed: • • The docum ent source changes the XAD patient ID associated with the documents – it can assume that the Registry has made this change as well If the document source does not change the document content, the document source • 7010 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 – the existing document is deprecated. 7015 Document Source merge prior to XDS Registry merge 2. Document sources apply merge logic to the documents within their database i.e., • documents are now associated with a new local domain patient ID he XAD • Document sources must now query XAD patient identity source to obtain t patient ID for the merged patient • The XAD patient ID is the same as already associated with the document: 7020 If the document source does not change the document content, the document • s quo source does not need to interact with XDS Repository/Registry – statu 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 7025 XDS Registry receives a merge n otification from the XAD patient identity source and • applies 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 continue d access to documents pertaining to the patient since 7030 • consumers are expected to obtain the XAD patient ID for the patient at the time of querying the Registry 3. Document Source merge at same time as XDS Registry merge 7035 Document sources apply merge logic to the documents within their database i.e., • documents are now associated with a new local domain patient ID ____________________________________________________________________________ 315 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

316 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ • 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 • 7040 • XDS Registry receives a merge notification from the XAD patient identity source and applies 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: 7045 The XAD patient ID for this document has now been merged in the XDS Registry • and, therefore, is no longer valid • nt registration transaction as the XAD patient The Registry will reject the docume 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 7050 -register the document with the XDS reposito ry/registry Scenario: Patient last name is corrected from “Smythe” to “Smyth” • 7055 ADT already has an entry for “Smyth” • • Smythe: patient ID D -123 is merged with Smyth: patient ID D -456 -Pc” and XAD Patient Identity Source has separate entries for both “Smythe: XAD • -Pf”. “Smyth: XAD- Pf”. As such, it merges these two patients in to “Smyth: XAD 7060 Process Steps: The process flow is a combination of the previous scenario process flows and, thereby, not repeated here. ____________________________________________________________________________ 316 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

317 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Appendix H: Security considerations for XDS -I.b (informative) This IHE profile does not specify all the details of the security environment for exchanging 7065 radiology information . The IHE includes several security profiles that apply to the XDS/ XDS - . The use of these security profiles in the first trial implemen use I.b will likely -I.b tation for XDS be optional . The security profiles make assumptions about the overall security environment and are configurable to adapt to different security requirements. Figure H -1 shows typical transactions for goes through security and . Each transaction XDS -I.b 7070 privacy controls . This figure illustrates use of firewall access points and TLS controls for all . The firewalls may have simple participants, including the Imaging Document Source -I.b XDS les depending upon local policies . The flows shown easy to implement rules or more complex ru H -1 are described in more detail below: in Figure , The Store Images, etc. transactions: Flow #1 7075 a) Internal firewall rules I: : “outgoing HTTP is OK” - Simple rules : examine s ource IP, destination IP, HTTP headers to decide whether to - Complex rules permit the connection. 7080 b) TLS within each actor: - IM/IA : Is this really the authorized Image Document Source that was requested? Repository - : Is this really an authorized IM/IA? c) Once the TLS connection is established there is further processing, generation of audit records, etc. 7085 Flow #2, The Provide and Register Imaging Document Set transaction: a) does not cross a firewall . b, c) TLS, authorization, auditing as above The Register transaction 7090 Flow #3, a) External firewall rules II: Simple : Outgoing HTTP is OK - Complex : examine source IP, destination IP, HTTP headers to decide whether to permit the - connection. b, c) TLS, authorization, auditing as above. 7095 ____________________________________________________________________________ 317 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

318 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ , Query Documents transaction: Flow #4 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 diff erent web 7100 - applications. b, c) TLS, authorization, auditing as above. Flow #5 , Retrieve Images, etc. transactions: 7105 a) External firewall access rules III: Simple - : Incoming DICOM is only permitted from authorized affinity domain IP blocks. Complex - : Examine the DICOM retrieve connection initiator and the targeting acceptor IP addresses, and permit only connections between a priori authorized pairs of initiator and acceptor. 7110 b, c) TLS, authorization, auditing as above. . It is easier to get multi- This example layer shows access for both HTTP and DICOM traffic protection for the DICOM traffic because it is easily differentiated from the many diverse uses of . Then the TLS security, actor authoriza HTTP for web applications and services tion rules, and 7115 auditing are applied to all traffic regardless of type. ____________________________________________________________________________ 318 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

319 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Inside the Enterprise Outside the Enterprise ( Affinity Domain and the rest of the world.) Affinity Domain Zone (Part of DMZ) II Registry 3 4 Reposit ory Image Manager/ Image Archive Internet TLS Authentication, Affinity Authorization 1 2 5 Document III I Consumer Imaging Document Source Internal Firewall External Firewall -1: Security Environment Figure H IHE assumes that there will be some form of external control point. This usually involves routers, etc. IHE does not specify what is necessary here, and technologies like VPNs, firewalls, the IHE profiles will operate and provide a good level of security even when the external control 7120 point is missing. The purpose of having an external control point is: network access between the Internet and the Imaging Document To control the low level • . The precision of this control is up to the sites Source and Document Repository 7125 involved. One common configuration is to merely restrict the list of IP Ports that are plifies the security requirements on the server. . This sim permitted access 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 the overall IT organization requirements. This kind of protection is useful and complements the encryption and access controls defined as 7130 part of IHE’s Audit Trail and Node Authentication (ATNA) Profile and its Radiology Option. ____________________________________________________________________________ 319 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

320 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 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 detect problems and to provide a means of rapidly isolating portions of the network in the event of a 7135 security breach. The Imaging Document Source is assumed to be located in the zone labeled the “Affinity . This might also be part of a general DMZ (De Domain Zone” r the -Militarized Zone) fo organization 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 7140 support both approaches. security requirements for the Imaging Document Source . It will IHE will specify the minimum- 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: 7145 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 • 7150 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 P rofile mandates this protection for any DICOM, HL7, HTTP or other protocols. There may be special auditing requirements for an XDS -I.b actor . For example, in the US there 7155 are HIPAA requirements for disclosure logs. Only the sites themselves can determine w hat belongs in a disclosure log. The ATNA logs were not directly intended for this purpose. The Imaging Document Source may be a system that is complete with its own image archive, or rhaps located in a it may be a proxy machine that relays information to another machine, pe . The XDS 7160 specifies Profile -I.b . This is considered an internal design issue by IHE private zone transactions, and does not specify that the Imaging Document Source must support the XDS -I.b the internal design. design considerations for securing There are several important networks that must be -I.b XDS . These are: made by the affinity domain and its members 7165 1. What kind of external control points are used? IHE recommends that they be present, but does not profile them. 2. nterprise network and whether to establish a dedicated Affinity How to subdivide the e . There is an advantage to creating Zone Domain an Affinity Domain Zone with just a few servers located in it: ____________________________________________________________________________ 320 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

321 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ a. The log analysis is easier 7170 b. The certificate and TLS management for node authentication is easier The preparation of disclosure logs and the equivalent is easier. c. d. The internal control point reduces the risks from a breach of the Affinity Domain Zone. Whether User Authentication is needed 7175 3. . IHE provides both the Enterprise User Authenticat ion (EUA) and Cross Enterprise User Assertion (XUA) Profile s. Use of user 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: . These can be 7180 a. What to do about automated processes, such as pre -fetch and email identified using node authentication via TLS as specified in ATNA, by using simple identity assertions. How to handle delegation. Often it is clerks, nurses, etc. that are actually operating b. 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 7185 nformation. further useful i The IHE profiles do not determine these choices . Some reasonable selections include: 1. Not using user authentication. The ATNA ensures that the enterprise and the machine are authenticated . These machines are already authenticated and trusted to protect PHI information 7190 . It may be impractical to track and coordinate the personnel activities across all the different organizations. - 2. Though not specifically designed for this purpose, it is also possible that the XDS is being used internall I.b Profile y within a centrally controlled large organization, where the Kerberos based identity management of EUA is available. EUA can be . EUA supports simple identity 7195 -enterprise environment used in such an intra cated node to provide the assertions . These are based on trusting the authenti . correct identity of its user The use of XUA is optional. Where a human user is involved, XUA can be 3. employed for cross -enterprise user identity assertion. If only machines are involved, the node authentication provided by ATNA s . The hould be sufficient 7200 use of XUA requires that the affinity domain establish the authentication policies, procedures, and have a supporting infrastructure of servers, etc . (This infrastructure may be provided by the local government or might need to be provided by the affinity domain.) 7205 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, the mechanism 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. ____________________________________________________________________________ 321 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

322 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. 7210 ____________________________________________________________________________ 322 Rev. 1 – Final Text 201 8-07-27 Copyright © 2018 : IHE International, Inc. 7.0

323 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Appendix I: Appendix I – Deployment of Dose Registries The Radiation Exposure Management Profile is intended to facilitate Dose Registry projects . can be depended on to provide data d the REM Profile Participating sites that have implemente with known contents in a known format and will all support a common transport mechanism 7215 . See the Submit Dose Information transaction for details (RAD TF -3: 4.63). This appendix includes discussions of logistical issues related to the deployment of dose , but the discussions here may registries . This is not part of the normative text of the REM Profile be helpful when deploying and using the REM Profile . 7220 I.1 Dose Registry Deployment Issues Code Set Management I.1.1 Although the REM Profile does manage to provide consistent dose data, for a Dose Registry to analyze dose objects and prepare summary statistics for a specific exam type, anatomy or am type, anatomy or pathology/indication, it will need to select/group dose objects based on ex 7225 pathology/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 is . Due to similar issues, consistency within an organization may even be challenging. unlikely 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 of 7230 . This may involve reverse engineering the codes from Code standard codes or categories Description fields, when available, or it may involve requesting code sets from participating sites. , there may be a procedure code Dose Registries should also be prepared for a lack of detail e.g. 7235 for “stent placement” but no indication if it was one stent, three stents, or more. I.1.2 Configuration of Secure FTP (Submit Dose Information Transaction – RAD - 63) ubmit Dose Information The REM Profile requires Dose Information Reporters support the S Transaction for the purpose of submitting dose data to Dose Registries. The Submit Dose Information Transaction specifies the use of FTP over TLS. 7240 When setting up the FTP server the dose registry project should consider useful featur es such as: 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 • ____________________________________________________________________________ 323 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

324 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ I.1.3 Alternative Transport Mechanisms 7245 -RS The DICOM STOW defined in the Submit Dose Transaction is Transport mechanism intended to provide a baseline transport mechanism . It is not intended to prohibit Dose Registry projects from using other transport mechanisms , as long as they also support the baseline . mechanism Some alternative transport mechanisms to consider include sending the objects via: 7250 • CD using the IHE Portable Data for Imaging (PDI) Profile • Secure FTP (which was defined in the original REM Profile but has been removed) • Email using the DICOM Email Media Profile and SMTP (XDM) -STORE Network using DICOM C to a DICOM Storage SCP or a VPN • over TLS 7255 -I) Profile -Domain Document Sharing for Imaging (XDS Network using the IHE Cross • Note the need to establish an Affinity Domain covering all contributing sites and to • fill in the XDS metadata which may be complicated by de -identification. • Note also the need to provide an Imaging Document Source at the provider end, since XDS -I does not “push” the dose objects themselves to the recipient, but rather register s their availability, requiring them to then be “pulled”. 7260 for Imaging -Domain Document Reliable Interchange • Network using the IHE Cross -I) Profile (XDR -file bundles, and “replacing” • -I features such as multi This might be attractive if XDR documents would be useful. 7265 • Note again the need to fill in the XDS metadata. Encapsulated Dose Registry Submission I.1.4 Another approach to addressing submission issues and facilitating site is for the organization that bute a client application to each is setting up a dose registry project to develop and distri participating site. 7270 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 ietary upload mechanism to get the dose objects up to the dose registry incorporate . a propr 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 7275 outside the organization. Imagine: • the XYZ Dose Registry Client implements the Dose Information Consumer to get dose vices protocol to send them to the Dose Registry objects, and some email or web ser ____________________________________________________________________________ 324 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

325 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ XYZ Registry Dose Registry XYZ Client Dose Info Proprietary Consumer Mechanism ↓ Query Dose Information ] 64 - [RAD - Retrieve Dose Information ] 65 [ RAD ↓ PACS Image Mgr/ Archive [RAD ↑ - 62] Store Dose Information ↑ 10] Storage Commitment - [RAD Acquisition Modality 7280 I.2 Real -World Projects A number of organizations have established or are in the process of establishing Dose Registry projects. 7285 Project: ACR Registry - USA . The initial pilot program will compare ACR is forming a national Dose Index Registry (DIR) 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. Thei r 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 and 7290 Benchmarking . They are specifically not interested in the Patient Dose History Use C ase as they have no plans to become a national personal dose record. Website : nrdr.acr.org ____________________________________________________________________________ 325 : IHE International, Inc. Copyright © 2018 8-07-27 – Final Text 201 7.0 Rev. 1

326 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ French Ministry of Health Registry Project: ose French regulations mandate the submission of Dose Reference Level data to a federal d 7295 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 at least two ex amination types (generally the most frequent and most irradiating examination 7300 types). The ministry is interested in Use Cases including: Population Dose and Dose Indicators, and . Data collection spans Radiography, Fluoroscopy, Mammogr aphy, Dose Reference Levels . The data is further broken down by patient age Computed Tomography and Nuclear Medicine category, and body part. www.irsn.org/en Website: 7305 Dose Monitoring Regulations I.3 ) drove original definition Several groups interested in regulatory issues (IEC, FDA, AAPM, etc. of the DICOM Dose SR objects . . The following sections contain some contributed summarie s of different regulatory initiatives These are only intended to provide a sense of the type of activities . Readers should refer to the 7310 regulations themselves for accurate information. European Regulatory European regulation is based on European Directive Euratom 1997/43/EC . The application of the directive is mandatory in all EU countries (27 today) since 2000. All European national regulations have to be compatible with the directive 7315 . Different countries have varied in their . reactions/actions to Euratom Euratom specifies a follow up for each patient and statistical analysis at the population level. n_en.htm http://ec.europa.eu/energy/nuclear/radioprotection/legislatio Euratom : Diagnostic Reference Levels (DRLs) in Europe : http://www.eu -alara.net/index.php?option=com_content&task=view&id=156&Itemid=53 7320 French Regulatory Today two regulations specify the dosimetric information that a user of ionising radiation must provide in France. One text, published in March 2004, concerns Dose Reference Levels (DRL) (Arrêté du • 7325 12 février 2004 relatif aux niveaux de référence diagnostiques en radiologie et en . mé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 be êté du 22 septembre 2006 present in the medical record of the diagnostic examination (Arr ____________________________________________________________________________ 326 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

327 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ relatif aux informations dosimétriques devant figurer dans un compte rendu d'acte 7330 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 7335 In Germany and the Netherlands, dose information is not conveyed above the Hospital level. Dose information is requir ed 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 • 7340 Indications for Procedure Physician Responsible for Indication • Performing Person (who administered) • • Radioactive Substance Administered • Radiation Exposure (text description of "the exposure") 7345 Performing Person’s Organization Name • Spanish Regulatory In Spain, dose information is not conveyed above the Hospital level . 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 7350 responsible health authority and the Nuclear Security Council will guarantee that the distribution of the estimations of resulting individual doses is determined, for the population and the significant groups of reference of the population, whose results will be sent to the Ministry of Health and Consumption. ____________________________________________________________________________ 327 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

328 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ 7355 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 more requested procedures. 7360 in a use case diagram that can perform an action within a use case diagram. An entity with Actor: Possible actions are creation or consumption of a message . Conventional 2D mammography: Refers to mammography images that have been acquired using FFDM. ICOM object (See DICOM PS 3.3: A.35.8 X -Ray Radiation Dose A persistent D Dose Object: 7365 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. A trademark of the DVD Forum that is not an abbreviation DVD: Evidence Documents: 7370 Evidence Documents represent the uninterpreted information that is primarily managed and used inside the imaging department, although distribution outside the -image information and imaging department is not precluded. Evidence documents are non include things such as measurements, CAD results, procedure logs, etc. and are to be encoded as DICOM SR documents. 7375 objects generated as a result of performing procedure steps on systems in All Evidence Objects: an imaging department. These objects are used by the reading physician in the process of creating a diagnostic report and are managed inside the imaging Department. Examples of evidence objects include: Images, Presentation States, Key Image Notes and Evidence Documents. 7380 Actions which should occur as the result of a trigger event Expected Actions: A database key that is used as a reference to relate one entity to another Foreign Key (FK): entity . It may be a unique value, or used in conjunction with another Foreign Key to create a unique value. -digital data into the Enterprise as DICOM The process of importing non Hardcopy Import: nal data may be Films or Documents that are scanned and stored as DICOM Objects 7385 . The origi Objects. Images Available: A transaction or transactions used to determine that images have been stored in an image archive and may be retrieved. epicts data flow and sequencing of events Interaction Diagram: A diagram which d bearing physical media, such as a CD or DVD. The term, A piece of data- Interchange Media: 7390 which is used in the DICOM standard, is synonymous with “portable media” or “transfer media”. ____________________________________________________________________________ 328 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

329 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ : An irradiation event is one continuous occurrence of irradiation being Irradiation Event -slice helical CT scan are -Ray acquisition, or a multi applied to a patient. A pulsed fluoro X of examples of single events; while a CT scanogram and the helical scan, or two different presses -ray tubes are examples of separate the fluoro pedal, or simultaneous irradiation from two X 7395 events. See RAD TF -3: 4.62.4.1.1 in Store Dose Information for a more detailed description -fetch: ts from previously Pre The activity of fetching images or other information objec 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 7400 The actions of an actor in a use case. Role: A brief description of the transaction. Scope: Slab: A thick slice tomosynthesis reconstruction (e.g., greater than 1mm). Trigger Event: An event such as the reception of a message or completion of a process, which 7405 ccur. causes another action to o 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 e.g., XHTML files and JPEG images) Web -Viewable: Browsable using a web browser ( XDS Imaging Documen t: 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 7410 Registry. An XDS Imaging Document may contain a manifest of images ( e.g., DICOM Key ocument) or a radiology report provided either as a PDF document or as Object Selection d structured and vocabulary coded clinical information ( e.g., CDA Release 2). DICOM Terms 7415 Basic Color Print Management Meta SOP Class: See DICOM PS3.4 See DICOM PS3.4 Basic Grayscale Print Management M eta SOP Class: See DICOM Supplement 23 Basic Text SR Storage SOP Class: DICOM Model of the Real World: See DICOM PS3.3 Enhanced SR Storage SOP Class: See DICOM Supplement 23 7420 See DICO Grayscale Softcopy Presentation State Storage SOP Class: M PS3.4 DICOM PS3.14 Grayscale Standard Display Function: See DICOM PS .3 Imaging Service Request: See DICOM PS3.3 Modality: Modality Worklist SOP Class: 7425 See DICOM PS3.4 ____________________________________________________________________________ 329 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

330 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ See DICOM PS3.3 Modality Performed Procedure Step: See DICOM PS3.3 Modality Performed Procedure Step Information Module: See DICOM PS3.3 Modality Performed Procedure Step Relationship Module: See DICOM PS3.4 Modality Performed Procedure Step SOP Class: 7430 See DICOM PS3.3 Patient: Patient Identification Module : See DICOM PS3.3 Presentation LUT SOP Class : See DICOM PS3.4 Print Procedure Plan : See DICOM PS3.3 : See DICOM PS3.3 Procedure Type 7435 : See DICOM PS3.3 Protocol Code : See DICOM PS3.3 Requested Procedure : See DICOM PS3.3 Requested Procedure Module OM PS3.3 Requested Procedure ID : See DIC Results Information Object Definition : See DICOM PS3.3 7440 : See DICOM PS3.3 Scheduled Procedure Step : See DICOM PS3.3 Scheduled Procedure Step Module Storage Commitment SOP Class : See DICOM PS3.4 : See DICOM PS3.4 Stored Print SOP Class : See DICOM PS3.3 Structured Reporting Information Object Definitions : See DICOM PS3.4 7445 Structured Reporting SOP Classes : See DICOM PS3.16 Structured Reporting Templates : See DICOM PS3.5 Unique Identifier (UID) HL7 Terms See HL7 version 2.3.1 7450 ADT: See HL Battery: 7 version 2.3.1 Filler: See HL7 version 2.3.1 See HL7 version 2.3.1 Observation: See HL7 version 2.3.1 Placer: See HL7 version 2.3.1 Universal Service ID: 7455 ____________________________________________________________________________ 330 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

331 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Acronyms and Abbreviations ACR: American College of Radiology CAD: Computer Aided Detection Compact Disk 7460 CD: Dose Area Product DAP: DBT: Digital Breast Tomosynthesis DLP: Dose Length Product Food and Drug Administration (USA) FDA: FFDM: Full Field Digital Mammography 7465 File -Set Creator FSC: File FSR: -Set Reader GSPS: Grayscale Softcopy Presentation State Healthcare Information and Management Systems Society HIMSS: Hospital Information System HIS: 7470 Hyper Text Markup Language HTML: ICRU: International Commission on Radiological Units IEC: International Electrotechnical C ommission IHE: Integrating the Healthcare Enterprise 7475 IOD: Information Object Definitions IT: Information Technology Joint Photographic Experts Group JPEG: LUT: Look Up Table MPI: Master Patient Index Modality Performed Procedure Step 7480 MPPS: MQSA: Mammography Quality Standards Act of 1992 MWL: Modality Worklist NEMA: National Electrical Manufacturers Association PACS: Picture Archive and Communication System PHI: 7485 Protected Healthcare Information Performed Procedure Step PPS: PSD: Peak Skin Dose ____________________________________________________________________________ 331 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

332 IHE Radiology Technical Framework, Volume 1 (RAD TF -1): Integration Profiles ______________________________________________________________________________ Quality Assurance QA: Radiology Information System RIS: 7490 RSNA: Radiological Society of North America SCU: Service Class User Service Class Provider SCP: Structured Report SR: Unique Identifier UID: 7495 Universal Serial Bus USB: 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 272- 284 . 4, pp. [2] Quality Improvement Guidelines for Recording Patient Radiation D ose in the Medical 7500 Record, Donald Miller, Stephen Balter, et al, Journal of Vascular Interventional Radiology, 2004, Vol. 429 15, pp. 423- -Rays Used in Medical Imaging. JICRU 5; [3] ICRU. Report 74: Patient Dosimetry for X 2005. [4] IEC. IEC 60601. (2000). Medical electrical equipment - 7505 -43: Particular Part 2 -ray equipment for interventional procedures. Geneva; 2000. requirements for the safety of X [5] IEC. PAS 61910- 1 Radiation Dose Documentation Part 1: Equipment for radiography and radioscopy. Geneva; 2007. [6] FDA. Federal performance standard for diagnostic x -ray systems and their major -- FDA. Final rule. Fed Regist 70: 33998 - 7510 34042; 2005. components [7] Capturing Patient Doses from Fluoroscopically Based Diagnostic and Interventional alter, NCRP Annual Meeting Systems, Stephen B -07; 2008 ____________________________________________________________________________ 332 : IHE International, Inc. Rev. 1 7.0 – Final Text 201 8-07-27 Copyright © 2018

Related documents