Page History

...

• Action Items
  • caDSR team to provide a list of what is used from the Java API to determine what would need to be exposed in a REST API.  Phillipa could meet with the team Wednesday at 3PM.
  • caDSR to update to Java 8 jar in 2018Q1.
  • Send retirement notice regarding the 6.4 retirement and caCORE REST.

...

• Action Items
  • Request for a table of contents on the CDISC Terminology page. (Cancer.gov)
  • Request to update the CDISC term suggestion request form.

...

• Action Items:
  • Follow up on the use of REST Services (CTS, LexEVS REST)Investigate the issue when finding clinical trials (search) the same stage could be listed several times in the dropdown. 
  • Investigate the issue - Drugs and Drug family is problematic when determing what should come to the top of the list.
  • Determine mapping for accrual coding.

...

• Action Items:
  • Update Architecture to had include value sets and mappings.
  • Update Architecture to include all the ways that reports are created. (content channels - as separate slide)
  • Update Architecture to incude additional sources being loaded into SPARQL.
  • Update Architecture by adding channels from triplestore to LexEVS.
  • Update Architecture to add detail for Browser and assiciated dependencies
  • Update Architecture to change from SPARQL to TripleStore.  

...

Decision Points:

• Action Items:
  • Further investigation of VS Hierarchy Display needed.
  • Further investigation of what FDA needs (NDF-RT/MED-RT)
  • Small group to meet to discuss ICD-O-3.1

...

• Action Items:
  • Cory to complete testing of containers using CentOS.
  • Systems team to configure Dev system to be available for Docker and non-docker applications.
  • Investigate usage of MariaDB for JSON and graphing capabilities.
  • Jacob to provide versions of elastic search and SOLR.
    
    

...

• Action Items:
  
  • Natalia to send spreadsheet of class usage.
  • LexEVS team to send Migration link to caDSR team.
  • Determine gaps between LexEVS REST services and caDSR LexEVS API usage.
  • Provide assistance to caDSR team to parse results coming from CTS2.

...

Thursday, December 7th, 2017

...

• Action Items:
  • Perform a gap analysis to look at what caDSR current uses and what is avaible in the EVS CTRP API.
  • Assemble a joint working group to help build investigate a combined/coordinated REST service to get content from both LexEVS and TripleStore environments.
  • Identify additions to the existing EVS API to make it more useful to users.

...

• Overall Impessions and themes
  • Mappings
    • Extract mapping from Meta efficiently
      • This would save effort of creating custom maps.
    • Extend the model of mappings (is it supported in CTS2) to support different types of maps.
      • ie ICD-O3, Meta and the logic (OR, AND..)
  • Diversity of paths through the architecture
    • Addition of triple store
    • Multiple APIs to address user communities.
    • flow described - input of data through the tooling and delivery
    • 2 views for documentation were identified:
      • Focus on what users needed
      • Focus on overall architecture (technical)
  • Remote API Roadmap
    • Determine the replacement for what of the API is needed. (based on gap analysis)
    • Determine current users and identify what is required for those users.  
  • REST API 
    
    • Federation using SPARQL or other tooling
    • Big Data will require that performance be addressed (caching, etc.)
      • Will support the annotation pipelines
    • LexEVS will need to provide REST services for content not available in TripleStore
    • Provide documentation to better help users
  • Report Writer
    • Support for other terminologies. LexEVS REST services/EVS REST Services
  • SWAGGER documentation
    • Differentiate from the general API and CTRP specific API
  • Microservices
    • integration of triple store to support/enhance LexEVS functionality
    • Hierarchy/Transitive Table support.
  • User needs to create a unified service
    • Discuss with stakeholders to gather requirements
    • Determine how to move forward based on the requirements (best practice)
      • Separate APIs
      • Combined APIs
    • Ensure the service simpilfies what the user needs to know about the technical implementation.
    • This could be several months of effort (across teams)
  • User Education - Enable users to use the services
    
    • Provide better documentation for end users.
    • Provide mapping of source into LexEVS or REST models so users can understand how to query the service in LexEVS
    • Review and update Wiki Organization
    • Provide documentation to aid in building applications that will utilize the services (REST, Java API, TripleStore/SPARQL/ftp)
    • Architecture diagrams to describe the 1) flow of data and 2) technical specifics.
    • Provide timeline for enhancement (REST Services), dates for deprecation, system deployments
    • LexEVS REST Code Migration Guide
  • Build and Deploy (Docker)
    • Continued development of Docker containers with the systems team.
    • Use of Node.js to be discussed with systems team.
    • Investigate use of Docker for data deployments. 
    • Migrate CTS2 API from Heroku to NCI.

Decision Points:

• Action Items:

...