NIH | National Cancer Institute | NCI Wiki  

  • Created by Unknown User (endlecm), last modified on Sep 18, 2017

 Attendees

NameRolePresent

Safran, Tracy

NIH/NCI [C]x
Wynne, Robert    NIH/NCI [C]x
Ong, Kim L ISx
Lucas, Jason R ISx
Bauer, Scott  Mayox
Stancl, Craig
Mayox
Endle,  CoryMayox

Agenda

 

Discussion of latest VS work

Discussion Points:

  • Published value set property will be published all the way up to prod.
  • VS hierarchy - Added other hierarchies (besides the source asserted value sets).
    • NCIt and NDRFT
  • VS updates - how to determine if one has been updated.
    • We are investigating looking at the history to determine if the VS has changed.

Decision Points:

Discuss usage of new mass value set load feature

Discussion Points:

  • Rob indicated that they are using the mass value set load for loading value sets and resolved value sets.

Decision Points:

Review and prioritize remaining VS issues in the backlog

 

Discussion Points:

  • LEXEVS-1732 - Getting issue details... STATUS
    • VS updates - how to determine if one has been updated.
      • We are investigating looking at the history to determine if the VS has changed.
  • LEXEVS-2965 - Getting issue details... STATUS
    • Need to determine how to resolve these hierarchies quickly/efficiently
      • Possibly use the triple store
      • Or Within LexEVS, use the entities association to entities table
    • What are the requirements?
      • Given Identifier and namespace, we can get these for the end user quickly.
      • For resolved VS, Kim wants an iterator
      • For a hierarchy/graph, for every value set,  Kim needs the parent code, child code and namespace. (we would need to resolve this with the 1 to many relationship in mind - for at least the children.)
        • Scott suggested we would use the entities association to entities table to store this relationship.
  • LEXEVS-2969 - Getting issue details... STATUS
    • The main user that is looking at a hierarchical value sets within CTRP is using EVS API
      • caDSR - would prefer REST to retrieve hierarchical value sets.
    • Neoplasm hierarchy - everything needed for this VS is inside the NCIt.
      • We should discuss priority regarding this item with Larry.
      • Requirements:
      • Subclass of relationships
    • NICHD and CDRH value sets
      • Tracy suggested has NICHD parent and CDRH parent would be good to load as a relationship.
      • Rob suggested it would be nice if the source asserted hierarchy is loaded in LexEVS to be displayed in the browser.
      • Load as a monolithic VS (for performance reasons).
      • Currently loaded with the terminology value set.
      • Scott suggested to load as hierarchies, individually and link them.
    • Browser hierarchy - Kim looks at "is-a relationship" to determine hierarchy.
  • LEXEVS-2968 - Getting issue details... STATUS
  • LEXEVS-3194 - Getting issue details... STATUS
  • LEXEVS-3195 - Getting issue details... STATUS
  • LEXEVS-3195 - Getting issue details... STATUS

Decision Points:

  • Scott will create a JIRA item to improve the transitive table performance during the load.
  
  • No labels