Xero - Area to be worked on.
The initial work for Xero needs to be done before other areas can really be considered. Those areas are:
Search for patients/studies; return a list (option: sort items). Select a study for display.
Display study, select series(one or more) and display images with images 1X1, or nxm
Display reports (text) (from display area only at first)
All of these areas need an initial implementation before anything else can be considered, as there needs to be sufficient existing work in order to frame the remaining work. The other area that would be very helpful to have working is a Themes management setup. We can start with the Seam Theme design, but something more complex that allows better selection of objects and pages is important so that different designs can be worked on without overlapping.
1. Open source version of preferences/role/user framework. Ideally this would look similar to the hierarchy that Agfa IMPAX 6.x uses.
Basic ideas:
Roles are nested inside roles, and preferences come from the nearest value found for the given item.
Users that have 2 or more roles have preferences for EACH set of roles.
When "setting" a preference, if it is the same as the next nearest parent, then setting it is equivalent to removing the local preference and that is the opreation performed.
Some preferences have partial overrides - eg list of command buttons to use, or command buttons for a given location.
Some roles might be specific to a given theme.
This could VERY easily become a nightmare to administer - thus, some careful thought into how this should be handled is required, especially as it interacts with Themes.
Instead of multiple user-roles per role that the user participates in, a way of indicating when changing preferences whether the change is global, just for the current role, and/or just for the current theme?
2. Add station/theme configuration. This adds 3 capabilities: device configuration for example RIM pagers, theme configuration for various layouts, eg an Intern Theme or a Nurse Theme or a St Mary's Hospital Theme. and plugin management.
Basic ideas (I will call this themes here):
Similar to preferences, themes store some number of "preferences"
Similar (identical?) to roles, themes inherit from their parent them.
Themes define a set of objects/web pages to use. That allows which plugins to use to be well defined.
Some Themes might be theme fragments, used to define a plugin. These themes over-ride certain values and are used to mix in new functionality. Again, careful work on figuring out how to manage this is required.
Some themes may define new preferences, and or completely new areas of functionality.
A way of detecting conflicts is required for theme management.
Note that although themes kind of sound like plugin management for a single application, they differ because users use different devices and there are multiple concurrent users, so it is more like managing multiple, possibly conflicting plugins simultaneously.
3. Add facelet/seam support for WAR fragments in Java. This is directly relevant to how we manage theme management, because ideally themes that include new web pages etc should be added to the system dynamically and as a completely separate portion. This currently works quite well for EJB jar files, but WAR's within a given EAR file are disjoint and don't share any state. That is, I think a mistake, and it would be nice to be able to remedy that, at least for being able to add in SEAM xml configuration in a new WAR file and Facelet XML files. Alternatively, we could just live with re-generating the xero.ear file, or using a fully exploded ear and just dropping things in place - however, I don't think that is such a good idea.
4. Create a theme for mobile devices, and further specialize that into a theme for RIM pagers and one for one or more mobile phones.
5. Create a theme for a Java applet replacement for the primary image display area, and write an applet (running on 1.4+) that knows how to cache images, display them, handle hanging protocols etc. Ideally this Java applet could run even on mobile Java?
6. Create a theme and executables to allow disjoint machines to display images. The idea here is to allow a small hand-held device to control a large screen, for example via an IR link. The clinician selects the study they want on their RIM pager/phone/palm, and then points the device at a large screen in a room, and selects display. They then can control layout, series selection, window level etc remotely.
7. Update the WADO client to add the most immediate needs for fast display:
a. Update the WADO client to use Seam and EJB3 - very important to use a conversation based model to hold state information and throw away stale images.
b. Add window-levelling support (this needs to be implemented as a plugin that knows how to modify the image processing logic - given ability to add arbitrary plugins, all the rest of the functionality becomes quite a lot easier to implement and manage.)
c. Add sub-region support
d. Add support for lossy level, to allow a really fast transmit of a highly lossy image (how well this will work depends on the performance of the encoding libraries.)
Given the 4 items above, Xero can be configured to use AJAX to display the images, downloading them in pieces, and can possibly implement window levelling without a downloaded client.
8. Implement AJAX based window levelling.
9. GSPS and markup support
The WADO client needs to have GSPS support so that we can display markup annotations (ie measurement), overlays etc. This would require changes:
e. Transmitting GSPS overlays as transparent GIF/PNG files.
f. Converting GSPS markup into SVG
g. Given the SVG markup, using the Java SVG libraries to convert the SVG into transparent GIF/PNG
h. Convert configured demographics into SVG and/or html, and thus into transparent GIF/PNG
i. Add a burn-in servlet, that takes the demographics, overlays, annotations and burns them into the image (for better WADO compliance).
10. Multi-frame support
It would be very nice to have support for better real-time display of multi-frames. This probably requires a dcm4che server change to allow storage of the MPEGs.
Initially, a set of pages to display multi-frames could be added, with WADO modified on the back-end to use mencoder (from mplayer) to encode the frames as a movie.
11. Reporting support
Just add support for displaying reports.
Add external report configuration and retrieval.
Possibly use the Java PDF reader to convert PDF to text for low-end devices
12. Configuration
Add pages and the ability to plugin new configuration areas. Integrate this with the dcm4che configuration if possible?
13. Help
Add the ability to make the help based on what plugins/theme is in use, and the ability to add help either as part of a plugin or as an independent portion, but still linked to the given functionality.
14. Implement zoom/pan functionality - this should be relatively easy to do, but some thought as to how it should be done based on the other things that are being done should be considered. Also, it would be nice to have this work even on devices with small screens - practically, that means that links need to be used for panning, and zoom probably isn't dynamic on those devices. However, on more capable devices, the use of AJAX (or perhaps just JavaScript and DOM tree management) would be better.
15. Add SVG editing support for the markups that are available from GSPS as generated by the WADO server.
i. Also add import/upload of overlays.
ii. Add GSPS publishing capabilities.
iii. Group GSPS objects by name, as per the DICOM spec.
iv. It might be desirable to allow users to delete their own GSPS objects, or at least to hide them. Which one is done might be a system configuration.
16. Add search/retrieve capabilities for non-local archives. Note that it is unlikely that we can achieve acceptable display performance without retrieving images locally. However, it would be nice to have the ability to retrieve just key images + GSPS objects. Ideally, the key objects should define the GSPS objects as well, as that makes it absolutely clear what is to be displayed.
17. Implement split/merge/segment selection and configuration.
18. Interpret hanging protocol DICOM files, and allow them to be used to display images.
19. Implement jBPM based workflow management for the list area to allow, for example, studies to be assigned to interns for preliminary review, or workflow sign-off etc. Ideally, allow other clients to also participate in this. Types of lists might include:
- Manually managed lists - users explicitly add/remove from such a list.
- Automatically created lists - based on some selection criteria, or image/study arrived.
- Integration with DICOM workflow - just add jBPM adapters for the DICOM standards here.
20. Specific behaviours for research areas - implement themes and functionality for specific types of behaviours such as Orthopaedics, automatic report creation, etc.
21. Create themes to integrate with various RIS systems (that is, make the system into an integrated portion of various WEB systems.)
22. Add support for other image level operations - eg Flip/Rotate, adjust aspect ratio, modify various LUT's, etc.
23. Add logic to handle a set-aside list and cycle list at the session level (eg 1 user has a set-aside list and a cycle list)
24. Add client-side jpdl workflows for managing complex image displays - eg Mammography workflow where the user might want to see a certain hanging protocol first, then a second one etc, but they would have alternate rules if there were 2 sets of priors, or if there were 2 currents, with 1 of them being extra images, and the other being the normal views etc. The workflows would need to be defined in a theme based system, but would need to be selected as to which one was actually active based on the role or preferences of a user, perhaps even by a button selection, eg a user might be doing sign-off at one point and they don't want to get dropped into a different complex workflow on signoff. (note that signoff potentially has both a jBPM process associated with it to manage who signs things off, as well as a jpdl page flow to actually manage the signoff interaction itself.)
25. Add support for image display against a remote server that is capable of serving WADO images - this will likely need a couple of theme modifications at various levels based on whether this is a low-functionality WADO server, a high-functionality one, or a dcm4che one with any custom extensions that we have.
26. Add single-sign on integration, so that we can sign on to the system as part of some other login process.
27. Add station based single sign on (that is, you log-in to the system and it automatically logs you into Xero)
28. Add automatic logout/un-display after a certain time out.
29. Improve security of Xero by having a server configuration that disables remote access to all services except those explicitly enabled/needed for display.
30. Improve security of Xero by adding user configuration for searching on given patient information and positive/negative permissions, including emergency override access. Ideally, this would use the same sorts of interfaces as other clients connection to dcm4che use, but with an open source back end as a potential interface - or make the configuration/management interface on the back end be open source. An alternative here is to configure this entirely with files, but have a w (proprietary) way to integrate the proprietary client systems into those files or services.
31. Work with W3C to extend XFrames to define a multi-screen version of XFrames. Update Firefox to implement this. Add a theme to Xero to support (automatic) multi-screen display.
32. Add directly client-side window levelling via SVG support. This involves:
1. Add support for feColorMatrix to firefox's SVG support.
2. Ensure the Firefox SVG internal support for images includes 16 bit lossless JPEG.
3. Add WADO support to specify lossless 16 bit JPEG.
4. Create a theme to handle window levelling via SVG. This will make window levelling lightning fast.
33. Add a magnify glass theme/operation that uses an overlayed window with AJAX or the like to allow it to be dragged around and magnify the area under the glass.
34. Create a theme for display of waveforms.
35. Clustered Xero - add support for display of Xero and dcm4che as a clustered set of servers.
36. Write an install system for Xero that installs a given configuration, updating only the elements that are required, and leaving local customizations and configurations in place.