Page History

• Document all services that exist for EVS

• Document Gaps and Overlap of existing services.

• Describe importance of architecture planned services

• Describe need for Architect role.

• Propose possible scenarios for architecture based on services and usage

Discussion Points:

• Remote users currently need to use the client jars. This is a concern for the end users. This could be done by updating CTS2 services and provide REST services to these users.
  • caDSR transition would take awhile
  • In the near term, leave the remote services as-is for them.
  • 
    
• CTS2 supports all the vocabularies (including meta). EVS REST API is limited to Triple Store content using elastic search.
  
• Governance of the services is critical in order to provide one central query mechanism.
• LexEVS will no longer have the stand alone code systems. The Meta will continue to live in LexEVS. There is the possibility for Meta in EVS REST API.
• The NLM does host UTS API. This could be something to look at.
• Sorting and Ranking is important for results, but this isn't available in the EVS REST API yet.
• End users do not have resources to upgrade or the funding. This might be done be the EVS team (rewriting code for interaction layer, etc).
• CTS2 REST results - different than the EVS REST API.
• caDSR and Browser are the primary consumers of APIs.
• Ability for usage analytics - what types of queries being run and what content.
• Infrastructure
  • Cloud
    • FedRAMP - provides information about cloud services.
    • EVS API noted issues with remote API dropping connections when communicating from the cloud.

Decision Points:

• Determine a level of governance and architecture for EVS related services.
• Work with the caDSR team to transition from remote API to REST Services. (TBD?)
• Propose ability to capture usage statistics for analytics of what types of queries are being run, content searched, etc.
• Determine a REST service for Metathesaurus and determine best how to support the end users.
• Continued transition of stand alone coding systems to EVS REST API.
• Transition of LexEVS search knowledge to the EVS API development team
  • utilize the services spreadsheet
• Provide LexEVS resources to help with EVS API.
• Investigate infrastructure considerations (cloud environments?).
• Single Service coverage (provide single search mechanism)
  • REST Service for Meta
  • EVS REST API
  • LexEVS API