First order - Time and date of next meeting - Monday afternoon or Tuesday.  I will send another poll specifically for that day

Goal: 

Reduce duplication of effort and resources.

Determine what our final interface looks like - single service?  Microservices?  Integrated browser suite or mutliple web sites?

Make things easy for the user and for us.

 

Method steps:

  1. What are current assets
    1. What users are we currently serving with each service
    2. What "types" of assets do we have
  2. Where do current assets fall short of what we need
    1. Where do we have assets that aren't utilized or not needed
    2. What is priority of need
    3. What demands are we expecting from the future and new users
  3. What is feasible for the future - determine constraints (including cost)
    1. In short term
    2. In long term
  4. What metrics will we use to evaluate services and usage.
    1. What tools are we missing the would help us gather these metrics

 

Lyubov - wants to see a structure which describes the services.  Has information on the users and their needs and how they are currently being met, and what they might need in the future.  Within each service category we also want technical details - what physical assets are part of it (servers, databases) and what people are working to provide the services. From the user perspective - what services do we not provide.

Gilberto - go bottom up.  At the end do we want a single service.  What are the improvements that need to be done to LexEVS to make it that service.  It already has a lot of our offered services (maps, VS, REST, etc).  What do we need to have a single infrastructure?

Action items:

Tracy - send out poll to determine meeting time for Monday/Tuesday

Tracy / Rob - identify services we use before next meeting

Tracy / Rob - identify services editors use

Jason - list NG products (Term Browser, Metathesaurus Browser, Term Suggestion Application, Report Writer, EVSRESTAPI, SPARQL Report Writer)

Tools and services inventory:

Reporting/Editing Tools:

  1. NCI Report Writer (LexEVS RMI, mySQL DB)
    1. 28 templates supporting
      1. CDRH
      2. CTS
      3. CareLex
      4. FDA
      5. GAIA
      6. GENC
      7. GUDID
      8. ICS
      9. NCI
      10. NICHD
      11. SPL
      12. eStability
    2. standalone Java program to generate ancillary Neoplasm Core formats
  2. Protege
    1. NCI edit tab
    2. Pellet reasoner
    3. Lucene query
    4. Reporting
      1. Export fields based on a Lucene Query
      2. Export fields based on a list of codes
      3. Export a report based on a root concept
  3. FormatProtegeReport (POJO)
    1. Extract terms, defs, properties of interest from a Protege report
  4. GenerateCDISC Java program (OWL API wrapper)
    1. ADaM
    2. CDASH
    3. Glossary
    4. SDTM
    5. SEND
  5. nci-diff-CDISC Java program (POJO)
    1. Changes between CDISC updates
  6. ODM_Converter (Scala)
    1. Format CDISC odm.xml, html, PDF
  7. SPARQL Report Writer

Communications/Publications:

  1. NCI Meta browser https://ncim.nci.nih.gov
  2. NCI terms browser - 
    1. https://nciterms.nci.nih.gov
    2. https://ncit.nci.nih.gov 
  3. CDISC Tracker for new term requests - https://tracker.nci.nih.gov/projects/CDISC/summary
  4. Term Suggestion - https://nciterms.nci.nih.gov 
    1. CDISC Term Suggestion https://ncitermform.nci.nih.gov/ncitermform/?version=cdisc
  5. NCI_Thesaurus email account
  6. Cancer.gov 
    1. https://www.cancer.gov/research/resources/terminology
    2. JIRA https://tracker.nci.nih.gov/browse/
  7. Github issue tracker for Protege https://github.com/NCIEVS
  8. EVS download page - https://cbiit.cancer.gov/evs-download
  9. Wiki
    1. EVS-LexEVS - LexEVS
    2. EVS public - EVS Wiki
    3. EVS private - https://wiki.nci.nih.gov/display/EVSproj
    4. Protege - Protege and NCI Protege
  10. ServiceNow https://service.cancer.gov
    1. Ticketing system for Systems support requests

Operations:

  1. ProtegeKbQA Java program (OWL API wrapper)
    1. 24 tests supporting business rules and quality control of data in Thesaurus baselines
    2. Metrics about Thesaurus data
  2. OWLDiff (OWL API wrapper)
    1. Diff report of two baselines
  3. GenerateOWLAPIInferred (OWL API)
    1. Generate the inferred version of Thesaurus
  4. OWLSummary Java program (OWL API wrapper)
    1. Details report
    2. Summary report
    3. Used for statistics and generation of the MEME config file
  5. OWLScrubber Java program (OWL API)
    1. Remove properties not for publication
  6. Lexical Variant Generation (LVG) (Java suite by NLM)
    1. Replace reserved list of characters with ASCII equivalents
  7. LexEVSCompare Java program (LexEVS RMI)
    1. Matching performed by the editors
  8. TopBraid (COTS)
    1. Conversion of CDISC reports to OWL/RDF
  9. NDFRT_File_Processing (POJO)
    1. Process and post monthly NDFRT files
    2. Process and post monthly SPL files
  10. Wusage - for extracting web usage of EVS related web sites and FTP
    1. https://sitestats.nci.nih.gov
  11. OWL Conversion programs
    1. HGNCtoOWL
    2. CTCAEtoOWL
    3. NDFRTtoOWL
  12. Protege_Baseline_Export (Java)
    1. Export a Protege baseline from the command line (scriptable)
  13. ExtractBranches (OWL API)
    1. Generate branch files from Thesaurus for publication
  14. FormatHistory (POJO)
    1. Generate history files for publication
  15. ValueSetProduction (POJO)
    1. Automate the value set file administration during each baseline
  16. Stardog (COTS)
  17. LexEVS runtime (Java)
    1. Administration of LexEVS

APIs

  1. LexEVS java api
    1. 6.4 (Java 7) - https://lexevsapi64.nci.nih.gov/
    2. 6.5 (Java 8) - https://lexevsapi65.nci.nih.gov/
  2. CTS2 - https://lexevscts2.nci.nih.gov 
  3. EVSRESTAPI https://evsrestapi.nci.nih.gov 
  4. SPARQL
    1. https://sparql-evs.nci.nih.gov/sparql 
    2. https://sparql-evs.nci.nih.gov/ctrp