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.1 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.1 release also includes the LexEVS 4.2 Grid Service which uses the DLB API to expose the underlying LexBIG interfaces.  

GF #17199 - Tag the API classes as deprecated.
Tag EVS API classes as deprecated.

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

GF #14485 - Semantic Net Loader should use SRSTR for association generator
Currently SRSTRE1 RRF file is being used by the Semantic Net loader to generate associations between the concepts. The
associations generated using SRSTRE1 file seems to be very flat and not hierarchical. For example, concept 'Vertebrate'
(T010) is associated to 'Organism'(T001), 'Physical Object' (T072), 'Event' (T071) and 'Animal' (T008) as 'isa'
association.

RRF file SRSTR seems to be having associations in proper hierarchy. Using this file, concept 'Vertebrate' (T010) is
associated only to 'Animal' (T008) as 'isa' association.

So using SRSTR to generate associations between concepts will give a correct hierarchical representation.

GF #15015 - Problem with matching properties
While testing using the fly anatomy ontology in the GUI, I ran into a problem if I search for the word "lateral"
using restrict to matching properties and select all the Match Properties and select all the Property Types. If I unselect
conceptCode from the list of Match Properties, then things work fine.

GF #16155 - Xerces cvc-complex-type.4: Attribute 'isImported' must appear on element 'supportedCodingScheme'.
While testing 2.3.0.Manifest file for the following
HL7_Manifest.
MGED_MF_1.3.1
NSDFRT_june2006_loadmanifest
Thesaurus-Bycode-07.12e_MF
VA_NDFRT_072606_MF
Zebrafish_MF

we received the following error "Attribute 'isImported' must appear on element 'supportedCodingScheme'.

Known Issues

GF #15776 - DLBWrapper.getSupportedCodingSchemes returns null
The DLBWrapper.getSupportedCodingSchemes returns null if any of the codingSchemes in the repository require secure access.
Currently the first vocabulary that it attempts to access is NCI Metathesaurus, which is secured. Remains to be seen
if it will return anything if the secured vocab is not first.

GF #15817 - Inconsistancy in the application of codingScheme name in DLBAdapter.
In the DLBAdapter you can do a .setVocabulary() to set the default codingScheme, version and tag that some queries of
the DLBAdapter will run against. However, this default codingScheme is not consistantly applied.

1. Some methods in DLBAdapter allow you to pass in a codingSchemeName. Of these, some use the passed in codingSchemeName
with a null CodingSchemeVersionOrTag. Others use the passed in codingSchemeName plus the version or tag passed in as
the default in .setVocabulary.
2. Some methods with no parameters automatically use the defaults. Others don't.

Deferred/Deprecated Items

As the EVS Team looks toward the next major release of LexEVS (v5.0), we have begun to anticipate functionality that will naturally be absorbed by the LexBIG API. Those items have
been classified as deprecated in our GForge tracking system. Additionally, those items that have not been evaluated has high priority items, have been deferred to the 5.0 release.
These items/trackers can be view here.

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.