 |
Page History
...
| Discussion Points | Notes |
|---|---|
| Who are the stakeholders and end users of value sets | FDA, CDISC, and others is only through files. Otherwise this is through the editors who write value sets into the NCIt. They are browser users, and users of the ReportWriter. (LexEVS supports these) caDSR, CTRP, Cancer.gov site developers. |
| Define what work flow end user interface is (Shell script, Rest Service, Browser based GUI) | Shell script is acceptable |
Define performance or other considerations require a move to triple store or OWL API (For Example: Do value sets need full OWL expressivity) In particular do we need reification for end users so that we can understand whether queries or API's need triple store or OWL API support. | 2017.04.24 VS Arch. Meeting - Gilberto and Larry would have to answer this question. This remains an open question following last Wednesday's meeting. |
| Will non NCIt sourced value sets continue to use legacy value set definitions? (more a scope statement question) Yes. | Resolved and see notes above. At this point yes. |
| What considerations/requirements drive the development of an architecture that encompasses hierarchical value sets and new resolution mechanisms? | Should be able to see these as hierarchies in the browser. We need an extension for hierarchical value sets. Loading and expressing through an API. Some value sets will be in the hundreds of concepts. At least one is 8000 members large. Flavors of Hierarchical Value Sets: Source to Target Association Value Sets NICHD parent values sets. Association is read out and generates an external file. CDRH parent value sets. Association is read out to an external file. SubClassOf Based Value Set Neoplasm. Also subClassOf, is now a flat list. Should be hierarchical. Alternative Value Sets: Source to Target that are transitive restrictions found inside the thesaurus. Anatomical_Structure_is_Physical_part of is an example.
LexEVS will provide an extension that loads these value set use cases as value set coding schemes with their own relational assertions. Whether this is a coding scheme or coding schemes is an open question. (Requirement)
|
| Create OWL source for some/all values sets from LexEVS api or other source? (OWL export of value sets) | Performance based consideration, but not a requirement. |
| What user needs around the report writer generate requirements for LexEVS or the LexEVS team | No requirements for this – moving to sparql |
| Does Excel spread sheet generation fall into the scope of LexEVS value set resolution or otherwise generate requirements for the LexEVS team | Not our concern |
| Do the users/stakeholders in the value set API have any new requirements beyond those already stated | Better, more tailored result sets from CTS2 Rest. Not a value set requirement. |
| What does it mean, in terms of requirements, to provide support for Neoplasm like value sets (Hierarchical) | See above |
