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

Document Information

Author:  Craig Stancl, Scott Bauer, Cory Endle
Email: craig.stancl2@nih.gov, scott.bauer@nih.gov,  cory.endle@nih.gov
Team:  LexEVS
Contract:   16X237
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 2017.12 technical face to face meeting details between the NCI and the LexEVS Team.

2017  December Face-to-Face Meeting Notes 

Tuesday, December 5th, 2017

TimeLocationTopicsParticipantsResources
9:00 AM - 11:00 AM4-W-034
EVS Status and Future Direction

Discuss EVS current state, trends, and future directions

  • Larry to give brief overview of EVS infrastructure, resources, and services.
  • Review overall technical workflow and architecture.
  • Group discussion of future possible directions and priorities.
Broad cross-EVS participationEVS Project Architecture

Attendees: 

Jason Lucas, Scott Bauer, Larry Wright, Cory Endle, Kim Ong, Tracy Safran, Rob Wynn, Gilberto Fragoso, Margaret Haber, Kumar, Sherri De Coronado, John Campbell, Ron, Luba, Shamine

 

Discussion Points:

  • House keeping Items
    • Reviewed agenda and approved - unless there are changes along the way.
    • WebEx will be live all day.
    • Goal is to record key tasks and wikis
  • Goal is to set context for the rest of the meetings this week and to start identifying the issues to be addressed.  
  • Larry would like to start to complete the complete EVS Project Architecture (including LexEVS)
  • General workflow for architecture:
    • Gather terminology content → protege and meme → loaded into LexEVS terminology service → accessed via java api, rest service api, browsers
    • Architecture now needs to include the triple store database and usage (REST API and native REST API).  This service is to support clinical trials (CTRP).  Ability to make changes into the production service was a driving factor in going to TripleStore architecture.  Loading into triplestore can be done nightly if needed.  Currently the loads have been nightly.
    • OBO is currently being looked as as a third delivery channel.  
    • Expected to have expanded use of services and downloads
      • Adverse events were the most downloads  - and then used and built in other systems (CDISC and FDA, etc).
    • Report Writer extracts value sets from LexEVS
      • Current work happening to create a SPARQL based report writer. Planned for early February.
        • This would be only on QA team.
        • External use would require a security layer (doesn't exist today)
        • Gilberto noted that report writer cannot currently take a search and return result set (with preferred names).  Noted this is "simple search" and could also be part of the term browser.
        • Existing templates should be able to be run without authentication.
  • The TripleStore still cannot provide all the terminology data needed for EVS and is stored in LexEVS. 
  • Mappings - need to determine how to capture and allow access to mappings.  The LexEVS model and triple store model do not provide the needed flexibility today.
  • Synchronization of data sources and coordination of distribution of data is an open issue.  Consideration is needed to provide an umbrella API (Federated) that serves both LexEVS and TripleStore content.
  • Gilberto noted that CTS2 services should be revisited and he'd like to review missing functionality and complexity (noted by CTRP).
  • LexEVS historically has been based on standards since the early inception of the tooling.  
    • As a terminology service, all the content has been loaded into Lexgrid data model.
    • Focus from standards has shifted to providing usable services to end users.
    • There are possibilities for enhancing the service today that still provides interoperability.  
    • Thesaurus based use cases should be considered when determining goals.
    • CTRP usage of TripleStore was speed in loading content.  LexEVS loading of transitive table is long process.  Tracy noted that LexEVS could start to use TripleStore technology to remove that bottleneck when loading content.
    • Noted that existing applications may not be ready to transition to new serivces.
    • Primary goal of EVS is to proviede terminolgoy content to NCI customers and users to support the sciences.  
      • Noted that no interest in re-desigining 
    • LexEVS provides a consistent model. 
  • Mappings
    • Currently default to the LexGrid XML format.   The other is RRF loader mappings.
    • No plans to load mappings into SPARQL.
    • ICDO3 Map from Meta - Kim looked at performace - not the best results.
    • Mappings in LexEVS in coding schemes.  
    • FTP will be main distribution for Maps. (Tab delimited to text)
    • Review of CTS2 mapping support will help decide if additional functionality can be added.
    • No support for contextual mapping currently exists.
  • Systems Priorities
    • LexEVS has spent time this last year and utilizing Docker.  This will provide efficient deployments.  
      • Current deployments are completed by using a documented deployment document.
      • Containers will reduce the middle man needed for deployments.  
      • Systems team has been trying to create an "approved" NCI container so the LexEVS team can use.  
      • Will still need to continue running tests.
      • Need to talk with systems about environment.
      • Docker is operational at NCI.
      • Docker usage for data
        • Gilberto suggested promotion of data using docker.
          • Provide the "database" container to the systems team.  
          • This would help as it is deployed up the tiers.  
      • Docker distributions to be used for end users.
        • ASU was working on this type of container.  
        • Current scripts do 90% of what is needed.  Need to change configuration so it doesn't remove the services.  
  • QA
    • Currently there are test scripts created by Kim and Shamime(?)
      • Covers the majority of the usage.
      • Test scripts still being developed.  
      • Tin is still available for reference.
      • Tests should be avaiable in Jenkins. (LexEVS team is currently doing this)
      • Docker shouldn't cause concern for QA.
    • Tech stack support 
      • Confirm that NODEJS and other technologies are supported.
  • Security Scans
    • 508 needs to be addressed.
      • Heroku and SWAGGER pages may need to be reviewed. 
  • Lucene, SOLR and elastic search
    • Jason noted that there might be need for discussion during the API focused discussion on Thursday.

Decision Points:

  • Action Items
    • Mapping to be discussed further with the editors.
    • Capture the Architecture to describe the workflow.
    • LexEVS to look at utilizing the triplestore to speed up load (remove the need to load transitive table)
    • LexEVS REST (CTS2) services should be revisited and reviewed for missing functionality and complexity
    • Investigate the use of Docker to deploy data (Database container).
    • Investigate the use of Docker containers to end users.
    • Docker environment updates from systems team. 
    • Consider 508 compliance going forward.
    • Confirm tech stack status for use of NODEJS and other related technologies.

 

TimeLocationTopicsParticipantsResources
11:00 AM - 12:00 PM4-W-034
EVS Technical Infrastructure, Issues, and Options

Flesh out architecture and workflow diagrams, identify key areas of discussion

  • Review overall architecture and expand/update
  • Identify areas where current infrastructure is changing or problematic

Primarily EVS technical team members

(several have conflicting clinical trials meeting)

EVS Project Architecture

Attendees: Jason Lucas, Scott Bauer, Kim Ong, Rob Wynn, Gilberto Fragoso, Cory Endle, Craig Stancl, Shamine

Discussion Points:

  • Mapping
    • LexEVS doesn't allow for ability to map into Meta
    • Execel spreadsheet (provided by Steph) provides ICDO code to Meta
    • Maps in LexEVS provide
      • Relationship 
      • Goodnesss 
      • Map Rank

 

Decision Points:

 

TimeLocationTopicsParticipantsResources
1:00 PM - 2:00 PM 5-W-032
User Group Discussion - caDSR

User Teams to share how they are using EVS and  discuss requirements/priorities for the future.

  • APIs: Java, REST (CTS2 or 3-store), SPARQL, FTP
  • Backwards compatibility of server/client/data releases
  • Incl: Java/jar file issues and future
  • Incl: New terminology server API/content/other needs.
caDSR contact - Denise, Philippa, developers 

Attendees: 

Discussion Points:

Decision Points:

 

TimeLocationTopicsParticipantsResources
2:00 PM - 3:00 PM  5-W-032
User Group Discussion - FDA and CDISC

User Teams to share how they are using EVS and  discuss requirements/priorities for the future.

  • APIs: Java, REST (CTS2 or 3-store), SPARQL, FTP
  • Backwards compatibility of server/client/data releases
  • Incl: Java/jar file issues and future
  • Incl: New terminology server API/content/other needs.

Editors

Liz, Erin, Brenda

 

Attendees: 

Discussion Points:

Decision Points:

 

TimeLocationTopicsParticipantsResources

3:00 PM - 4:00 PM

5-W-032
User Group Discussion - CTRP / CTS-API

User Teams to share how they are using EVS and  discuss requirements/priorities for the future.

  • APIs: Java, REST (CTS2 or 3-store), SPARQL, FTP
  • Backwards compatibility of server/client/data releases
  • Incl: Java/jar file issues and future
  • Incl: New terminology server API/content/other needs.
CTRP / CTS-API - managers,  developers, Tiger team (Gisele, Samantha, David, Brian, Peter, Tracy, Jason, others) 

Attendees: 

Discussion Points:

Decision Points:

 


Wednesday, December 6th, 2017

TimeLocationTopicsParticipants
    

Attendees: 

Discussion Points:

Decision Points:

 

TimeLocationTopicsParticipants
    

Attendees: 

Discussion Points:

Decision Points:


Thursday, December 7th, 2017

TimeLocationTopicsParticipants
    

Attendees: 

Discussion Points:

Decision Points:

 

TimeLocationTopicsParticipants
    

Attendees: 

Discussion Points:

Decision Points:

  • No labels