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 9 Next »

Document Information

Author: Craig Stancl, Scott Bauer, Cory Endle
Email: Stancl.craig@mayo.edu, bauer.scott@mayo.edu, endle.cory@mayo.edu
Team: LexEVS
Contract: S13-500 MOD4
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services

Contents of this Page

The purpose of this document is to collect, analyze, and define high-level needs for and designed features of the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) LexEVS Release 6.4.

The focus is on the functionalities proposed by the stakeholders and target users to make a better product.

Design Scope

The LexEVS 6.4 Scope Document can be found here: LexEVS 6.4 Scope Document

Requirements 

The LexEVS 6.4 Requirements Document can be found here: LexEVS 6.4 Requirements Definition Document

Detailed Design

The following sections specify how the design will satisfy the requirements for the Lucene search upgrade.  This design reflects the wide ranging changes that will be necessary to LexEVS to fully update over three full releases of Lucene.  Since Lucene is the heart of the search mechanism that powers efficient searches in LexEVS these changes are necessarily extensive.  The focus of these changes can be broken down, to some extent, into three areas. 

  • Code decoupling from the current Lucene to allow for easier updates to the underlying search implementation.  
  • Multi-index searches to replace single index searches.  This will allow easier maintenance than the large, monolithic index we currently use
  • Code refactoring to the latest Lucene code base.  This requires extensive changes to the code base including replacement of objects with similar behavior for the current code base  and adjusting to changes in the Lucene API.  This also includes reimplementing a number of customized Lucene analysers and HitCollectors to insure compatibility with current code unit tests and user expectations.

Code Decoupling

Multi-Index Searches

Our current search for coding schemes within a monolithic index requires use of a Lucene Filter dependent on an XML file called metadata.xml.  This file has a handmade concurrency protecting class providing access and relies on the processing of DOM objects in order to provide both filtering of more granular entities in the system, and listings of the code systems in general.  As such it is something of a bottleneck for access.

With the advent of an index per code system design.  The metadata structure can go away.  In it's place a contextual file read of the names of the indexes with additional metadata persistence where necessary will replace the concurrent xml parsing.

Changing the Relational Representation in Lucene

 

General Code Refactoring

 

 

Detailed Design - Provide the architecture and design for the new Lucene feature.

LEXEVS-724 - Getting issue details... STATUS

 

The following JIRA items are all part of LEXEVS-724.

LEXEVS-813 - Getting issue details... STATUS

LEXEVS-814 - Getting issue details... STATUS

 

LEXEVS-815 - Getting issue details... STATUS

LEXEVS-816 - Getting issue details... STATUS

LEXEVS-817 - Getting issue details... STATUS

LEXEVS-818 - Getting issue details... STATUS

LEXEVS-819 - Getting issue details... STATUS

LEXEVS-820 - Getting issue details... STATUS

LEXEVS-821 - Getting issue details... STATUS

LEXEVS-822 - Getting issue details... STATUS

LEXEVS-823 - Getting issue details... STATUS

LEXEVS-824 - Getting issue details... STATUS

LEXEVS-825 - Getting issue details... STATUS

 

 

 

 

Please view the detailed design: LexEVS 6.2 Design Document - Detailed Design - Make it easy to do retrieval of only active concepts in a terminology through the/ a service

 

  • No labels