NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Document Information

Author: Traci St.Martin/Craig Stancl
Email: stmartin.traci@mayo.edu
Team: LexEVS/EVS
Contract: SAIC Subcontract#28XS112
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services

Contents

Sign off

Date

Role

CBIIT or Stakeholder Organization

Reviewer's Comments (If disapproved indicate specific areas for improvement.)

 


 


 

 


 


 

 


 


 

The purpose of this document is to collect, analyze, and define high-level needs for and designed features of the [Product or Component Name x.x]. The focus is on the functionalities proposed by the stakeholders and target users to make a better product. The use case documents show in detail how the features meet these needs.

Note

Use the sub-headings that you need for details of your Design Scope, Solution Architecture, and Implementation Requirements. Delete the ones you do not need, along with this note.








Design Scope

GForge items

Please visit the LexEVS 5.1 Scope document found at:  https://wiki.nci.nih.gov/display/EVS/LexEVS+5.1+Scope+document

Solution Architecture

Proposed technical solution to satisfy the requirements.

Performance Enhancements

  • Lucene
    • Lazy Document Loading
      • Lucene is very fast as a search engine. Given a text string,
        Lucene can find matching documents in huge indexes very fast.
        This is the purpose and strength of Lucene. Lucene is not, however,
        a database. Retrieving information from the documents that the
        search found as 'hits' is slow.

Consider this scenario: A user searches for 'heart' in the NCI
MetaThesaurus. When Lucene does its search, it will return probably
50,000+ 'hits'. This search is done very fast. LexEVS previously
would retrieve all of those documents to populate the
ResolvedConceptReference. Retrieving this many documents from
Lucene is slow.

What we do now is lazy load the documents as needed. After the
Lucene search is complete, we only store the Document Id. Then,
when information from the document is needed, it is retrieved
from the document. This is helpful in Iterator-type scenarios,
where retrieval can be done one at a time.

  • Update to Lucene 2.4 code
    • ...expand...
  • Searching
    • Plug-in Search Framework
      • ...expand...
  • Sorting
    • Plug-in Sort Framework
      • ...expand...
  • SQL
    • SQL query optimizations to increase database performance
      • ...expand...

RRF Data



Value Set/Domain Support



Loading Framework



Cross product dependencies

Include a link to the Core Product Dependency Matrix.

Changes in technology

Include any new dependencies in the Core Product Dependency Matrix and summarize them here.

Assumptions

List any assumptions.

Risks

List any risks.

Detailed Design

Specify how the solution architecture will satisfy the requirements. This should include high level descriptions of program logic (for example in structured English), identifying container services to be used, and so on.

Performance Enhancements





 RRF Data





Value Set/Domain Support





Loading Framework




Implementation Plan

This will include the technical environment (HW,OS, Middleware), external dependencies, teams/locations performing development and procedures for development (e.g. lifecycle model,CM), and a detailed schedule. 

Technical environment


External dependencies


Team/Location performing development


Procedures for Development


Detailed schedule

The LexEVS 5.1 project plan is located in Gforge at: 

Training and documentation requirements

One heading for each item.

Download center changes

List the needed changes.

  • No labels