1 / 19

Enhanced URI Interface for DICOM Metadata Retrieval

This document provides an overview and discusses open issues related to the Enhanced URI Interface for retrieving DICOM metadata using HTTP requests and responses.

eholcomb
Download Presentation

Enhanced URI Interface for DICOM Metadata Retrieval

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WADO Enhanced URI Work Item timothy.culp@harris.com DICOM WG-27 RSNA November 2011

  2. Agenda • Overview • Open Issues • Enhanced URI Request/Response   • Questions/Comments

  3. Overview • Explain to everyone what we’ve done to get here…

  4. Open Issues • Normalized Metadata • Currently metadata will be returned using the same schema as WADO Web Services defined in PS3.19. • It would be more efficient to return metadata in a normalized form when requesting it at the study or series level. • WG-06 is submitting a multiframe work item that will address the normalization of metadata across a series or study. • This supplement will inherit those changes when they become available.

  5. Open Issues (cont) • Returning a list of SOP Instances • Is there a standard way to represent a list in a URL? • For returning a list of SOP Instances, are we going to concatenate the list of UIDs into the URL? • Are there limitations on the the length of a URL? • The URL could not be generated by hand but the intention for this interface is for enabling machine to machine transfers of data, not human to browser display. • For purposes of this design, we suggest the following: • To return a single instance (GET): • /studies/{studyid}/series/{seriesid}/instances/{uid} • To return a set of instances from a series (GET or POST): • /studies/{studyid}/series/{seriesid}/instances{?uid1,uid2,uid3}

  6. Open Issues (cont) • HTTP Accept Headers • When requesting a study, series, or instances through the Enhanced URI Interface, the data can be returned as DICOM objects or zip file containing XML and/or binary. • The format of the request is indicated in the HTTP Accept Header. • The accept header will specify application/dicom for the former and application/wado for the latter.

  7. Open Issues (cont) • Transfer Syntax • Transfer syntax can also be part of the content negotiation since it is requesting the same information in another format. • The response shall be the Transfer Syntax requested if possible. If it is not possible for the response to be sent using the requested transfer syntax then the Explicit VR Little Endian Uncompressed Transfer Syntax shall be used. • There are probably two main uses cases that account for 95% of user requests: • User wants data returned in the format in it’s native format • User wants the data uncompressed because they do not have the necessary codecs to decompress

  8. Open Issues (cont) • Private metadata • If we use the metadata schema as defined in PS3.19, is there a mechanism for including private XML tags without making a change to the schema? • How are new tags incorporated within this schema – does it affect the XSD?

  9. Open Issues (cont) • Metadata Info vsXpath • Is there a use case for Study Metadata Info? • The original use case was to be able to get high level summary of studies on a server for sorting/filtering/searching/indexing without having to download and parse all of the metadata. • XPath filtering would provide the same information, although it puts more burden on the end user to formulate the query and more burden on the server to return the result. • It also prevents the study info from getting cached. However, XPath is more flexible than “info” because users can select the information that’s important to them. • Since the use case we identified is more a function of “searching” versus “transporting” DICOM, our suggestion is to drop the info resource and leave it up to the QIDO search engine.

  10. Open Issues (cont) • Parameters vs resource • Most proxy servers do not cache URL’s with a ? in the URL (browsers do but that isn’t our target client). We want to support greater caching capability to a larger audience (proxy servers as well as browsers). This supports greater caching capability for all base URL resources which point to static resources where parameter notation is better for user specific requests. • Our recommendation is static content should be in the base URL, and any custom request such as a region of an image, etc should and could be URL params and those should be not expected to be cached. • An important caching use case is reverse proxies at edges, where the same study is likely to be looked at by multiple people, e.g. techs, rads, referrings. • For a good discussion on best practices for caching, see http://code.google.com/speed/page-speed/docs/caching.html.

  11. Enhanced URI Request/Response • The DICOMWADO Enhanced URI Interface defines several resources. An implementation shall support at least one of these endpoints. The endpoints are: • RetrieveStudy - This resource retrieves the full set of DICOM instances related to the study returned in a multipart mime response • RetrieveSeries - This resource retrieves a series as a set of DICOM objects returned in a multipart mime response • RetrieveInstance - This resource retrieves a range of SOP Instances as a set of DICOM objects returned in a multipart mime response • RetrieveMetadata - This action retrieves the study level metadata or a subset as defined by an XPath filter. • All XML responses shall be encoded as described in the Native DICOM Model defined in PS3.19. • By default, DICOM objects returned shall be encoded in Explicit VR Little Endian (see 8.2.11 for more information on Transfer Syntax UID).

  12. RetrieveStudy • Request • Resource • {SERVER_ROOT}/studies/{StudyInstanceUID} • SERVER_ROOT is the base url for the web servers WADO URI service. This may be a combination of host, port, and protocol(http or https) • {StudyInstanceUID} is the unique StudyInstanceUID for a single study. • Method • GET • Accept • application/dicom • Specifies to the URI service the response should be in DICOM object format. • application/wado • Specifies to the URI service the response should be zip file including study level metadata as XML and bulk data as binary format.

  13. RetrieveStudy • Response • The response format can depend on the Accept header the request specified. The two possible response formats are application/dicom and application/wado. Both response formats have a content type of multipart/x-mixed-replace with a boundary separation of “BinaryItemBoundary-7afb50349c2148c3a5d6a324891a481c” • Type: application/dicom (Content-Type: multipart/x-mixed-replace) • Each binary item in the multipart response represents a DICOM SOP instance object. The entire multipart response contains every instance for the study specified. • Type: application/wado (Content-Type: multipart/x-mixed-replace) • The first item in the response is study level metadata. Each following binary item is the binary data portion of a SOP instance.

  14. RetrieveSeries • Request

  15. RetrieveSeries • Response

  16. RetrieveInstance • Request

  17. RetrieveInstance • Response

  18. RetrieveMetadata • Request

  19. RetrieveMetadata • Response

More Related