Overall Use Cases

This document describes some of the higher level use cases and work-flows for users, sites and support personnel.

The use cases that are required in order for the project to go ahead are marked with a if they are already implemented and working, with if they aren't implemented but are not expected to be problematic, and if they are not implemented and are difficult/unknown in how they are implemented. Finally items need discussion as to status.

For items required for final release, they are marked with if implemented, if not implemented, but not troublesome and if not implemented and could be troublesome.

Other, non-required features that are implemented are just shown with a

Clinician Use Cases

The clinicians are the end-users of the Xero system, and they are expected to be the ones searching for patients, studies and reports, and displaying/manipulating such reports.  By clinician, we mean any medical professional who has access to multiple users protected health information such as reports and images. Excluded from such users are the patients themselves, and  administrators who manage the overall system.

Login/Use Xero/Logout and Security

Generally, the workflow for a user is that they select a page to display as a link from some other system or from an email, and if they aren't logged in (perhaps automatically because they were already logged into some other system, or perhaps manually because they were already working on pages), they will be redirected to a login page, and asked for credentials.  They will then be allowed to proceed to their original page.  After some length of time, they may decide to logout, or close their browser and be automatically logged out, or perhaps just wait on a given page long enough that they are automatically logged out. After this, they would view the login page again before they could see any protected pages, and the cycle would repeat.

1. Login
2. Automatic logout
3. Explicit Logout
4. Controlled access to PHI when logged in (PHI=protected health information)
5. No access to PHI when not logged in
6. Integration with IMPAX 6 or 7 users/roles
7. Fine grained control to PHI

Search for Patients, Studies or Reports

The search for patients, studies and reports works with the user entering some number of criteria such as patient id or patient name, and then selecting a find operation. Alternatively, they may have pre-configured searches that they use all the time. The search results would be displayed, and they could select one or more studies/reports to view.

1. Search for studies by Modality, Patient ID, Patients Name, Sex (other parameters also possible)
2. Search and/or display for patient/studies by location. This is not technically possibly in the current Dcm4che implementation as patient location isn't known. An integration with a RIS or other related system could allow this.
3. View a single study
4. Add a study or studies to a list of studies to view
5. Bookmark a page with a fixed set of study criteria and/or values.

Display Study Images and Navigate

A very important use case is the ability to display a study's images and to navigate with them. This has a number of important sub-use cases to allow the image to be manipulated in various required fashions.

1. Select a Study to view from the set of studies available for a patient.
2. Select the series to view from the current study. This series can be either a real series, or a "virtual" series, created typically be splitting up a real series into different pieces (eg for MG studies or MR echo).
3. View the first image in a series
4. View the next/previous image in a series
5. For a larger series, navigate faster than next/previous. Should probably be exponential based on human factors, eg view next/previous, view 2cd, view 4th, view 8th etc to allow the user to quickly get to a given position in the study, or perhaps use a slider to select a given position.
6. View the patient/study/series/image demographics
7. View key objects as series (instead of viewing all series, this shows key objects)
8. Apply window level presets
9. Apply GSPS information (excluding true size requirements, and calibrated monitor requirements)
10. Apply dynamic window level (demo is implemented, but not cleaned up for commit yet)
11. Zoom/pan the image.
12. Apply measurements to the image (or series/study)
13. Save the measurements, window-level, etc (anything in GSPS)
14. Select objects as key objects, and save those as a KO

Display Report

From a given study, the user needs to be able to view the default report, or to select a given report to view if they wish to see another report. This can be difficult because the reports may not be stored locally, and there could be quite a few different types of systems storing reports and providing them in different formats, with different status codes etc.

1. View report in image frame, instead of image
2. Select and View alternative report
3. View images in series tray that are associated with the report.
4. View a report through a gateway - report is coming from somewhere else.
5. View whether a study has a report, and if so, what kinds and what status.

Administrative Use Cases

An administrator of Xero is someone who manages users, studies etc. The administrative uses cases are currently all handled by the existing DCM4CHE web interface, however, it is expected that such administration will be extended/supplemented either by 3rd parties or by Agfa as part of a commercial offering.

1. Create a user
2. Assign a user some permissions
3. Assign a user fine-grained permissions
4. Create a group of users with permissions etc
5. Interoperate with some remote definition of users/passwords, possibly including smart cards etc.
6. Provide URL that looks the same as WEB1000 including use of tickets.

Site and Support Use Cases

The site use cases deal with customizations of the appearance and functionality of the Xero system, while the support use cases deal with installation, upgrade and repair.  These are combined into one section because many of the customizations and other management overlap with the installation and general management of the Xero system.  As well, a site maybe able to purchase site level support for customization in addition to purchasing support for the management of a Xero system.  This statement is not an agreement to provide such support, merely that it is possible for a company to offer such services.

Performance

In order to support this system, it is required that there be a reasonable level of performance, and that not too many servers are required to support a reasonable number of users. The assumption will be that there is a separate system for Xero that accesses the same database and caches as the regular Dcm4che server. These are not hard and fast, but are thoughts based on what I have seen other servers handle. There maybe some hard reasons why this is unrealistic, but what seems like it would be required in order to make this product feasible is approximately:

1. Allow 25 concurrent users per processor
2. Allow 25 concurrent users per gigabyte of RAM consumed
3. Allow 25 concurrent users per 100 mbit/sec network access to the server
4. Support 10% of the concurrent users doing dynamic window levelling, at 5 fps minimum, 15 fps maximum
5. Support 35% of the concurrent users doing a query
6. Support 35% of the concurrent users doing a series view
7. Support 20% of the concurrent users doing other operations
8. Assume think time per operation is 2 for query, and 1 s for other operations and series view.
9. Assume 8 processors maximum for this configuration at the moment (we can go higher, but that will require more power from the remote DB, likely with another server, probably even at 4 processors it will switch to 2+ machines)
10. Combined operations should not cause DB queries to use more than 1 CPU worth of DB processing time.
11. Combined operations should not cause cache reads to use more than 100 mbit/sec of the network
12. Local disk not to exceed 1 tb of cache to allow the above operations to proceed

Note that the 25 concurrent users would allow 200 concurrent users on an 8 processor machine - our maximum target machine. From WEB1000 experience, this would support approximately 8000 registered users. That seems like a reasonable cost for the server machines in this type of category, and is the reason for some of the numbers that are chosen.