Author: Craig Stancl, Scott Bauer, Cory Endle
Email: Stancl.craig@mayo.edu, bauer.scott@mayo.edu, endle.cory@mayo.edu
Team: LexEVS
Contract: S13-500 MOD4
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services
The purpose of this document is to document the technical face to face meeting details between the NCI and Mayo for the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) LexEVS Release 6.3 and LexEVS Release 6.4 .
2015 December Face-to-Face Meeting Prioritization List
All issues are considered after 6.4 related development.
| 6.4 Priority (1-high 3-low) | Future Priority (1-high, 3-low) | Category | Topic | Notes |
|---|---|---|---|---|
| 1.5 | Tech Catalog | Migrate to centOS 7 | 6.5 Required for better Docker support. | |
| 1 | Tech Catalog | Migrate to Java 8 | 6.5 | |
| 1.5 | Tech Catalog | Migrate to Spring 4 | 6.5 | |
| 2 | Development | Tree Performance - determine requirements and propose solution | Linked to the triple store discussions. | |
| 2 | Development | CTS2 Functionality - Expand to fully support browser | ||
| 1 (implementation) | 1 | Development | CTS2 Functionality - CTRP Support - Determine specific requirements and propose solution (Partonomy, Disease Biomarker, and others) | TBD (early 2016Q2?) |
| 1 (gather requirements) | 2 | Development | LexEVS Model - OWL and RRF Mapping use cases - Determine requirements and propose solution | This would include consulting with Harold Solbrig. Considerations for backward compatibility with suggested changes. Will contribute to the triple store discussion. Implementation would happen after 6.4. |
| 1 (implementation) | Development | Multi-namespace LEXEVS-1386 - Getting issue details... STATUS | Existing JIRA item. | |
| 2 | Development | Multi-namespace - Horizontal navigation - determine requirements and propose solution | May require model change. | |
| 2 | Development | Query - Relationships - determine requirements and propose solution | ||
| 2 | Development | Inferred Data - determine requirements and propose solution | ||
| 2 | Development | Remove caCORE (API artifacts) | Gilberto to verify the removal. | |
| 1.5 | Development | Refactor Remote API | Suggested inclusion with Spring migration | |
| 1 (implementation) | 3 | Development | CTS2 Functionality - Ability to provide complete transitive closure (this includes path(s) to root) | Will support CTRP requirement. |
| 2 | Development | CTS2 Functionality - Ability to restrict to association | ||
| 2 (implementation) | 3 | Development | CTS2 Functionality - Ability to provide history API functionality | May be required for CTRP |
| 3 | Development | CTS2 Functionality - Ability to group value sets together (FDA and SPL) | May require changes to LexEVS and an addition to the browser. | |
| 3 | Development | CTS2 Functionality - Report to OMG the issue pertaining to return all results | ||
| 2 | Development | CTS2 Functionality - Ability to restrict to properties and to matching properties | ||
| 2 | Development | CTS2 - Verify the resolution of subject to and target of relationships is CTS2 compliant and provide the preferred presentation | ||
| 3 | Support | Documentation Updates - review and clean up "LexEVS Code Examples" | ||
| 3 | Support | Documentation Updates - Update CTS2 API documentation | ||
| 2 | Development | Presentation of Value Set and Mapping Data with Hierarchical structure - determine requirements and propose solution. | ||
| 1 | Development | Lucene Implementation - Document query result differences and share with group to decide on solution. | This is part of our 6.4 implementation work. | |
| 1 | Loader | OWL2 - LEXEVS-586 - Getting issue details... STATUS | Gilberto to provide requirements. | |
| 1 | Loader | OWL2 - LEXEVS-1160 - Getting issue details... STATUS | Included as part of OWL2 implementation. | |
| 4 | Loader | MedDRA - Provide comparison of MedDRA loaders to identify differences - determine requirements and propose a solution. | ||
| 3 | Loader | HL7 - LEXEVS-1037 - Getting issue details... STATUS | ||
| 1 | Loader | MedDRA - Close LEXEVS-339 - Getting issue details... STATUS | ||
| 1 | Loader | HL7 - Close LEXEVS-584 - Getting issue details... STATUS | ||
| 3 | Loader | HL7 - Review HL7 website rendering of brach/hierarchy to determine requirements and to propose solution to support HL7 structure. | ||
| 2 | Loader | Load Process Automation - determine requirements and propose a solution. | Includes Rob and Tracy. | |
| 1 | Admin | Review all loader related JIRA issues and remove those that are no longer valid. | ||
| 2 | Loader | MySQL 5.5 Table Locking issue - propose a solution. | Need to create JIRA item. | |
| 2 | Loader | SNOMED - LEXEVS-234 - Getting issue details... STATUS | ||
| 2 | Loader | OWL2 - LEXEVS-347 - Getting issue details... STATUS | ||
| 1 | Loader | Value Set - LEXEVS-459 - Getting issue details... STATUS | ||
| 1 | Loader | CLAML - Close - LEXEVS-535 - Getting issue details... STATUS | ||
| 1 | Loader | Create an OWL2 to LexGrid Model spreadsheet (mapping). | Tracy will lead this | |
| 2 | Development | Triple Store / SPARQL- Clarify the strengths and weaknesses in the tools (Blazegraph, Virtuoso, Stardog) to determine how to best address the browser and LexEVS needs. | This will be led by Kim and Jason. They will share their evaluation with the group to help determine the best approach. | |
| 2 | Development | Review of value set workflow (including resolution) to determine requirements and proposed changes. | ||
| 2 | Development | Review of admin workflow to determine requirements and proposed admin script changes and additions. (to replace using lbGUI) | ||
| 2 | Development | lbGUI - Provide viewing additional metadata in the GUI. |
