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

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.