Notice: You are only receiving the textual content of this site, most likely because you are using an outdated web browser that does not support a web technology called CSS. To also receive this site's layout and design, please upgrade to a browser that supports web standards.


Jump to Navigation

cni » projects » software development » SPINE

SPINE

SPINE (Structured Planning and Implementation of Neurological Explorations) is an informatics infrastructure designed to enable topical consortia and collaborative research studies. Through the software designed under the SPINE system, common data organization schemes can be integrated, which in turn enables standardized project-specific ad-hoc data retrieval, data pooling, and data management through complex queries on an "as-needed" and pre-negotiated basis.

SPINE is a complex suite consisting of centralized server side (application server) and distributed applications capable of multi-tiered data management of centralized, distributed, and local data repositories linked through a work-flow management system based on a number of freely available as well as commercial analysis and computing modules, and a structured SQL-based query interface. SPINE allows planning and definition of scientific projects, through specification of clinical populations to be compared, primary data to be used for derivation of variables, and definition of statistical models through integrated statistical software.

Data originators remain in full control of their data, and creators of (image) analysis modules also can determine their modules' distribution and accessibility policies. The SPINE interactive system is designed to provide novel operational functionality to the scientific community, with a particular focus on integration of clinical and neuroimaging data.

The primary embodiment of the SPINE concept is its interface (Figure 3 and Appendix 6), which - through a single portal will enable the design of a scientific proposal. This proposal uses language intelligible to both humans and machine (essentially text combined with complex queries and workflow definitions). Once the design of a project is performed using this interface, automated and rapid feasibility analysis can be performed and forwarded to potential collaborators. Once the project plan is approved, the same plan can be used to implement/execute the experiment by guiding and auditing each step of complex data and image analysis workflows.

The SPINE Interface web portal will consist of a set of user and project dependent portlets. Portlets represent a federation of web based applications with interfaces aggregated on web browser windows. They can be considered as atomic utilities, each of which has the capacity to enter into inter-process communications. Specific examples of the capacity of this system include: (1) Article aims description; (2) Case selection portlet allowing for user-defined patient inclusion/exclusion criteria; (3) Full and partial queries options with pre-defined limitations based on data ownership or study proposal-specific criteria; (4) Pre-defined queries, which can be incorporated into case selection portlet or implemented as a specific portlet; (5) Proprietary data request and regulatory compliance verification forms; (6) Project scheduling and workflow management, and (7) Publication preview and editing portlet. Statistical programs and an open “discussion board” can also be placed within the system, but are currently proposed as part of the Statistical Support Services (see below) and as part of the DCAC Interactive Web (Pediatric MS Dashboard).

The currently operative and actively used elements of SPINE are the data repository, WFMS, and some SPINE-compatible analysis modules [including 3D SLICER, R (an open-source advanced statistical package)], and Matlab-based image analysis tools, as well as pdf document generation capabilities. The remaining elements are in the early design, mock-up, or prototyping phase. Web services will be developed as main building blocks and integration entities for the entire SPINE System, utilizing SOAP (Simple Object Access Protocol) for both publishing and consuming services. XML- RPC protocols will be used to connect to the third party Web Services that are communicating with clients via XML-RPC protocol. For instance, OsiriX image processing suite has XML-RPC web services feature. If end users need to deploy light weighted web services accessible on a local network, the XML-RPC servers can be deployed as well. SOAP web services will be deployed on Sun Java Systems Application server. The client side developers will create web services consumption by client by doing the following steps: (1) Access to a Web Service Descriptor Language (WSDL) via corresponded link on the Application server; (2) Creation of a client proxy module based on the description of web service operations encoded in WSDL file in XML format, and use of a client proxy module to write a web services consumption code. Since both the SOAP messaging protocol and WSDL are based on the standard XML interface, the web service internal functionality can be implemented through Java or Matlab applications and may consume web services written in C++. The web services are adopted by DICOM and HL7 and are by the IHE (Integrating the Healthcare Enterprise) technical framework.

The Web service functionality allows composite applications to be created based on existing functional blocks implemented as web services. The Web service will provide standard functionality for custom build applications developed on various platforms. Same web services' operations will be used by applications built in Java, C/C++, Matlab and other programming environment. The SPINE applications will consume R and SAS statistical scripts' functionality developed at Harvard School of Medicine. Inter- and intra- project communication is enhanced by this system, through XML packets using HTML protocol. Development costs are reduced by allowing publishing of existing applications' functionality as web services, hence optimizing current IT assets utilization and through the simple consuming of published functionality by newly designed applications.


Use Cases

Figure 1. Figure 2. Visual QC Session Screenshot.




CNI/BWH © 2000–2004 | XHTML 1.0-T, CSS