Page History

Discussion Points:

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

Decision Points:

Discussion Points:

• Jira
  server NCI Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 7954a81f-12da-3366-a0ef-97c806660e7c key LEXEVS-1732

  • VS updates - how to determine if one has been updated.
    • We are investigating looking at the history to determine if the VS has changed.

• Jira
  server NCI Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 7954a81f-12da-3366-a0ef-97c806660e7c key LEXEVS-2965

  • 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  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.

• Jira
  server NCI Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 7954a81f-12da-3366-a0ef-97c806660e7c key LEXEVS-2969

  • The main user that is looking at a hierarchical value sets within CTRP is using EVS API
    
    • CTSR 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.