The data model for Xero is split into two major sub-components. External data is information such as the results of a DICOM C-Find query. The data for that type of a query is the same for all users. Internal data is information about the current state and configuration of the user interface. For example, what are the current search parameters, what patient is being viewed right now, what studies has the user selected as being of interest and so on. Saveable user/role/group settings are external data, with any changes that are made taking affect immediately. Not all users using preference data may see the change immediately, but they will whenever their browser refreshes the xml content for their preferences.

External Data

External data includes information such as results of a DICOM C-FIND query, the JPEG image for a specific DICOM UID, at a given size and window level and other related data. This data doesn't change based on who is logged in, where they are logged in or on permissions, (although whether it can be seen or not does change). Mostly, this data is read-only, and is thus cacheable for some length of time on the client. As well, quite a lot of this data is large, or expensive to calculate, or both. Finally, this type of data is the sort of information that is required by any display type client. Thus, separating the interfaces for external data and documenting them is useful in order to allow clients to use the data in various ways and to reduce dependencies on the specific client.

The typical data producer for external data is a series of filters, in many ways like the Unix command line. Each filter can create data by querying other components (eg the database or do a C-FIND query etc), or modify the previous filters data (or both). This allows new features on the DATA level to be added by writing additional features.

There may also be data creators and updater's. The design for those components has not yet been decided upon, but is likely to be related to the filter pattern, but starting with fixed data and providing a series of filters to manipulate the data ending up with store of the data to remote system. An example of a possible filter here would be a GSPS publisher that takes annotations at the series and image level, possibly overlays, and window level, and publishes one or more GSPS objects to the Dcm4che server. This should use the SAME url patterns, but perform a post operation in order to comply with standard restful design. This also aids the browser in understanding when to clear cached data, so that the client automatically refreshes the visible information on the next display.

There are a number of support classes provided to allow creation of filters. The package to look at is org.dcm4chee.xero.metadata.filter. and metadata.servlet.

Significant Classes

FilterBean

A filter bean is the class to extend in order to modify an existing external data provider (with a new filter), or to create a new one. This class is provided with the parameters to use to modify the data, as well as with the next filter to call. Alternatively, the class can ask for a specific filter by name. This can allow two child filters to combine their data, for example to burn in GSPS data onto an existing JPEG image as provided by a WADO image filter. It can also allow conditional or repeated execution, for example, query for additional data if the initial set of data provided isn't correct for some reason.

FilterList

Filters are defined by being in a filter list, where the result of the filter chain can be read. The class that organizes them is the FilterList class. It isn't required to understand this class, but understanding how to configure this class is very important. The filter chain is configured via a set of meta-data. This information can be provided as annotations, or in a property file. The property file definitions for a particular filter chain for providing XML formatted C-Find queries is:

servletFilter=$\{org.dcm4chee.xero.metadata.filter.FilterList}
servletFilter.jaxbFilter=$\{org.dcm4chee.xero.metadata.servlet.JaxbFilter}
servletFilter.jaxbFilter.priority=999999

This defines a filter named servletFilter - notice the class is FilterList, with one filter element, JaxbFilter. This filter uses Jaxb on the result of the NEXT filter to provide an XML stream.

MetaDataServlet

The meta-data servlet is configured in the web.xml to use a specific filter list, and it provides the filter list with the request parameters, and uses the return value to provide the servlet response. This requires that the first filter called return a ServletResponseItem - that is, something that can be called to provide a final output for the servlet.
To configure this, use an example like:

   <!-- Data page mappings - XML files and the like -->
   <servlet>
      <servlet-name>Study Xml Servlet</servlet-name>
      <servlet-class>org.dcm4chee.xero.metadata.servlet.MetaDataServlet</servlet-class>
      <init-param>
	  <param-name>metaData</param-name>
    	  <param-value>/xero-cfind.metadata</param-value>
      </init-param>
      <init-param>
	  <param-name>filter</param-name>
    	  <param-value>studyFilter</param-value>
      </init-param>
   </servlet>

Example External Data - C-Find Study XML Data

An interface to the C-Find services on the local machine is available as: http://localhost:8080/xero/study/study.xml?ModalitiesInStudy=CT The parameters after the ? are standard c-find query parameters at the patient or study level. Not all C-Find parameters are necessarily supported. This example is the one configured above in the meta-data servlet. The filter beans defined for this servlet are: JaxbFilter, EmptyQueryParameterFilter, StudySearchConditionParser and DicomCFindFilter. The calling sequence is below:

Internal Data

The internal data consists of a set of information required for specific operations or view modes such as the current study parameters for the search page, the cine repeat speed when displaying CINE in the view page, the set of study UIDs of current interest etc. This tends to be a set of somewhat un-related data, where different components can contribute different pieces of data, and some components may contribute data in different formats, such as the search format for studies, as opposed to the URL format that is used to retrieve the external data.

The un-related data is typically provided by Seam based components, and updated by posting to URLs for the specific data to be changed. This is done regardless of whether the post is via a Javascript internal control, or is an overall post to replace the entire page. Using the same mechanism allows the same controls to be used for multiple themes such as an AJAX theme or a mobile device theme.

The Seam controls are well-documented on the jboss site, but a quick introduction to the concept of conversation state is worthwhile. Conversation state is a set of data related to a specific browser window or set of windows, based on a conversation id. This allows the user to perform different operations in different windows and to not overlap the state, and to have the state remembered for a reasonable length of time, but discarded after some configurable length of time of not being used. See the JBoss documentation at http://docs.jboss.com/seam/1.1.6.GA/reference/en/html/ for more information.

Current Design

The current design is very ad-hoc - all the data for each page is collected into a custom page in a fixed order just by adding lines of XML to an XHTML facelet file, and directly reading the value from the variable. This isn't viable long term, as it doesn't allow any way to add new data or modify the data without affecting that overall file. If two modifications are developed independently, they both modify the central data file to add their new information.

Design In Progress

The internal data is currently changing from ad-hoc data saved per-page into more organized structures. There are a number of items that users can change - their search criteria, adding presentation state to an image or series, editing report data and so on. These are saved in individual additions to the existing data, or new data information. Some specific data models that are important are: search conditions, search results display, cycle list, presentation state and layout/hanging protocol data. Each of these is described below.