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 8 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 document the technical face to face meeting details between the NCI and Mayo for the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) LexEVS Release 6.3 and LexEVS Release 6.4.

Meeting Details (December 8 - 10, 2015)

Date

Tuesday, December 8 - Thursday, December 10, 2015

Attendees

NameRoleAttend? (Y/N)

Wright, Larry

NIH/NCI  

 

Fragoso, Gilberto

NIH/NCI    

 

De Coronado, Sherri    

NIH/NCI   

 

Safran, Tracy

NIH/NCI   

 

Ong, Kim L

IS

 

Lucas, Jason R

IS

 

Bauer, Scott  

Mayo

Y

Stancl, Craig

Mayo

Y

Endle,  Cory

Mayo

Y 

Wynne, Robert    

NIH/NCI

 

Tran, Tin    

NIH/NCI [C]

 

Carlsen, Brian

(NIH/NCI) [C]

 

Wong, Joanne 

  

Kuntipuram, Kumar

  

Topics

  • Tech stack updates, esp. Java 8
    • Do we need to coordinate LexEVS and tools updates?
    • Are there updates other than Java 8 to plan now?
  • Development process
    • Changes to build and distribution process
    • DevOps and CI: How Mayo implemented their CI server and what NCI's plan is for their own server.
    • Loaders
      • how to create one from scratch
      • Create a simple example of a loader
    • End user approach to LexEVS
      • Tutorial on how to query the LexEVS API
      • Review of existing LexEVS documentation
  • CTS2 REST services 
    • Expand to include associations?
    • Relationship of specialized REST calls (e.g., bulk download) to CTS2 service framework.
    • Discussion about one client should be able to connect to multiple instances of a service.  Can one endpoint provide data to query against another?  How can CTS2 be used in a manner that provides uri's that are not a part of the local resources.
    • Future uses/extensions of resolver
      •  Discuss a REST Framework that includes CTS2 and other calls (extensions)
      •  CTS2 REST vs additional (extensions) REST calls like bulk download  
  • Loaders
    • Issues with OWL2, MeDRA and HL7.
    • Tutorial/education on creating and using loaders.
  • GUI updates
  • RDF Triple Store or graph database LexEVS backing
  • End-user Value Set editor
  • Model updates to support additional Value Set functionality

  • Horizontal Coding Scheme searches 

  • Browser/LexEVS performance

  • Optional Tasks (from SOW, for reference):

    • LEXEVS API Performance and Usability Improvements
LEXEVS API performance and usability will be a major focus area for this effort.   EVS and other users have hit a number of bugs and missing features that significantly affect the usability of the APIs, with special effort needed to improve value set, mapping, multi-namespace support as well as querying of relationship and inferred data.
Active LEXEVS support in all indicated areas is important to the quality and efficiency of ongoing EVS operations and services, and to the growing community of LEXEVS adopters for whom it provides a shared conceptual and technical terminology model supporting community standards and interoperability.
    • LEXEVS Loader Improvements
The subcontractor shall address LEXEVS Loader Improvements.  The LEXEVS Loaders are a set of Java programs and configuration files that transform and load terminology data from the various file formats and source terminology data structures into the unified LEXEVS server data model.  They are crucial to data access and quality, and a top priority for the current effort.  Key areas of effort are improving and extending loaders to better handle current and new sources and formats, and improved documentation and error handling.
    • Enhancing the LEXEVS CTS2 REST Interface
The subcontractor shall address improvements to the CTS2 REST API and related resources.  The previously existing REST API was created as a prototype to prove that such an interface will have value.  It succeeded in that task.  Unfortunately, that older API is tied very closely to the underlying structure of the data rather than being tied to the usage of the data.  This effort will extend the new CTS2 API, tools and documentation to fill gaps in coverage of the CTS2 REST specification and focus on the user of the API, providing them with a clean, complete API that is easier to use than the current heavyweight solution.
    • Cloud Support
The subcontractor will address the deployment, customization and maintenance of cloud-based LEXEVS services in order to address the challenges associated with the growth of biomedical research data, and the computational limitations currently experienced by biomedical researchers.

 

  

 

  • No labels