2019-01-08 Meeting notes

• Mayo to demo tool.  Any support needed?
• The UMLS group is making their mapping tool available and will be showing how to do it with the command line
• Long term - what is the need for the final tool.
  • tiers of increasingly stident matches
  • Only send previously unmapped terms
  • Controlling interface accessing maybe multiple services
  • Steve had collected mapping requirements - do we still have that?  I will look
• Kim will demo new iteration of mapping tool tomorrow

• Access to tech stack plans
• What would need to be migrated simultaneously
  • LexEVS local and remote.  CTS framework
  • RMI Users? Probably
    • Browsers all local but use client jars
• Java compatibility
  
  • lucene to 551
  • package changes, class removals
  • class security tightened

Kim uses the RMI to help development.  Is a cloud server an option to allow us to retire RMI?  Can cloud server be mounted as a local drive?  Is CentOS capable of being mounted as local drive as an alternative?

Last discussion we chatted structure and said it might need a database to store hierarchies of indexes.  Any more thoughts?  Could this be stored itself in TS or does it need relational?

For very specific use case of resolving large hierarchies - graph databases are best. 

Some other types of queries are very fast - Kevin has been working with Arango and OSQL. Calls itself a "multi-model" database.

Text search

Hierarchy resolution

Hierarchy navigation

Mapping

Value Sets

Reporting and exporting

Coding scheme metadata

Filtering return values - entity resolution

Metathesaurus and how to host

The structure likely will be left behind.

Still valid portions can be broken out as microservices, or inform new services

Data model is sound and useful as a terminology service

Metathesaurus to RDF or still supported in LexEVS? Consult with UMLS developers. Us UMLS backend and their API?