 |
Page History
...
Jason Lucas, Scott Bauer, Larry Wright, Cory Endle, Kim Ong, Tracy Safran, Rob Wynn, Gilberto Fragoso, Margaret Haber, Kumar, Sherri De Coronado, John Campbell, Bron, Luba, ShamineSana Din, Craig Stancl
Discussion Points:
...
Scott Bauer, Craig Stancl, Cory Endle, Gilberto Fragoso, Larry Wright, Lyubov, Tracy Safran, Rob Wynne, Kim Ong, Jason Lucas, Liz, Margaret, Bron Kiesler, Sherri De Coronado, Sana Din
Discussion Points:
- EVS REST API
- CTRP and GDC are currently using the API.
- https://evsrestapi.nci.nih.gov/evsrestapi/swagger-ui.html#/evs-controller
- Working with other groups for API usage.
- CTRP in the URL identifies the data being searched. Kim noted that in future it would be coding system and version.
- Modeled specific for the CTRP usecases. Data in the response may have specific CTRP.
- Larry would perfer to have a common API that could then be customized for specific users.
- Suggested to perform a gap analysis to look at what caDSR current uses and what is avaible in the EVS CTRP API.
- Will need to get parameter instances so we can know exactly what is used. (restrict to code/properties, etc)
- This should be reviewed by NG, Tracy, Scott, etc and the caDSR team (Natalia, Vikram, etc.)
- Agreement to have a joint working group to help build a combined REST service to get content from both LexEVS and TripleStore environments
- Minimal testing has been completed (10 concurrent users).
- REST Service Future Direction
- The REST service should not have application specific content.
- There will be a need to consider input from users - caDSR, GDC, CDISC, CTRP
- Sherri suggested that it may be worthwhile to generalize the existing CTRP REST service and then get user feedback.
- Considerations for REST services:
- Keep the CTRP API separate and build a more common API
- Create a common API and provide specific convience APIs on top of the common API for specific customers.
- Fill in the gaps (to be identified) with CTS2 based REST service. Create local extensions and look at opportunities to update the specification.
- Customer needs will come first.
- LexEVS REST (CTS2) and LexEVS Remote Service gap analysis
- Service Discovery - could be created
- Paging and Iteration - no gap
- Entity Search - gaps in search type (LexEVS 6.4 Search Algorithm Implementation Details)
- Result Sorting - gaps exist
- Custom Result Filtering - gap exists
- CTS2 URI Read of Entiy - could be created
- Code System Operations - gap exists
- Entity Count - gap exists
- Relational Operations - gap exists
- Query Parameters - gap exists
- Result Parameters - gap exists
- Operation Functions - gap exists
- Value Set Operations - gap exists
- Value Set Search - gap exists
...
Tracy Safran, Jason Lucas, Rob Wynne, Larry Wright, Gilberto Fragoso, Kumar, Cory Endle, Scott Bauer, Craig Stancl, Lyubov, Margaret Haber, Bron, Sherri de Coronado, Sana Din
Discussion Points:
- 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..)
- Extract mapping from Meta efficiently
- 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.
- Mappings
...
