Project

General

Profile

DICOM ยป

Application Hosting

Here are some notes about the upcoming Application Hosting services which basically defines an interface between an application and an image processing plugin. This information was mainly written having the CTK project in mind.

Current Status

At the time of writing, the extension (in DICOM called "Supplement") for Application Hosting (Supplement 118) was in status letter ballot. The Supplement text in the latest letter ballot version can be downloaded from the NEMA server (ftp). In DICOM 2011 the extension is already part of the DICOM standard. Note that there may be slight changes in the final specification compared to the letter ballot version.

Idea

The idea behind Application Hosting is to have a standardized interface to exchange information typically found in DICOM objects, e. g. images. This is done by defining a plugin mechanism. In Application Hosting, an application ("Hosting System") can utilize a plugin ("Hosted Application") by communication with it through a well-specified interface. One example would be a third party segmentation plugin that is instantiated by an application and then is feeded with the image-related data. The plugin may ask for further input information on the screen, then performs the segmentation and finally returns the results to the application.

An important technical aspect is that the underlying interface between Hosting System and Hosted Application does neither rely on DICOM network services nor does (by force) require any DICOM parsing capabilities. This is achieved by offering Web Services for transport, additionally to exchange of DICOM object information over DICOM files. Also, bulk data can be handed over by referring to files.

Interfaces

The interface includes lifecycle management (initialize, terminate, ...) and data exchange management (passing data to the plugin, query status, communicate results). From the conceptual point of view, there are three interfaces:

  1. Application Interface: Offered by Hosted Application (=plugin) to control it.
  2. Host Interface: Offered by Hosting System and utilized by plugin, e.g. to ask for ressources (disk space,...) or for communicating status change.
  3. Data Exchange Interface: Offered by both (Hosting System and Hosted Application) parties and can be used to exchange processing data between them. Thus, it offers calls like notifyDataAvailable() or getData().

All interfaces are based on WSDL descriptions. 1) and 2) are fairly simple. The third, Data Exchange, is a bit more sophisticated since it permits different ways to transfer meta information and bulk (pixel) data.

Data Exchange Interface

Data can be exchanged either by DICOM files or by a model-based mechanism that is based on XML Infosets. The second may be especially interesting for implementors that are not that common with DICOM parsing. Since the file method should be self-explanatory, I will only give a few words about the model-based one.

I am not an expert in XML technologies (DICOM is a binary hell;) If you are, skip this paragraph. XML Infosets were new to me. Basically, an XML infoset, as I understand it, is a bunch of information that could be represented by an XML file. However, that does not mean that an XML Infoset actually is somewhere stored (disk, memory, somewhere) but it means that you can query it as if it would be. For that query, XPath is used which gives the ability to use existing tools. So, an XML Infoset (and you may know better than I do) is just something like an XML file abstraction.

Actually, the Application Hosting's Data Exchange interface for communication between Hosted and Hosting Application offers two different so-called Models (maybe extended in the future). One is the "Native DICOM Model" and the other is the "Abstract Multi-Dimensional Image Model". The first one defines a representation of binary-encoded DICOM objects as XML Infosets that allows a recipient of data to navigate through a binary DICOM data set using XML-based tools (say: via XPath queries) instead of relying on toolkits that understand the binary encoding of DICOM. Every attribute of an original DICOM object is just turned into a counterpart in an XML infoset which can be accessed by XPath queries. Every XML Infoset (DICOM) attribute includes information like tag, data type, and so on. The value is transferred as a string. Since this is very inefficient for bulk data (like the DICOM attribute Pixel Data carrying the actual pixels of an image), a bulk data file link (URI) can be given instead.

The second model (the "abstract" one) is not directly derived and an underlying DICOM file structure but permits to make multi-dimensional (image) data queryable. This model does not include patient information and so on but concentrates on pixel data and describing information (spatial relationships between the different pixel data dimensions provided, or any other dependencies). Usage examples given in the supplement include 3D Grayscale Volumes or a 3D MR Metabolite Map with multiple components.

Bulk data cannot be exchanged via sharing pointers to common areas in memory. However, implementations might use file memory mapping on both sides to reach performance which is very near to the direct reading from memory. A typical bulk data exchange over such memory sharing file handles could be exist of the following steps (thanks to Larry Tarbox for clarification and example):

  1. source creates a temporary file large enough to hold the data (one can use a 'delete on close' temporary file for better efficiency)
  2. source memory-maps that file as a writable memory area
  3. source fills in the data
  4. source passes the URL of the temporary file to the recipient
  5. recipient memory-maps the temporary file read-only (or copy-on-write if desired)
  6. when the recipient is finished with the file, it ends the memory-mapping, closing the file, and releasing the data pointer with the App. Hosting interfaces
  7. when the source receives the data release, it closes the file
  8. when all open file handles are closed, the operating system deletes the temporary file

Plugin Implementation Requirements

To implement Application Hosting related plugins the following is needed:

  • Implement Application Interface as a server: Web-Service-based interface consisting of the following functions:
    1. getState() : State
    2. setState(newState : State) : boolean
    3. bringToFront(requestedScreenArea : Rectangle) : boolean
  • Implement Host Interface as a client: Web-Service-based interface consisting of the following functions:
    1. generateUID() : UID
    2. getAvailableScreen(appPreferredScreen : Rectangle) : Rectangle
    3. getOutputLocation(preferredProtocols: ArrayOfString) : String
    4. notifyStateChanged(state : State) : void
    5. notifyStatus(status : Status) : void
  • Implement Data Exchange Interface as client and server: Web-Service-based interface consisting of the following functions. Not all functions must be supported, the supplement states: "Hosted Applications shall support at least one of the file-based or model-based interfaces, as either a data source or as a data recipient, as needed by the Hosted Application. If a Hosted Application supports the model-based interfaces, it shall support at least one of the models defined in Annex A of the Supplement. Hosted Applications may choose to implement only those portions of those interfaces that the Hosted Application actually uses; however, all interface methods that a Hosting System might call must be available for the Hosting System to call, even if the Hosted Application does not do anything but return appropriately."
    1. notifyDataAvailable(data : AvailableData, lastData : boolean) : boolean
    2. getData(objectUUIDs : ArrayOfUUID, acceptableTransferSyntaxUIDs : ArrayOfUID, includeBulkData : boolean) : ArrayOfObjectLocator
    3. getAsModels(objectUUIDs : ArrayOfUUID, classUID : UID, supportedInfosetTypes : ArrayOfMimeType) : ModelSetDescriptor
    4. queryModel(models : ArrayOfUUID, xpaths : ArrayOfString) : ArrayOfQueryResult
    5. queryInfoset(models : ArrayOfUUID, xpaths : ArrayOfString) : ArrayOfQueryResultInfoset
    6. releaseData(objectUUIDs : ArrayOfUUID): void
    7. releaseModels(objectUUIDs : ArrayOfUUID): void

Implementations

There is currently an implementation developed under the name XIP (eXtensible Imaging Platform). The XIP homepage offers some download and there is also a link to a pre-press book chapter on Application Hosting and XIP.

DCMTK also implements a DICOM file format conversion to an XML file format that conforms to the native interface specification of Application hosting, see the announcement in the wiki and the corresponding dcm2xml tool manual.