IHE_RAD_Suppl_IID_Rev1.3_TI_2016

Integrating the Healthcare Enterprise

IHE Radiology 5

Technical Framework Supplement

Invoke Image Display 10

(IID)

Rev. 1.3 - Trial Implementation 15

Date: September 9, 2016 20

Author: IHE Radiology Technical Committee

Email: [email protected]

Please verify you have the most recent version of this document. See here for Trial 25

Implementation and Final Text versions and here for Public Comment versions.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Foreword

This is a supplement to the IHE Radiology Technical Framework V15.0. Each supplement

undergoes a process of public comment and trial implementation before being incorporated into

the volumes of the Technical Frameworks. 30

This supplement is published on September 9, 2016 for trial implementation and may be

available for testing at subsequent IHE Connectathons. The supplement may be amended based

on the results of testing. Following successful testing it will be incorporated into the Radiology

Technical Framework. Comments are invited and can be submitted at

http://www.ihe.net/Radiology_Public_Comments. 35

This supplement describes changes to the existing technical framework documents.

“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the

relevant section(s) into the relevant Technical Framework volume.

Amend Section X.X by the following:

Where the amendment adds text, make the added text bold underline. Where the amendment 40

removes text, make the removed text bold strikethrough. When entire new sections are added,

introduce with editor’s instructions to “add new text” or similar, which for readability are not

bolded or underlined.

General information about IHE can be found at: www.ihe.net. 45

Information about the IHE Radiology domain can be found at: ihe.net/IHE_Domains.

Information about the organization of IHE Technical Frameworks and Supplements and the

process used to create them can be found at: http://ihe.net/IHE_Process and

http://ihe.net/Profiles.

The current version of the IHE Radiology Technical Framework can be found at: 50

http://www.ihe.net/Technical_Frameworks.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

CONTENTS

Introduction to this Supplement ...................................................................................................... 4

Open Issues and Questions ........................................................................................................ 4

Closed Issues .............................................................................................................................. 4 60

General Introduction ....................................................................................................................... 6

Appendix A – Actor Summary Definitions .................................................................................... 6

Appendix B – Transaction Summary Definitions ........................................................................... 6

Glossary .......................................................................................................................................... 6

Volume 1 – Profiles ....................................................................................................................... 7 65

Copyright Licenses..................................................................................................................... 7

Domain-specific additions ......................................................................................................... 7

2.1 Integration Profiles Overview .............................................................................................. 7

2.1.35 Invoke Image Display ................................................................................................ 7

2.3 Actor Descriptions ............................................................................................................... 7 70

2.4 Transaction Descriptions ...................................................................................................... 8

35 Invoke Image Display (IID) Profile ........................................................................................... 9

35.1 Invoke Image Display (IID Actors, Transactions, and Content Modules) ........................ 9

35.1.1 Actor Descriptions and Actor Profile Requirements ................................................ 10

35.2 IID Actor Options ............................................................................................................ 10 75

35.3 IID Actor Required Groupings......................................................................................... 10

35.4 IID Overview ................................................................................................................... 10

35.4.1 Concepts ................................................................................................................... 10

35.4.2 Use Case #1: Review Studies ................................................................................... 14

35.5 IID Security Considerations ............................................................................................. 16 80

35.6 IID Cross-Profile Considerations ..................................................................................... 17

Volume 3 – Transactions (cont.) ................................................................................................ 19

4.106 Invoke Image Display [RAD-106] ................................................................................. 19

4.106.1 Scope ...................................................................................................................... 19

4.106.2 Use Case Roles ....................................................................................................... 19 85

4.106.3 Referenced Standards ............................................................................................. 19

4.106.4 Interaction Diagram ................................................................................................ 20

4.106.5 Security Considerations .......................................................................................... 26

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Introduction to this Supplement 90

The Invoke Image Display Profile allows the user of an Image Display Invoker, typically a non-

image-aware system like an EHR, PHR or RIS, to request the display of studies for a patient, and

have the display performed by an image-aware system like an Image Display (PACS).

Open Issues and Questions

Closed Issues 95

1. Should a SOAP-based version of the transaction be provided in addition to the HTTP

GET URL request?

No. Demand for SOAP not expressed. Do this first.

2. What about viewer automatically showing relevant priors? 100

No. Don’t burden the Image Display. Reports may or may not contain references to

relevant priors (which could be put in the study message by the Invoker).

IdentifyRelevantPriors would be a good service to which you could send various context

details and get back a list of relevant studyUIDs. 105

3. Is there value in including a "requesting physician" or similar parameter to constrain the

patient request studies provided?

No. Redundant with security/access control mechanisms and does not work with teams

(e.g., would need role rather than individual, etc.) 110

4. Should modality be an optional parameter for the patient request?

Yes. Useful to be able to ask just give me the latest CT instead of pulling a list and

looking for CTs.

5. What baseline security mechanisms should the profile specify that the "server" be 115

required to support?

Mention the server can request the user's credentials itself rather than attempting single

sign on or delegated trust. Otherwise leave it out of scope.

6. How should the invoker choose the right root when multiple providers are possible in the 120

same environment?

Current silence of the text is adequate. For a single service provider, a hardwired or

configurable URL root suffices. Can query a list of multiple configured roots. Could

receive appropriate root from the host (e.g., EMR), etc. 125

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

7. Is there a need to forbid caching?

OK to remain silent.

8. Should implementations be required to record various details in the Integration

Statement? 130

No. IS references other documents where such information could be recorded. Should

raise the issue with Domain Coord Cmte for further discussion.

9. Should "optional" parameters be explicitly required by the server?

135

Yes. They are optional only for the client, and were documented in the same manner as

ITI RID but this may be confusing. Should submit a CP to ITI perhaps.

10. Should machine readable definitions of the interface be provided?

Yes. WSDL has been found useful for IHE SOAP interfaces, is familiar to some IHE 140

implementers and WSDL is apparently appropriate for an http GET request even if there

is no SOAP binding ("http://www.w3.org/TR/wsdl.html#_http"). WADL is more

typically used for this type of interface. Both will be provided as files in the ftp folder and

referenced from the supplement.

145

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

General Introduction

Update the following Appendices to the General Introduction as indicated below. Note that these

are not appendices to Volume 1.

Appendix A – Actor Summary Definitions 150

Add the following actors to the IHE Technical Frameworks General Introduction list of Actors:

Actor

Definition

Image Display Invoker Requests display of DICOM image studies.

Appendix B – Transaction Summary Definitions

Add the following transactions to the IHE Technical Frameworks General Introduction list of

Transactions: 155

Transaction

Definition

Invoke Image Display [RAD-106]

Invokes the display of DICOM image studies.

Glossary

Add the following glossary terms to the IHE Technical Frameworks General Introduction

Glossary:

No new glossary items. 160

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Volume 1 – Profiles

N/A

Domain-specific additions

Add the new profile to Section 2 dependencies table 165

Table 2-1: Integration Profiles Dependencies

Integration Profile

Depends on

Dependency Type

Comments

… … … …

Invoke Image Display None None -

Add the new profile to Section 2.1

2.1 Integration Profiles Overview 170

…

2.1.35 Invoke Image Display

The Invoke Image Display Profile allows the user of an Image Display Invoker, typically a non-

image-aware system like an EHR, PHR or RIS, to request the display of studies for a patient, and

have the display performed by an image-aware system like an Image Display (PACS). 175

Add the following actors to Section 2.3

2.3 Actor Descriptions

…

Image Display Invoker – An actor that requests that DICOM

®1

image studies be displayed by

another actor (e.g., an Image Display Invoker might be an Electronic Health Record (EHR), 180

Personal Health Record (PHR) or Departmental Information System (such as a Radiology

Information System)).

…

DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards

publications relating to digital communications of medical information.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Add the following transactions to Section 2.4 185

2.4 Transaction Descriptions

…

Invoke Image Display [RAD-106] – An Image Display Invoker invokes the display of DICOM

image studies by an Image Display.

… 190

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

35 Invoke Image Display (IID) Profile

The Invoke Image Display Profile allows the user of an Image Display Invoker, typically a non-

image-aware system like an EHR, PHR or RIS, to request the display of studies for a patient, and

have the display performed by an image-aware system like an Image Display (PACS). 195

35.1 Invoke Image Display (IID Actors, Transactions, and Content

Modules)

Figure 35.1-1 shows the actors directly involved in the IID 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 that have a mandatory 200

grouping are shown in conjoined boxes.

Figure 35.1-1: IID Actor Diagram

205

Table 35.1-1 lists the transactions for each actor directly involved in the IID profile. In order to

claim compliance with this profile, an actor shall support all required transactions (labeled “R”)

and may support the optional transactions (labeled “O”). Actor groupings are further described in

Section 35.3.

210

Table 35.1-1: IID Profile - Actors and Transactions

Actors

Transactions

Optionality

TF Reference

Image Display Invoker Invoke Image Display [RAD-106] R RAD TF-3: 4.106

Image Display Invoke Image Display [RAD-106] R RAD TF-3: 4.106

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

35.1.1 Actor Descriptions and Actor Profile Requirements

35.1.1.1 Image Display Invoker

This profile specifies only the interoperability requirements of the Image Display Invoker

immediately associated with requesting the display of images. 215

35.1.1.2 Image Display

In the absence of a claim of support for another profile that specifies requirements for Image

Display, the Integration Statement for the Image Display shall include a link to documentation

describing either explicitly, or by reference to its DICOM Conformance Statement, the type of

images supported, such as the variants of DICOM images and evidence objects (which may 220

include Presentation States, Evidence Documents, Key Image Notes).

The Image Display shall be able to provide both review and diagnostic quality. See RAD-TF-3:

4.106.4.2.2.2.

In the context of this profile, how the Image Display obtains the images to display based on the

parameters provided, is not specified. 225

Note: E.g., it may be integrated with an Image Manager/Archive, Imaging Document Source or Imaging Document

Consumer, or it might retrieve images from an Image Manager/Archive, etc.

35.2 IID Actor Options

Options that may be selected for each actor in this profile, if any, are listed in the Table 35.2-1. 230

Dependencies between options when applicable are specified in notes.

Table 35.2-1: Invoke Image Display - Actors and Options

Actor

Options

TF Reference

Image Display Invoker No options defined - -

Image Display No options defined - -

35.3 IID Actor Required Groupings 235

None

35.4 IID Overview

35.4.1 Concepts

The IID request to display a patient’s studies is implemented as a single HTTP request with the

appropriate parameters identifying the patient or one or more studies, and accompanying 240

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

parameters describing the desired display behavior. The request is implemented as a simple

HTTP GET with the parameters in the URL.

The Image Display is responsible for somehow displaying the images to the user. This may be

via a current or new window hosted in a browser that shares a screen with, or is embedded in, the

IDI, or it might be via a separate co-located hardware device that is driven directly by the Image 245

Display, or it might be via a plug-in provided by the Image Display but executed on the IDI

system, or it might be by some other means.

This profile does not specify what mechanism, browser or platform is necessary to actually

execute the display software, or how to identify the user and control their access; these are

matters of local IT infrastructure configuration, customization of software, or even configuration 250

of software other than the browser +/- consumer plugins. An Image Display that complies with

this profile will not necessarily be able to display images for an IDI actor that complies with this

profile, due to such technical details that are not constrained or specified by this profile.

The following sections outline several conceptual scenarios where IID can be used.

35.4.1.1 Mobile Web EHR Invoking Mobile Web Image Viewer 255

Figure 35.4.1.1-1: Mobile Web EHR Invoking Mobile Web Image Viewer

In this scenario, a user reviewing data on their mobile EHR application would like to review

associated images to a report. Using IID, hyperlinks are generated by the EHR and displayed to 260

the user; when clicked, it will launch a mobile web image viewer. The Image Display Invoker is

the system which is responsible for the contents of the IID message string (in this scenario the

HTTP Provide patient identifiers + cookie

HTTP Log in to EHR Portal

Mobile

Browser

EHR Portal

PACS Web

Server

Return HTML patient lookup page + cookie

Return patient details + embedded IID links

User

clicks

IID

link

[RAD-106] Invoke Image Display

(HTTP Request Display of Study Images + cookie

Return HTML image viewer page

HTTP Request for binary image data + cookie

Return requested binary image data

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

EHR which embeds the string as a link in the HTML that it provides to the Browser) even

though the message is transmitted to the Image Display by another device (in this scenario the

Mobile Browser). 265

Only the IID transaction is standardized within the scope of this profile; in particular, the

“cookie” referenced in Figure 35.4.1.1-1 is a placeholder for any form of authentication session

state information supported by the actors.

35.4.1.2 Desktop EHR Invoking Desktop Image Viewer

270

Figure 35.4.1.2-1: Desktop EHR Invoking Desktop Image Viewer

In this scenario, a user reviewing data on their EHR desktop application requires access to

diagnostic quality images for treatment decision-making. Using IID, buttons are generated in the

desktop application, and when clicked, will launch a transient popup page that triggers the 275

startup of a local PACS viewing application and then commands that application to display the

selected study.

Request for binary image data

[RAD-106] Invoke Image Display

(HTTP IID Request Display of Study Images)

Client

(IDI)

PACS Server

(ID)

Return Trigger to launch local PACS application

Return requested binary image data

User launches

detailed patient view,

which generates

embedded IID links

User clicks IID link

Launch local PACS

application

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

35.4.1.3 Advanced Image Display

Figure 35.4.1.3-1: Advanced Image Display 280

Similar to 35.4.1.2, this scenario demonstrates how this profile applies not only to traditional

EHR to PACS launches, but also to any application that triggers the launch of any other

application with an image-specific context, such as an advanced visualization tool. Note that in

this scenario the PACS Client is the Image Display Invoker, not the Image Display. 285

Request for rendered image data

[RAD-106] Invoke Image Display

(HTTP IID Request Display of Study Images)

PACS Client

(IDI)

Advanced

Visualization Server

(ID)

Return Trigger to launch Adv. Vis. application

Return requested rendered image data

User launches

detailed study view,

which generates

embedded IID links

User clicks IID link

Launch local advanced

visualization application

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

35.4.1.4 Launching Image Viewer on Adjacent Workstation

Figure 35.4.1.4-1: Launching Image Viewer on Adjacent Workstation

This scenario demonstrates how IID can be extended beyond traditional platforms. In this case, 290

IID is used to trigger a launch on another physical device; for example, a regular workstation

running an EMR Client side-by-side with a specialized PACS workstation.

35.4.2 Use Case #1: Review Studies

35.4.2.1 Review Studies Use Case Description

The user of an EHR, PHR or RIS computer or mobile device application can open a link to 295

review the study data on that device using the Invoke Image Display transaction.

Note: The Image Display may support a full functionality image review client that can be hosted on the EHR/PHR/RIS.

Such a client application may or may not be an Image Display (in other IHE profiles) using DICOM transactions

with the Image Manager/Image Archive.

Specific variants of this use case include: 300

1. A nurse practitioner, physician assistant or physician not expert in imaging is using the

EHR and wants to review only key images on mobile device; the user clicks on a "key

image review" button or a hyperlink in the radiology report, for a dated study entry for a

patient in the web application; the web browser tab switches to one that contains adequate

review quality (not diagnostic) key images. 305

[RAD

-106] Invoke Image Display

(HTTP IID Request Display of

Study Images)

EMR Client PACS Server

User clicks

IID link

PACS Client

User launches

detailed patient

view, which

generates

embedded IID

links

Launch

local

PACS

application

Generate Trigger to

launch local PACS

application

Request for binary

image data

Return requested

binary image data

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

2. A physician or surgeon expert in imaging is called to consult on an emergency patient

and is using an EHR application on a desktop computer (with a high speed connection to

the local network and with diagnostic quality displays); the user is reviewing the patient's

status and results, and wants to see the diagnostic quality images for treatment decision

making; the user clicks on "diagnostic image review" (or a hyperlink in the preliminary 310

or final radiology report, if one has been issued already) in a dated study entry for the

patient in EHR web portal; a new web browser page executing a zero footprint viewer

displays a complete set of diagnostic quality images for the selected study.

3. The same situation as 2, but when the user clicks on "diagnostic image review", a

transient popup page opens that triggers startup of local PACS viewing application and 315

then commands that application to display the selected study.

4. The same situation as 2, but when the user clicks on "diagnostic image review", an

already running local PACS viewing application is commanded to display the entire

study selected.

5. The same situation as 2, but when the user clicks on "diagnostic image review", a 320

separate workstation with specialized hardware running PACS workstation software,

physically co-located with the EHR workstation, is commanded to display the entire

study selected.

6. A physician or surgeon expert in imaging is located in another enterprise (a trauma

center) than where the patient is currently physically located (the emergency department 325

of a rural community hospital), and is evaluating whether the patient needs to be

transferred for treatment; the user has credentials on the EHR and PACS portals of the

remote site, with restricted access to transfer candidate patients only; the user interacts

with the remote EHR and thence the remote PACS using their mobile device with review

quality images, decides that diagnostic quality images are required, and repeats the 330

review using a diagnostic quality workstation, again interacting first with the remote

EHR and then invoking display by the remote PACS of the studies from the EHR

application; the patient is not yet registered in the local enterprise, and only remote

applications are executed, displaying on local hardware.

7. A physician or surgeon expert in imaging is consulting on a new patient referred from an 335

outside facility, either as an inpatient or in an ambulatory setting; the patient's history

(including radiology reports) has been previously loaded into the local EHR and the

patients images are available on the external regional image repository, where they are

indexed by an identifier different from the local medical record number, but known to the

EHR; the user has credentials to view images in the external regional image repository 340

(also known to the EHR); the user clicks on a hyperlink in a prior radiology report

displayed in the EHR, and a viewer supplied by external regional image repository but

running on the local hardware displays a complete set of diagnostic quality images for the

selected study.

8. The same situation as 7, except that the EHR has not stored the user's credentials for 345

access to the external regional image repository, hence the user is prompted for their

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

username and password by the remote external regional image repository before they are

permitted to view the images.

9. A patient's relative/friend/neighbor who is a specialist radiologist is asked by the patient

to review their images; together, using the patient's credentials to login to the patient 350

portal of the hospital EHR, they read the radiology report and then click on a hyperlink to

display their images; the patient portal of the hospital PACS, recognizing that the patient

is permitted access to their own images (only) displays a complete set of diagnostic

quality images for the selected study on the radiologist's teleradiology hardware that is

being used for the session. 355

10. The same situation as in 9, except that the patient's record being reviewed is in the

patient's own PHR, provided by their insurance company, and the images are stored in a

regional image repository, provided by the regional government.

11. The same situation as in 2, but the basic image viewer user wants to invoke a separate

advanced visualized application for the same studies as they were already looking at, so 360

requests the viewer software to invoked the more advanced application on the same

studies.

35.4.2.2 Review Studies Process Flow

Image Display

(ID)

Display Images

Image Display Invoker

(IDI)

Invoke Image Display

(RAD-106)

Figure 35.4.2.2-1: Basic Process Flow in IID Profile

365

35.5 IID Security Considerations

The Invoke Image Display Profile may be used in a variety of environments, from small

ambulatory practices, to large enterprises or cross-enterprise. The threat models for those

environments may vary widely, and hence the IID Profile does not mandate any specific security 370

protections.

Deployments should consider whether or not:

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

• The Image Display Invoker requires user authentication to access patient data.

• The Image Display uses credentials supplied by the Image Display Invoker in the Invoke

Image Display transaction, or whether the Image Display requires its own user logon 375

authentication

• Whether the Image Display Invoker or the Image Display (or both) records access in an

audit log.

The form and granularity (patient or study level) of any audit logging by the Image Display

Invoker and the Image Display are outside the scope of the IID Profile. The ITI Audit Trail and 380

Node Authentication (ATNA) Profile is recommended if appropriate to the deployment

environment.

How the Image Display Invoker supplies credentials to the Image Display in order to provide the

user with a seamless "single sign on" experience, if it does, is not defined in this profile. The

HTTP GET URL transaction allows for a range of authentication mechanisms including HTTP 385

basic authentication (over a secure connection to protect the cleartext credentials), digest

authentication, client certificate based authentication, provision of a SAML assertion in an

authentication header, or other mechanisms that are suitable for stateless atomic single phase

transactions.

Whether the Image Display requires that the Image Display Invoker identify the user 390

individually in order to perform access control, or whether it trusts the Image Display Invoker

regardless of the user, or uses some delegated authority mechanism, is outside the scope of the

IID Profile.

Not all approaches to deployment and management of security credentials will support

sufficiently restrictive access control to support all use-cases, particularly those involving access 395

by patients themselves, and cross-enterprise access.

35.6 IID Cross-Profile Considerations

Some uses cases for invoking image display involve access only to locally acquired images,

others are to allow the review of images that have been acquired in other locations, and to share

images acquired locally with other institutions. Each institution thus needs to be able to either 400

provide remote access or to exchange images with other institutions' EHR and image

management systems.

The IID Profile considers only the manner of requesting that images be displayed if they are

known to the system, regardless of whether they were acquired locally, imported, or reside in

remote systems. 405

The Image Display Invoker may be faced with the need to determine what endpoint (URL root)

they need to connect to in order to choose the right Image Display.

In the absence of a service to look up the endpoints, a hardwired or configurable (set of) URL

roots may be required.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

SWF – Scheduled Workflow 410

An Image Display in SWF that also claims IID can use query/retrieve to access images for

display.

XDS-I.b – Cross-Enterprise Document Sharing for Imaging

An Imaging Document Source in XDS-I.b might be grouped with an Image Display to respond

to requests from outside IDIs, and no XDS-I.b transactions are required. 415

Alternatively, an Imaging Document Consumer in XDS-I.b might be grouped with an Image

Display to locate and access remote study data for presentation to local Image Display Invokers.

The Image Display might use the assigning authority provided in the invocation request to get

guidance on the affinity domain to search. The Imaging Document Consumer retrieves the

images using XDS-I.b transactions from the Imaging Document Source, for use by the Image 420

Display.

IRWF – Import Reconciliation Workflow

An Importer in IRWF might be grouped with an Image Display to display images that have been

imported and adjusted to match local identifiers.

CPI – Consistent Presentation of Images 425

An Image Display in CPI that also claims IID can apply presentation states during display, and to

use a calibrated display. Note that the presentations states in question may have been created in

the context of the Presentation of Grouped Procedures (PGP) Profile.

KIN – Key Image Note

An Image Display in KIN that also claims IID can apply Key Object Selection documents that 430

may be present in the study as appropriate.

IOCM – Image Object Change Management

An Image Display in IOCM that also claims IID can suppress the display of rejected images in

the requested studies. An Image Display that only supports KIN might present the images along

with the KOS describing their rejection 435

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Volume 3 – Transactions (cont.)

Add Section 4.106

4.106 Invoke Image Display [RAD-106]

This section corresponds to Transaction RAD-106 of the IHE Radiology Technical Framework.

Transaction RAD-106 is used by the Image Display and Image Display Invoker actors. 440

This transaction is derived from CARD-15 and ITI-11.

4.106.1 Scope

In the Invoke Image Display Transaction, the Image Display provides an HTTP interface to

command display of stored DICOM images and evidence in one or more studies.

4.106.2 Use Case Roles 445

Actor:

Image Display Invoker

Role:

Requests display of DICOM image studies.

Actor:

Image Display

Role:

Displays DICOM image studies.

4.106.3 Referenced Standards

IETF RFC1738, Uniform Resource Locators (URL), http://www.ietf.org/rfc/rfc1738.txt

IETF RFC2616 HyperText Transfer Protocol HTTP/1.1, http://www.ietf.org/rfc/rfc2616.txt 450

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October

2000. http://www.w3.org/TR/REC-xml.

Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001.

http://www.w3.org/TR/wsdl.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

4.106.4 Interaction Diagram 455

Image

Display

Display Study

Images

Image

Display

Invoker

Request Display of

Study Images

4.106.4.1 Request Display of Study Images Message

4.106.4.1.1 Trigger Events

The following event will trigger a Request Display of Study Images – Patient-based:

• User of the Image Display Invoker needs to review imaging studies for a specific patient 460

(optionally in a specific date range).

The following event will trigger a Request Display of Study Images – Study-based:

• User of the Image Display Invoker needs to review specific imaging studies, using

identifiers of the study as keys.

4.106.4.1.2 Message Semantics 465

These messages are implemented as an HTTP request and response.

The Image Display Invoker shall support both Patient-based and Study-based requests.

Table 4.106.4.1.2-1 specifies the HTTP request parameters for the patient-based request.

Table 4.106.4.1.2-2 specifies the HTTP request parameters for the study-based request.

470

The Image Display shall support all parameters, including those that are optional, except that the

viewerType may not be recognized. The Image Display shall return at least all exact matches to

the query parameters sent by the Image Display Invoker; IHE does not further specify matching

requirements.

All parameter names and values are case-sensitive (except for patientName values). 475

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Table 4.106.4.1.2-1: HTTP Request Parameters – Patient-based

Parameter

Name

REQ Description Notes

requestType

Specifies what type of information

shall be provided.

Shall have the value PATIENT

patientID R Identifies the subject of the studies

being requested. Its value shall

include identification of assigning

authority.

Shall be formatted as HL7

®2

CX data type

according to the requirements specified for the

Patient Identity Feed transaction (see ITI TF-

2a: 3.8.4.1.2.3)

patientName

Assists in the identification of the

subject of the studies being

requested, in case the patientID is

unrecognized.

Shall be encoded in the DICOM PN format.

patientBirthDate

Assists in the identification of the

subject of the studies being

requested, in case the patientID is

unrecognized

Shall be encoded in the XML primitive

dateTime format.

lowerDateTime O Used to constrain the earliest study

date/time.

Shall be encoded in the XML primitive

dateTime format.

upperDateTime

Used to constrain the latest study

date/time.

Shall be encoded in the XML primitive

dateTime format.

mostRecentResults O The number of most recent studies

to be included into the response.

Omitting this parameter means the server will

decide how many or how few results to return.

modalitiesInStudy O This attribute identifies one or

more modalities being requested,

by comma-delimited DICOM

Modality values.

Selects any study that contains a series with

any one of the specified modality values

viewerType O The type or name or family of

viewer requested

The value of viewerType may be

implementation defined or a well-known

value; see Section 4.106.4.2.2.1

diagnosticQuality O The quality of display requested. Value of "true" indicates that diagnostic

quality is requested; value of "false" indicates

that diagnostic quality is not requested; see

Section: 4.106.2.2.2

keyImagesOnly O Whether or not only key images

are displayed

Value of "true" indicates that only key images

are requested; value of "false" indicates that a

complete set of images is requested; see

Section 4.106.4.2.2.3

Notes: 1. The patientID, lowerDateTime, upperDateTime, and mostRecentResults parameters are identical to those of

the Retrieve Specific Information for Display [ITI-11] SUMMARY request.

480

2. If subcomponents of the CX data type are used for the patientID (such as in the Assigning Authority

component), the HL7 subcomponent delimiter ‘&’ must be escaped to ‘%26’, as & is the delimiter for the HTTP

parameters.

HL7 is the registered trademark of Health Level Seven International.

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

Table 4.106.4.1.2-2: HTTP Request Parameters – Study-based 485

Parameter

Name

REQ Description Notes

requestType

Specifies what type of information

shall be provided.

Shall have the value STUDY

studyUID C Identifies one or more DICOM

studies being requested

Shall contain a comma-delimited list of Study

Instance UID values.

Required if accessionNumber is not present.

Shall not be present otherwise.

accessionNumber

Identifies one or more DICOM

studies being requested.

Shall contain a comma-delimited list of

Accession Number values.

Required if studyUID is not present. Shall not

be present otherwise.

viewerType

The type or name or family of

viewer requested

The value of viewerType may be

implementation defined or a well-known

value; see Section.4.106.4.2.2.1

diagnosticQuality O The quality of display requested. Value of "true" indicates that diagnostic

quality is requested; value of "false" indicates

that diagnostic quality is not requested; see

Section 4.106.4.2.2.2

keyImagesOnly O Whether or not only key images are

displayed

Value of "true" indicates that only key images

are requested; value of "false" indicates that a

complete set of images is requested; see

Section 4.106.4.2.2.3

Formal definition of the HTTP Request in WSDL and in WADL is provided on the IHE FTP

site: ftp://ftp.ihe.net/TF_Implementation_Material/Rad/.

The only binding required for both the Image Display Invoker and Image Display is the binding

to the HTTP-GET. In this binding, messages are formatted as in the following examples, in 490

which the normative components are indicated in bold, the deployment-specific components are

in normal text, and the instance-specific parameter values are in italics:

http://<location>/IHEInvokeImageDisplay?requestType=PATIENT&patientID=99998410^^

^AcmeHospital&mostRecentResults=1

http://<location>/IHEInvokeImageDisplay?requestType=STUDY&studyUID=1.2.840.11388

495

3.19.110.4,1.2.840.113883.19.110.5&viewerType=IHE_BIR&diagnosticQuality=true

The <location> part of the URL is configurable by the implementation, and must contain the host

name, an optional port address, and may be followed by an optional path. The path, if present,

may not contain a ‘?’ character. The remainder of the URL, including IHEInvokeImageDisplay

and the following request parameters, are specified by the message semantics and may not be 500

changed. See the discussion about <location> in ITI TF-2a: 3.11.4.1.2.

The Image Display Invoker may perform the request utilizing the HTTPS protocol.

Image Display Invoker Actors can expect to receive an error response, or the data requested, or a

request to look elsewhere for the data. An Image Display Invoker must follow redirects

(responses with values of 301, 302, 303 or 307), but if a loop is detected, it may report an error. 505

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

4.106.4.1.3 Expected Actions

The Image Display shall support the HTTPS protocol.

The Image Display shall return an HTTP response.

The Image Display shall return HTTP response code 404 (Not Found) if it cannot locate the

requested identifiers, or if no studies meet the parameters, or the studies contain no images. 510

The Image Display may return HTTP redirect responses (responses with values of 301, 302, 303

or 307) in response to a request.

If there are no errors, the contents of the DICOM Study or Studies matching the request

parameters shall be displayed by the Image Display, as specified in Section 4.106.4.2. If there are

errors, any previously displayed images of a different Patient or Study shall be closed, to prevent 515

incorrect interpretation.

The Image Display shall provide a mechanism to handle the case where multiple studies satisfy

the request parameters. For example, this might involve letting the user select from the set of

matching studies, or providing side-by-side display for comparison, or providing sequential

display of the matching studies. 520

4.106.4.2 Display Study Images

The Image Display displays the contents of the requested studies.

4.106.4.2.1 Trigger Events

The Request Display of Study Images message initiates this action by the Image Display.

4.106.4.2.2 Message Semantics 525

4.106.4.2.2.1 Viewer Type

A parameter in the request specifies whether a particular type of viewer is requested.

The Image Display is not required to support this parameter, but may do so if it is able to provide

different types of viewer. If the value of the parameter is not recognized by the Image Display, it

shall ignore it and use any viewer it wants and not return an error. 530

The value of viewerType may be implementation defined or a well-known value.

Well-known viewer types are defined in Table 4.106.4.2.2.1-1.

Table 4.106.4.2.2.1-1: Well-Known Values for Viewer Type Parameter

Parameter Value Description Notes

IHE_BIR Viewers compliant with the IHE Basic Image Review (BIR) Profile.

535

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

4.106.4.2.2.2 Diagnostic Quality

A parameter in the request specifies whether or not diagnostic quality is requested.

Diagnostic quality is display of a complete set of images with the quality required to make a

diagnosis or clinical decision.

The Image Display shall be able to provide diagnostic quality, assuming that the display 540

hardware and viewing environment are appropriate.

When diagnostic quality is not requested, a lower quality display may be provided, sufficient for

review, for the purpose of providing sufficient quality but faster, if it is necessary to sacrifice

quality for adequate interactive performance.

The Image Display shall be able to provide review quality. 545

Factors that affect quality include the capabilities of the viewer, and whether or not irreversible

compression, spatial or contrast down-sampling or other forms of image processing have been

applied.

It is beyond the scope of this transaction to specify more detail, but regulatory authorities hold

manufacturers to standards of performance according to a claim of diagnostic quality in the 550

labeling of the device. The intent is that when the user requires and requests diagnostic quality,

the quality should not be limited by the software, storage or transmission mechanisms used by

the Image Display.

If the parameter is not supplied, the default shall be review quality.

4.106.4.2.2.3 Key Images Only 555

A parameter in the request specifies whether or not only key images are requested.

Key images in this context are those that have been designated within the information about the

Study that is available to the Image Display as being key from the perspective of being relevant

clinically. The radiologist may have designated them during authoring of the report, or at some

other time. The designation of key images in the Image Display may use the Key Image Note 560

Profile, or may use the DICOM Key Object Selection SOP Class, or some other mechanism.

If key images only are requested (the parameter has a value of true), the Image Display shall

initially display only those images. It may provide a means of navigation to other images

subsequently.

If key images only are not requested (the parameter is absent or has a value of false), or if there 565

are no key images specified for a study, then the complete set of images shall be displayed.

4.106.4.2.3 Expected Actions

The Image Display shall display all requested DICOM objects for which it claims compliance in

any IHE Content or Workflow profile or DICOM Conformance Statement. This includes images

(single frame and multi-frame), DICOM SR (including Evidence Documents and Key Image 570

Notes), and Presentation State objects with their referenced images. All supported DICOM

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

information objects included in the selected studies shall be displayable, except images identified

as “for processing”, raw data instances, and instances of private SOP Classes. It is permissible to

display “for processing”, raw data instances, and instances of private SOP Classes. There are no

specific requirements placed on the manner in which non-image objects are displayed. 575

Note: Grouping with other profiles, such as CPI, SINR, and KIN, may require more specific behavior for non-image

objects.

The required behavior for display of images is specified in the Retrieve Images transaction View

Images Behavior section (RAD TF-2: 4.16.4.2); any additional behavior defined by other

profiles claimed in conjunction with this transaction (such as the Mammography Image Profile) 580

is defined therein.

The Image Display shall provide interactive viewing. Interactive viewing in the context of this

transaction is defined to be the ability to navigate within the requested studies (including change

studies, series, and scroll between images and frames), and manipulate the appearance of the

displayed image (window, zoom and pan). 585

Note: A more complete definition of interactive viewing capability in other contexts is provided in the Basic Image

Review (BIR) Profile, but support of the BIR Profile is NOT a baseline requirement of the Image Display in this

transaction, though it may be requested using the optional viewerType parameter.

Display may be (but is not required to be) in the form of a web-based client interaction to one or

more windows opened, or already open, on the Image Display Invoker. Any necessary plug-ins 590

shall be automatically downloaded from the Image Display, if not already installed on the Image

Display Invoker client.

There is no requirement that the image be displayed on the same device hardware as the Image

Display Invoker is running on.

The specific viewer technology used is outside the scope of this transaction, but the IHE 595

Integration Statement for the Image Display and the Image Display Invoker shall include a link

to documentation describing the technology required.

Note: The area of web interaction technologies is rapidly evolving, and the producers of Image Display products with

web interfaces are very cognizant of the need to display properly on the variety of platforms that are used for

EHR systems. The IHE Cardiology and Radiology Technical Committees have decided that over-specification of

600

this interaction would be counter-productive to innovation in implementation of effective user interfaces. This

transaction therefore specifies only the initial HTTP invocation, and the functional requirement for display of all

study information objects. During Trial Implementation, the committee will monitor whether this approach is

achieving the requisite level of interoperability.

As an example, the provider of the interactive display may provide an HTML page that does whatever is

605

necessary, including, but not limited to, such methods as:

• HTML5/Canvas zero footprint viewer

• traditional HTML +/- JavaScript JPEG/PNG viewer or plugin (Flash, Silverlight) embedded (in-browser)

viewer

• Java WebStart or ActiveX viewer

610

• triggers proprietary installed plugin to feed or launch local viewer application

IHE Radiology Technical Framework Supplement – Invoke Image Display (IID)

______________________________________________________________________________

__________________________________________________________________________

Template Rev. 10.3

4.106.5 Security Considerations

User access control is managed outside of the specification of this transaction. This transaction

makes few assumptions about the security environment (see RAD TF-1: 35.5 - IID Security

Considerations). 615

4.106.5.1 Security Audit Considerations

The Image Display may record in an audit log the requesting client network address and the

identifiers of the patient and studies displayed, together with any additional information (such as

authenticated user identity).

The Radiology Audit Trail Option in the IHE ITI Audit Trail and Node Authentication Profile 620

(ITI TF-1:9) defines audit requirements for IHE Radiology transactions. See RAD TF-3:5.

Editor: Add the following row to RAD TF-3: Table 5.1-2

Table 5.1-2: IHE Radiology transactions and resulting ATNA trigger events 625

IHE Radiology

Transaction

ATNA Trigger Event(s) Actor(s) that shall be able to record audit

event

Patient Registration [RAD-1] Patient-record-event ADT

Order Placer, DSS/OF – when PHI is presented

…

Invoke Image Display [RAD-

106]

Study-used Image Display Invoker

Image Display