Page History

...

• Currently uses the API using the Jar file and dependencies.
  • Curresnt uses LexEVS Java API
  • No use of REST API except for limited use.
• Denise noted issues when data model or data have changed
  
  • Curation tool and SIW - no plan to change/update.
    • No reason to change the API unless it was going to be depricated. 
• Denise noted that no release somplete to access to resolved value sets
  • LexEVS can provide, but caDSR needs to update.
• There are proof of concept services being evaluated.
  • CDE Recommender Service
  • CDE Validator Service
  • Looking at using SPARQL
• Traci asked what of the Java API is currently being used by caDSR so that when building the REST API, the team could focus on those services. 
  • Search for Concept Code
    • Return name, definition, def source
    • Return super concepts or sub concepts
  • Search for Top level concept for value set/domain
    • Return resolved codes
  • Search for CDISC SDTM Variable Terminology
  • List all value sets
• Release Roadmap
  • Early 2018 - plan to make recommendation and decision
• Java 7 / Java 8 Jar
  • would require caDSR to do a maintenace release in 2018 (Q1)
  • Until this is complete, the EVS team needs to maintain 6.4 and 6.5 sets of data. 

Decision Points:

• 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

...