NIMS Contract Phase3


Jump to: navigation, search


[edit] Scope

The objective of this third phase of the NIMS contract is to modify NIMS to support its deployment in the newly created CNI. This phase will move NIMS from a substantially complete prototype to a beta version of an enterprise mission critical tool

At the conclusion of this phase NIMS should

  • be deployed within SUnet providing a new login mechanism that enables logging in with Stanford credentials, in addition to standard login
  • provide the needed connectivity for its use with the CNI scanner
  • have a number of minor issues cleaned up

[edit] Project Management

The deliverables below will be carried out within the time-frame of this agreement on a best-effort basis.

As before, Jorge will provide project technical and architectural direction.

Bob will support the local management of Gunnar, Reno and other people resources as needed

[edit] Deliverables

[edit] Update NIMS Request Processor

Current: NIMS NRP is implemented using Pyro 3.x. Although Pyro 3.x is stable and reliable, most automated package searchers find Pyro 4.x instead (a beta version).

Planned: The deployment of NIMS to its new target hardware and software infrastructure would benefit from porting the design using Pyro 4.x. This will require changing the implementation of the lower layer of the request processor in terms of the updated Pyro 4.x code, which is incompatible with earlier versions.

This task will produce a new version of the code using Pyro 4.x and enable the simultaneous maintenance of two versions of NRP depending on deployment and reliability requirements.

[edit] Architect, design and implement the NIMS Pull Scanner Interface

Current: Phase 2 of NIMS development implemented a fully-featured prototype oriented towards use from the Lucas Center facility

Planned: The creation of CNI and the deployment of its MRI scanning facility has opened the possibility of implementing a more streamlined interface between the scanner and NIMS than the one that was previously used. Bob is currently implementing a scanner side DICOM processor to be interfaced with NIMS. This task will produce a pull interface that pulls DICOM images from Bob's DICOM server. This will be the primary way of getting images into NIMS from the CNI.

There are several tasks:

1. Architect a DICOM puller interface for NIMS

2. Define an API for the interface with the DICOM server

3. Design the needed modifications to exam and series loading as well as any needed changes to the NIMS raw loader and related packages and modules

4. Implement and test this interface

This task will produce an architecture and design document, as well as the associated code implementation

[edit] SUnet Webauth Login Functionality


The current login scheme has not been interfaced to the Stanford web authorization scheme to allow use of Stanford credentials for logging into NIMS to use its services.


We will modify the login code to allow both the existing login scheme and allow the use of Webauth credentials when logging in from within the Stanford network.

The following are the objectives of this task:

1. Support the design of Webauth login providing the NIMS side expertise.

2. Design the modifications needed to the existing NIMS login code and internal session credential management to support Webauth.

3. Implement the corresponding NIMS functionality

Detailed features"

1. The WebAuth code will set a cookie in the environment with the SUNetID of the person logging in. We will dispatch the login URL to a controller that will get the cookie, search for the user in NIMS, set the capability vector and carry out the rest of the login process. If there is no SUNet ID set in the cookie, login will fail. Login failures will be treated the same as they are now. Login will be blocked the same way it is currently blocked.

2. An enhancement to login would be to allow both a WebAuth login and a traditional login.

3. Another enhancement would be to allow RFID login at a workstation. The RFID tag is read by a reader, which sends this to the system, which searches a database of bindings RFID to SUNet ID, and proceeds with login as in 1.

[edit] Updated exam upload

[edit] Modified exam upload structure


The current system provides a flexible exam content structure and images from a series are uniquely identified by their series and acquisition number. There is no naming convention for exam content upload (i.e. NIMS does not interpret series directory names as having any meaning e.g. Anatomy, Pfile and DTI content).


We will allow uninterpreted content to be uploaded and associated to an exam or its associated series. The new functionality will also allow series to be grouped into a hierarchical file structure, such as:

  • An exam to be uploaded is a compressed directory of trees.
  • At upload time, an Exam entity is created in the database from which all uploaded content will be referenced.
  • Each subdirectory in an exam tree(including the root directory) contains a number of image files (DICOM slices), P* files, and uninterpreted content such as text files, PDFs, functional annotations, etc. to be indexed into the database.
  • Subdirectory image files are grouped into series objects according to <series#, acquisition#> or according to P* conventions. At upload time all series objects in each subdirectory will have their descriptors loaded into the NIMS database as Series entities and their raw image data converted to separate .nii image volumes
  • Uninterpreted content in the root directory is associated at upload time to the exam object being created
  • Uninterpreted content in a non-root directory that has only one series is associated to that series
  • Uninterpreted content in a non-root directory that has several series is associated --arbitrarily, TBD -- to the series in the subdirectory with the earliest acquisition time. If a user wants to embed several series in the same directory, each with separate uninterpreted content, then the user must place each such series into a separate single-series sub-directory and the uninterpreted content placed there.
  • Directory names in the upload file will not be discarded. They will be used as the default description for the NIO.

[edit] NIMS Functionality Enhancements

[edit] Subject Access Restrictions


Access to subjects is not restricted depending on user


Subject access should be restricted to subjects associated either with the current group of a user, or any group a user belongs to, or to subjects associated to experiments or exams a user has access to. This task will choose an access scheme and implement it.

[edit] Access to grant information


Non-root users cannot see grant information


Basic grant information should be viewable by researchers. This information may be constrained to grants associated to groups the researcher or user belongs to.

[edit] Schedule of Deliverables

Wave 1:

  • NIMS request processor changes to use Pyro 4.

Wave 2:

  • Web access basic functionality

Wave 3:

  • Scanner exam load functionality and interface, exam loading format

Wave 4:

  • Subject access, grant access

[edit] Milestones

  • Milestone 1: NRP implemented on Pyro 4, Webauth basic login functionality
  • Milestone 2 Scanner exam load interface
  • Milestone 3: Revised exam loading format
  • Milestone 4: Subject access, grant access

[edit] Status

  • Milestone 1: NRP4 completed, documentation generated (1/15/2011), tested on standard deployment. Basic Webauth login completed (4/28/2011). r93
  • Milestone 2:
  • Milestone 3:
  • Milestone 4:
Personal tools