Release History

New Features and Updates

DTSRPC V 2.2
Continues to provide legacy support for the caCORE 3.x EVS API.

NCI Thesaurus and MetaThesaurus Browsers
Continues to provide legacy support for the caCORE 3.2 EVS API.

LexEVS
The 4.2 release of LexEVS includes EVS API (based on the EVS 3.2 Object Model) with LexBIG v2.3.0 on the backend).  The EVS API suite includes the caCORE SDK generated interfaces as well as, the Distributed LexBIG (DLB) API.  The 4.2 release also includes the LexEVS 4.2 Grid Service which uses the DLB API to expose the underlying LexBIG interfaces.  

[[GF #12357]]  Loader should allow Presentation properties to be specified
The LexBIG loader currently has a hard-coded list of property names that will be tagged as "Presentation" properties within LexBIG.  Instead, the list of appropriate presentation properties should be set by the manifest.

[[GF #8672]|http://gforge.nci.nih.gov/tracker/?func=detail&group_id=14&aid=8672&atid=137]Allow external configuration of complex properties
Per GForge #8671, additional support is to be added for complex properties (embedded as XML fragments in OWL source as part of the NCI curation process). The initial solution will involve customizing the NCI OWL loader to include enough knowledge to support the sources in caCORE 4.0.

[[GF #13193]|http://gforge.nci.nih.gov/tracker/?func=detail&group_id=14&aid=13193&atid=137]Manifest support on additional loads (RRF, etc) or decoupled from load.
Manifest support on additional loads (RRF, etc) or decoupled from load.

Features:
-    independent of loader
-    tuning of code system metadata
-    could be applied during and after the load

[[GF #8442]|http://gforge.nci.nih.gov/tracker/?func=detail&group_id=14&aid=8442&atid=137]Lazy loading of properties for CodedEntry
Coding scheme data such as URN and Version are available in ResolvedConceptReference, but not in CodedEntry. This may present difficulties in implementing lazy loading of CodedEntry in the future. It is desirable to find the corresponding CodingScheme from CodedEntry itself.

[[GF #13026]] Load both SAB and VSAB data for Meta sources
LexBIG only loads the SAB presentation of a source when loading data from Meta.  We would like to have the VSAB information loaded as well.  The end users want to know what version of the source that they are pulling data from.

[[GF #7891]]Eliminate the dependencies of restriction methods (for example, CodedNodeSet restrictToMatchingProperties) on backend database
To improve the performance of distributed LexBIG, it is desirable that implementation of all restriction methods, such as restrictToMatchingProperties in CodedNodeSet, do not involve database access. Validation of input parameters, in this case, property names, may be performed at the resolve stage.

[[GF #12995]|http://gforge.nci.nih.gov/tracker/?func=detail&group_id=14&aid=12995&atid=137]Add database info to GUI
Incorporate a way to view the dbName in the GUI.  Either a column in the Available Coding Schemes window or a field in the Code System Viewer.  This information is available in the registry.xml and the metadata.xml

[GF#13500] MedDRA Loader
EVS will depend on the UMLS to obtain the version of MedDRA that we serve as a standalone terminology on LexBIG.  A loader for the MedDRA terminology distribution needs to be developed (if necessary).

[GF#13501] HL7 Loader
A LexBIG loader is needed for the HL7 XML format that is used to distribute version 2 and version 3 of the HL7 syntax terminology.

[GF#13565] LOINC Loader
Extend load capability of the existing UMLS Loader to support loading of the LOINC terminology.

[GF#15071] Make copyright statements accessible through LexBIGService, or ConvenienceMethods interface.
Currently, copyright or license statements are accessible through the getCopyright() method of CodingScheme. As a part of the GForge 10884 effort to safeguard licensed ontologies such as MedDRA from unauthorized access, the CodingScheme object currently accessible through the resolveCodingScheme method of LexBIGService would no longer be accessible without a valid authentication token. But, users would need to review copyright statements to understand any restriction on a licensed ontology. Therefore, it is necessary to modify LexBIG code base to make these statements accessible through the LexBIGService, or the ConvenienceMethods interface instead.

[GF#13880] Grid Enablement
The LexBIG API was Grid-enabled as a prototype for the close of the previous Mayo contract.  During the 4.2 timeframe Mayo will extend this prototype to provide a more comprehensive of the LexBIG API and deploy to the NCI environment.

[GF#13881] Expand LexBIG Model
A potion of the LexGRID/LexBIG model was modified and adjusted as necessary to make it compatible with the SDK for the close of the previous Mayo contract.  During the 4.2 timeframe Mayo will extend the SDK Compliant Model.

[GF#13882] Silver Level Compatibility
The process of applying for Silver Level Compatibility of the LexBIG API will be initiated.  A Silver Level Compatibility Submission Package will be created and submitted for review.

Bugs Fixed Since Last Release

[GF#8670 ]  MedDRA SMQ attributes not loaded properly
Standardized MedDRA Query (SMQ) attributes were introduced into the 10.0 release of MedDRA.  There is currently a problem loading this information to LexBIG as association qualifiers.  

[GF #10439]/[GF #10884] MedDRA security needs to be enforced
When searching for concepts against the MedDRA Vocabulary, the Distributed LexBIG API should return null if the user has not input a token using the following provided SecurityToken methods.  Instead it is returning results even when no token is sent.

 

[GF #14252]/[GF #13808] CL CUI -> CUI Mapping Required
To maintain accessibility by client applications that may store and later attempt to access temporary ids assigned by Metathesaurus, mappings need to be established.  A loader needs to be created to load the history information into LexBIG and then the data can be exposed through the LexBIG history service.  The EVS API needs to handle the actual interface between the client application and the history service.

[GF #15437] getCodingSchemesWithSupportedAssociation iterations
A SecurityToken must be passed in along with the URN to correct problems with this method call.

[GF #15474] Make EVSAPI compatible to LexBIG 2.3 Release.
The LexEVS API needs to be updated tyo work with the LexBIG 2.3.0 release.

[GF #16158] Null point exception- LexGrid.LexBIG.Impl.function.query.TestAttributePresenceMatch.matchAttribute.
When running the Junit for EVSAPI we received the following error.

Null point exception- LexGrid.LexBIG.Impl.function.query.TestAttributePresenceMatch.matchAttribute.
The test case is wrong in TestAttributePresenceMatch.matchAttribute line no-73.
need to be changed.

[GF #16291] ResolvedConceptReferencesIterator returning same concept on calling next()
On calling next() method of ResolvedConceptReferencesIterator when resolving a CodedNodeSet, the iterator is returning
the same concept again and again. This seems to be happening only with distributed calls. Attaching two programs making
distributed and local calls.

[GF #16405] MatchRootName preference not recognized on OWL load
The MGED ontology does not declare 'kinds' and therefore root nodes are not detected the same as historic releases of
the NCI Thesaurus.  An xml-based preference file was created to detect the single known root node as follows.  However,
the setting was not recognized.

[GF #16438] Unable to apply manifest post-load
By design, manifest load disallows change to primary coding scheme identifiers (e.g. coding scheme name and registered
name) when applying a manifest to an already loaded scheme.  However, the load should not fail if the identifying information
matches the already loaded scheme.  Currently it is assumed that if the manifest provides the identifiers it is a change
and the load fails.

[GF #16478] Export to LexGrid XML does not recognize menu selection
If using the the command line program and a specific URN and Version are not provided as parameters, the program will
prompt for a coding scheme to export.  However, the coding scheme choice is not recognized after selection.

[GF #17063] EVSQueryDAO getHasChildrenbyCode method fails on NCI Thesaurus root node, Conceptual Entity (C20181).
EVSQueryDAO getHasChildrenbyCode method fails on NCI Thesaurus root node, Conceptual Entity (C20181). It is because
that this concept has two subconcepts both called "Channel" (getEntityDescription().getContent()). The sorting
algorithm needs to be modified to handle such cases.

Known Issues

• Description of the issue including special circumstances and workarounds. Note: Write for the intended audience.
  GF tracker number hyperlinked to the tracker. 

  Indented commentary if needed (example). Continue the previous pattern for each software change.

  CORE Product Dependencies

Refer to the CORE Product Dependency Matrix for the caCORE SDK and other software technologies on which this release of this product relies.