WEB PACS with JPIP

 

 

WEB PACS with JPIP

[e-mail]

 

SCOPE

 

This article will provide a general description of new technology about WEB PACS finalized in DICOM (2008)

 

Symbols and abbreviated terms

 

WADO     Web Access to DICOM persistent Objects

JPIP          JPEG 2000 Interactive Protocol

 

3rd Party Library

1.      zlib to support deflate transfer syntax (Dataset encode/decode) www.zlib.net

2.      JPIP, JP2K lib   www.leadtools.com www.ware.com www.kakadusoftware.com

3.      DCMTK dicom.offis.de/dcmtk.php.en

 

DICOM standard refer

1.      Part 3.18 (DICOM 2008)

2.      CP106 (DICOM 2008)

 

Questions

 

1.      How to get the available record set (study, series, image)

2.      How to retrieve the DICOM image

3.      How to render the DICOM image

4.      How to get the structure report

5.      How to retrieve the annotation

6.      How to retrieve the overlay and render

7.      How to work with the JPG2K streaming technology

8.      How to process (measure, adjust W/L …) the DICOM image from web server?

 

 

Available solutions

 

1.      How to get the available record set (study, series, image)

 access the database and get the recordset

2.      How to retrieve the DICOM image

[Copy from 3.18]

Annex B - Examples (Informative)

B.1 RETRIEVING A SIMPLE DICOM IMAGE IN JPEG

http://www.hospital-stmarco/radiology/wado.php?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

 

[Only the pixel coded with JPEG will be retrieved base on http]

 

B.3 RETRIEVING A REGION OF A DICOM IMAGE

Retrieving a region of a DICOM image, converted if possible in JPEG2000, with annotations burned into

the image containing the patient name and technical information, and mapped into a defined image size:

https://aspradio/imageaccess.js?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5

&annotation=patient,technique

&columns=400

&rows=300

&region=0.3,0.4,0.5,0.5

&windowCenter=-1000

&windowWidth=2500

 

[part of the pixel coded by JPEG2000 will be retrieved and it need to be decoded explicitly before rendering]

B.4 RETRIEVING AS A DICOM MIME TYPE

Retrieving a DICOM image object using the baseline 8-bit lossy JPEG transfer syntax, and de-identified:

http://www.medical-webservice.st/RetrieveDocument?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&contentType=application%2Fdicom

&anonymize=yes

&transferSyntax=1.2.840.10008.1.2.4.50

[JPEG coded image can be rendered directly without explicitly decode since it is a MINE type support by IE]

 

 

3.      How to render the DICOM image

To different transfer syntax DICOM file, different decoder required here to decode the file.

To Deflate (.99), zip(zlib) will be used to decode the whole dataset before parsing the pixel data.

To JPIP (.94),   (0028, 7fe0) pixel data provider URL should be parsed correctly and retrieve the JP2 image (standalone image file) from the URL and decode/render the pixel.

 

To Deflate JPIP (.95), similar to .99, decode by zlib firstly and then refer to .94 to render the pixel.

 

To JPEG2000 Lossless (.90), download the whole file and decode/render it. (DCMTK is free, but the jpeg2000 lib is not free)

 

To JPEG Lossless (.70), download the whole file and render without explicitly decoding.

 

 

 

4.      How to get the structure report

 

B.2 RETRIEVING A DICOM SR IN HTML

http://server234/script678.asp?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&charset=UTF-8

 

[HTML format SR will be generated]

In some cases, the transfer syntax of the SR may be deflated "1.2.840.10008.1.2.1.99", the dicom file need to decoded in client side before rendering it into html.

 

5.      How to retrieve the annotation

It’s better to burn it into the pixel data in server side before send to client.

 

6.      How to retrieve the overlay and render

 

Burn it into pixel data in server side or parse it from DICOM file and render it in client side.

 

7.      How to work with the JPG2K streaming technology

Buy the encode/decode JPIP lib from 3^rd party (Ware, Kakadu, Leadtools) or implemented your own JPIP stack.

 

Retrieve the raw DICOM files and process them into JPIP content scheduledly or encode on demand when the request comes.

 

Receive and decode the content in client server and render. After the image has been retrieved completely, save the image in client side temperately for post processing.

 

8.      How to process (measure, zoom, adjust W/L …) the DICOM image from web server?

Zoom out can be processed separately since it related with JPIP, some work can be processed in server side to decrease the network IO.

 

Other works should be processed in client side, an ActiveX or similar program need to execute in client side to manipulate the DICOM file in the client cache.

  Appendix

[Copy from IHE IT Framework v3]

4.55 WADO Retrieve

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

RAD-55 is used by the Imaging Document Consumer and the Image Manager/ Image Archive

actors.

4.55.1 Scope

The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM

SOP Instances with a web-based service through HTTP/HTTPS protocol.

4.55.2 Use Case Roles

WADO Retrieve

Imaging

Document

Consumer

Imaging Document

Source

Actor: Imaging Document Consumer

Role: Issues an HTTP Get Request to access a DICOM instance.

Actor: Imaging Document Source

Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP

response with the appropriate content.

4.55.3 Referenced Standard

DICOM 2007 PS 3.18: Web Access to DICOM Persistent Objects (WADO)

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30

IHE Technical Framework, vol. III: Transactions (continued)

______________________________________________________________________________

__________________________________________________________________________

135

4.55.4 Interaction Diagram

Imaging Document

Consumer

Object(s) request

(GET HTTP Request)

Imaging

Document Source

Object(s) send

(HTTP Response to the GET Request)

4.55.4.1 WADO Retrieve

The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instance

from the Imaging Document Source. The Imaging Document Source receives the request,

generates the response with the appropriate content and sends an HTTP Response to the Imaging

Document Consumer.

4.55.4.1.1 Trigger Events

The Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within

a DICOM Manifest.

4.55.4.1.2 Message Semantics

The message semantics are defined by the DICOM Web Access to DICOM Persistent Objects

(WADO), PS 3.18.

The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a

HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document

Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM

instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance

UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the host

information (e.g., web server location, and script language) of the web server to perform this

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30

IHE Technical Framework, vol. III: Transactions (continued)

______________________________________________________________________________

__________________________________________________________________________

136

transaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOP

Instance to the web server host information based on its local configuration (see Appendix G).

In addition, the Imaging Document Consumer shall support the following fields in the HTTP

request:

Table 4.55-1. WADO HTTP Request Fields

HTTP Field REQ Description Values

Accept R This field is used to specify MIME

types which are acceptable for the

response

At least one of the following values:

application/dicom

image/jpeg

application/text

application/html

*/*

Other values may be included as

well

Accept-

Language

O This field specifies the language of

the object to be retrieved.

Any valid value according to

RFC2616

The Imaging Document Source shall list all media types it supports in the Accept field of the

HTTP request, and shall use WADO HTTP parameter contentType to request the desired media

type of the object to be retrieved in the HTTP response (see Table 4.55-2).

The Imaging Document Source and the Imaging Document Consumer are required to support a

number of parameters in the WADO HTTP Request-URI, as described in the following table.

Table 4.55-2. WADO HTTP Request Parameters

Parameter Name Parameter Description Requirement

Imaging

Document

Source

Imaging

Document

Consumer

Note

requestType Type of the HTTP request

performed. It must be “WADO”

R R

studyUID Unique identifier of the study R R

seriesUID Unique identifier of the series R R

objectUID Unique identifier of the object R R

contentType MIME type of the pesponse R+ R+ IHE-1

IHE-2

charset Charset of the response O O

anonymize Anonymize object O O

annotation Annotation of the object O O IHE-3

rows Number of pixel rows O O IHE-3

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30

IHE Technical Framework, vol. III: Transactions (continued)

______________________________________________________________________________

__________________________________________________________________________

137

Parameter Name Parameter Description Requirement

Imaging

Document

Source

Note

Imaging

Document

Consumer

columns Number of pixel columns O O IHE-3

region Region of image O O IHE-3

windowCenter Window center of the image O O IHE-3

windowWidth Window width of the image O O IHE-3

frameNumber Frame number of the single frame

in a multi-frame image

O O IHE-3

imageQuality Image quality factor O O IHE-3

presentationUID Unique identifier of the

presentation object

O O IHE-3

presentationSeriesUID Uniquer identifier of the series

containing the presentation object

O O IHE-3

transferSyntax Transfer syntax UID used with

DICOM image object returned in

the response

O O IHE-3

IHE-1: The Imaging Document Consumer must use the value “application/dicom” to

retrieve a DICOM SOP Instance in the DICOM Part 10 File Format. This allows the

Imaging Document Consumer to receive a SOP Instance in the native DICOM

format for full data manipulation.

The Imaging Document Consumer can also use the value “application/jpeg” to

retrieve an image encoded in JPEG baseline format if it is a single frame DICOM

image object or a single frame image encoded in a multi-frame DICOM image

object.

The Imaging Document Consumer can also use the values “application/text” or

“application/html” to retrieve a DICOM SR object represented in the text or html

format.

The Imaging Document Consumer can also use other values for this parameter as

specified in DICOM PS 3.18, if they are supported by the Imaging Document

Source.

This parameter is optional in DICOM PS 3.18. Because the default format of the

DICOM persistent object returned in the HTTP Get response in the absence of a

value in this parameter varies depending on the SOP Class of the retrieved object,

this profile requires that the parameter is supported, to improve interoperability.

IHE-2: This parameter must be compatible to the value(s) that the Imaging Document

Consumer placed in the Accept field of the HTTP Request-URI.

IHE-3: The parameter applies only to a DICOM SOP Instance if it is an image object.

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30

IHE Technical Framework, vol. III: Transactions (continued)

______________________________________________________________________________

__________________________________________________________________________

138

4.55.4.1.2.1 Example of WADO Request-URI

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

using WADO:

http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.

40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&

objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&contentType=application

%2Fdicom

This example uses reponse MIME type application/dicom to request the DICOM SOP Instance

returned in the native DICOM Part 10 file format.

4.55.4.1.3 Expected Actions

Upon reception of the WADO HTTP Request, the Imaging Document Source shall parse the

request and if there are no errors, shall construct an HTTP Get Response with the requested

DICOM instance content and return the response as specified by the DICOM WADO standard,

with HTTP response code 200 (OK).

The Imaging Document Source shall return HTTP response code 406 (Not Acceptable), if it

cannot serve the requested response MIME type(s) in parameter contentType and/or Accept

Field.

The Imaging Document Source shall return HTTP response code 404 (Not Found) if it cannot

locate the requested DICOM SOP Instance or cannot recognize the UID values specified in the

received HTTP Request-URI.

The Imaging Document Source shall return HTTP response code 400 (Bad Request) if any

required HTTP field or required WADO HTTP parameters are missing in the received HTTP

Request-URI, or any other syntactic error is detected in the HTTP Request-URI (e.g., media type

in contentType parameter conflicts with media types in Accept field).

4.55.4.1.4 Audit Trail Trigger Events

IHE specifies a number of events that shall be reportable by means of the IHE Audit Trail (ITI

TF-II 3.20). IHE Radiology Audit Trial Option further defines a subset of these events, which are

particularly applicable to the radiology transactions.

Table 4.55-3 lists all the radiology audit trial trigger events applied to transaction RAD-55. The

last column specifies whether the sender or receiver side of the transaction is required to audit

the event.

Table 4.55-3. Audit Record Trigger Events

IHE Radiology Transaction ATNA Trigger Event(s) Audit Recording Requirements

WADO Retrieve [55] Instance-Stored Imaging Document Source shall

audit

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30

IHE Technical Framework, vol. III: Transactions (continued)

______________________________________________________________________________

__________________________________________________________________________

139

IHE Radiology Transaction ATNA Trigger Event(s) Audit Recording Requirements

Study Used Imaging Document Consumer shall

audit

Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA

2007-08-30