This page is for capturing the discussion around updating the workflow for value set definition creation.
Observations
- LexEVS model and implementation are more complex than requirements of most NCI value sets
- NCI Thesaurus may have enough assertions to adequately describe value sets without external modeling
Meeting Minutes
Value set requirements gathered through meetings with the NCI stakeholders. Minutes from the meetings are here:
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.01.06
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.01.09
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.01.19
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.02.21
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.03.02
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.03.27
- LexEVS Meeting Minutes - Value Set Architecture Planning Session - 2017.04.24
Requirements
Requirements for the new value set work flow architecture
| Requirement | Priority | Notes |
|---|---|---|
Better logging to help determine if there were any failures for resolving the 760+ value sets. | ||
| Resolving all 760+ value sets should be able to finish over night (Rob). | ||
leafOnly=false
| 2017.04.24 VS Arch. Meeting | |
| Proposed or Possible Requirement | Priority | Notes | Is Requirement? (Yes/No) |
|---|---|---|---|
| Remove Dependency on Value Set Definitions for NCIt defined Value Sets | |||
| Generate All NCIt sourced Value Sets from NCIt source. | |||
| Resolve discrepancies between number of value set definition files and value sets defined in NCIt | |||
| Provide acceptable substitutions for value set URI's and other metadata that is not defined in the source (List in other rows as necessary) | |||
| Maintain Resolved Value Set Coding Scheme API as interface | |||
Provide concurrent value set loading capability | |||
Provide programmatic Access to value set definition XML files | |||
Provide example code for regular api level access (CodedNodeGraph example) of value set members | |||
Provide support for Neoplasm like value sets (Hierarchical) | |||
| Do we need to define A8 every time ... | |||
| Discussion Points | Notes |
|---|---|
| Who are the stakeholders and end users of value sets | |
| Define what end user interface is (Shell script, Rest Service, Browser based GUI) | |
Define performance or other considerations that require a move to triple store or OWL API (For Example: Do value sets need full OWL expressivity) | |
| Will non NCIt sourced value sets continue to use legacy value set definitions? (more a scope statement question) | |
| What considerations/requirements drive the development of an architecture that encompasses hierarchical value sets and new resolution mechanisms? | |
| Create OWL source for some/all values sets from LexEVS api or other source? (OWL export of value sets) | |
| What user needs around the report writer generate requirements for LexEVS or the LexEVS team | |
| Does Excel spread sheet generation fall into the scope of LexEVS value set resolution or otherwise generate requirements for the LexEVS team | |
| Do the users/stakeholders in the value set API have any new requirements beyond those already stated | |
| How to identify identical VS for different agencies. They need different URIs. | 2017.04.24 VS Arch. Meeting - There is information of the agency is in the annotation on that concept. This information can be used to create the unique URI that represents the agency |
Open Questions
Questions that need further research or consideration.
| Open Questions |
|---|
