Retrieve preformatted images over web services - Detailed Proposal - 2012-2013

1. Proposed Workitem: Retrieve preformatted images over web services

• Proposal Editor: Mark Sinke
• Editor: Chris Lindop
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

Summary

It is impossible to send XUA tokens for a WADO (RAD-55) request, making it impossible to employ effective access control at the Imaging Document Source side. In addition, it is hard to tunnel RAD-55 requests over a standard XCA-I gateway, because WADO does not use web services.

DICOM has defined the RetrieveRenderedImagingDocumentSet transaction, as specified in supplement 148, and folded into the 2011 standard, which exactly fits the purpose.

An additional transaction to retrieve preformatted or rendered images over web services can be added as an option to the XDS-I.b profile to allow secure and scalable exchange.

In projects that involve sharing imaging data, the question of Source side enforcement of access control have been raised. These have not satisfactorily been solved by the existing RAD-55 transaction.

IHE has defined existing RAD-55 and RAD-69 transactions that get one part of the way there. When converting from XDS-I.a to XDS-I.b, we defined every transaction to use web services, but unfortunately left JPEG rendered images out. Adoption of XDS-I has been very successful so far, hence IHE seems to be a good forum for the type of development.

2. The Problem

With the current XDS-I and XDS-I.b infrastructure, it is not possible in a standard way to obtain JPEG-preformatted images using web services. The main things that break interoperability is that to get to preformatted images, one must use WADO (which is a plain HTTP GET).

This has two consequences

• using XUA to convey user identity and other identifying traits is not possible
• routing the request over XCA-I does not work, as XCA-I only supports RAD-69, not WADO

An optimization of the WADO server might also be possible, if we allow multiple preformatted images to be retrieved at once. WADO only allows one retrieval at a time. I consider this a lucky side effect, not a criterion per se.

The value of this profile or supplement would be that we can use the XDS-I.b RAD-69 service or an extension to use to securely access image information within or across affinity domain boundaries. We avoid a proliferation of non-interoperable private extensions to IHE to make the same thing happen.

3. Key Use Case

A mammography screening program results in images being collected. These images are stored and shared within the mammography screening program using XDS(-I). For follow-up in treatment sites it is necessary to gain access to the images taken. Users in the treatment hospitals are used to sharing information in their region, and they need access to the images in the screening domain. The need is even greater if the treatment hospital is not determined upfront (for example, in the Netherlands, where women have the right to choose the actual treatment site).

The current problem is that it is (a) hard to make this work from a system engineering perspective, as the WADO transaction is not profiled for XCA-I use, and (b) that any user identity is lost, as WADO cannot convey it. Hence, in the current situation, the study needs to be transferred on a CD, or by other proprietary electronic means.

In the new situation the user logs in to their XDS-I enabled system and is able to look at a quick preview of the screening images. Under the hood, this transaction is audited, and access control is applied according to the identity of the user established at login.

4. Standards and Systems

• XCA, XCA-I, XDS-I.b have parts of the solution, but the missing piece is retrieval of preformatted images over XCA-I.
• DICOM has performed work in a transaction like RetrieveImagingDocumentSet that allows for preformatted images. I cannot find the right part of DICOM to point to now. It might still

be work in progress.

5. Technical Approach

The current RAD-69 allows for the JPIP transfer syntax, but we see very little uptake of that standard in the field, and the JPIP standard suffers from the same interoperability problems (lack of XUA, no routing over XCA-I), as it is also based on plain HTTP traffic.

The WADO – WS – Retrieve Rendered Imaging Document Set transaction, as defined in the recently updated DICOM WADO specification (through the inclusion of the edits in supplement 148 in Part 18 of the DICOM standard can be used to tackle the problem. In essence, we would profile the same parameters as used in the RAD-55 transaction, but for the web service implementation of the WADO specification.

The problem can be tackled in a fairly straightforward way with existing standards. RAD-69 sets the stage for DICOM transfers over Web Services, and RAD-55 can be used as a template to define the semantics of the transaction.

In a second phase, this transaction can be applied to XCA-I, making it possible to transparently request rendered images over an XCA-I infrastructure.

Existing actors

The Imaging Document Source would be affected mostly, as it should implement another transaction (RetrieveRenderedImagingDocumentSet). The Imaging Document Consumer may choose whether to use the original WADO-based specification or the new RetrieveRenderedImagingDocumentSet transaction. No other actors are affected.

New actors

No new actors are introduced.

Existing transactions

Most likely, this transaction is going to be implemented as a new transaction. No existing transactions are impacted.

New transactions (standards used)

A new transaction to retrieve rendered images over a web services stack would be introduced, profiled based on the standard DICOM WADO RetrieveRenderedImagingDocumentSet transaction. Apart from the transport mechanism, this functions much like the traditional WADO (RAD-55) transaction.

Impact on existing integration profiles

The XDS-I.b integration profile will get an Option "WADO over Web Services" or a similarly named option.

New integration profiles needed

No new profiles are introduced.

Breakdown of tasks that need to be accomplished

The effort for this proposal is relatively minor

• write a little bit of text that would help vol 1 readers understand why the option for web services exists
• augment vol 2 with a new transaction, using RAD-55 as a template for semantics, and RAD-69 as a template for the transport protocol
• review any design choices made during the vol 2 work
• do the usual editiorial work to introduce the vol 1/2 option, and to add the new transaction

6. Support & Resources

No explicit support groups have been identified. I know of customer installations, where the lack of security in the WADO protocol and/or the inability to use WADO effectively over XCA are expressed as a concern, but the people managing those sites are not of the required skill level to write a supplement.

7. Risks

The major implementation risk I see, is that we introduce yet another way to get to imaging data. From an XDS-I Source implementer perspective however, that should not really be a big problem, since the transaction proposed is very much modeled like the RAD-69 and RAD-55 transaction that are already mandatory. The consumer can choose to ignore the transaction, if they wish so.

A deployment risk is that, to make effective use of the transaction, we need to have consumers implement it. If there are none (which is possible, since the transaction is optional), we may not have achieved our goal of increased security and interoperability over XCA.

8. Open Issues

We need a discussion on the optionality of the transaction (see risks), but otherwise I don't think there are any open issues.

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 30% given the need to incorporate XCA-I and consider appropriate packaging (new Profile?)

Responses to Issues:

• WADO-RS is out of scope for this profile

Candidate Editor:

Chris Lindop