Programmers access coded concepts by acquiring first a node set or graph. After specifying optional restrictions, the nodes in this set or graph can be resolved as a list of ConceptReference objects which in turn contain references to one or more Concept objects. The following example provides a simple query of concept codes:
The LexEVS system maintains service metadata which can provide client programs with information about code system content and assigned copyright/licensing information. Below is an brief example showing how to access and print some of this metadata:
One of the most powerful features of the LexEVS architecture is the ability to define multiple search and sort criteria without intermediate retrieval of data from the LexEVS service. Consider the following code snippet:
Attempts to provide a tree, based on a focus code, that includes the following information:
This example accepts two parameters... The first parameter is required, and must contain at least one code in a comma-delimited list. A tree is produced for each code. Time to produce the tree for each code is printed in milliseconds. In order to factor out costs of startup and shutdown, resolving multiple codes may offer a better overall estimate performance.
The second parameter is optional, and can indicate a hierarchy ID to navigate when resolving child nodes. If not provided, "is a" is assumed.
Displays a list of available coding schemes.
Example showing how to find codes matching descriptive text. The program accepts up to two parameters...
The first param (required) indicates the text used to search matching descriptions. Matches are determined through a customized match algorithm, which uses a simple heuristic to try and rank returned values by relevance.
The second param (optional) indicates the type of entity to search. Possible values include the LexGrid built-in types "concept" and "instance". Additional supported types can be defined uniquely to a coding scheme. If provided, this should be a comma-delimited list of types. If not provided, all entity types are searched.
Example: FindCodesForDescription "blood" Example: FindCodesForDescription "breast cancer" "concept"
Example showing how to find the entity description assigned to a specific code. The program accepts one parameter, the entity code.
Example showing how to find concept properties and associations based on a code.
Example showing how to find all concepts codes related to another code with distance 1.
Example showing how to find all concepts codes related to another code with distance 1, plus the Property Link relations.
Example showing how to find all endpoints of a named association for which the given term matches as source or target.
Note: the match algorithm applied to the term is the standard lucene query syntax.
Example showing any source-asserted hierarchies (based on import of MRHIER HCD) for a CUI. The program takes a single argument (the UMLS CUI), prompts for the code system to query in the LexGrid repository, and displays the available hierarchical relationships.
Example showing how to determine and display an unsorted list of root and subsumed nodes, up to a specified depth, for hierarchical relationships.
This program accepts two parameters:
The first parameter indicates the depth to display for the hierarchy. If 1, nodes immediately subsumed by the root are displayed. If 2, grandchildren are displayed, etc. If absent or < 0, a default depth of 3 is assumed.
The second parameter optionally indicates a specific hierarchy to navigate. If provided, this must match a registered identifier in the coding scheme supported hierarchy metadata. If left unspecified, all hierarchical associations are navigated. If an incorrect value is specified, a list of supported values will be output for future reference.
BACKGROUND: From a database perspective, LexBIG stores relationships internally in a forward direction, source to target. Due to differences in source formats, however, a wide variety of associations may be used ('PAR', 'CHD', 'isa', 'hasSubtype', etc). In addition, the direction of navigation may vary ('isa' expands in a reverse direction whereas 'hasSubtype' expands in a forward direction.
The intent of the getHierarchy* methods on the LexBIGServiceConvenienceMethods interface is to simplify the process of hierarchy discovery and navigation. These methods significantly reduce the need to understand conventions for root nodes, associations, and direction of navigation for a specific source format.
Example showing how to determine and display the hierarchical relationships for a specific code, ancestors or descendants, within a fixed distance.
This program accepts two parameters, indicating the code and distance. The first parameter is the code (required). The second parameter is the distance (optional). If 1, immediate children are displayed. If 2, grandchildren are displayed, etc. If absent or < 0, all downstream branches are displayed.
BACKGROUND: From a database perspective, LexBIG stores relationships internally in a forward direction, source to target. Due to differences in source formats, however, a wide variety of associations may be used ('PAR', 'CHD', 'isa', 'hasSubtype', etc). In addition, the direction of navigation may vary ('isa' expands in a reverse direction whereas 'hasSubtype' expands in a forward direction.
The intent of the getHierarchy* methods on the LexBIGServiceConvenienceMethods interface is to simplify the process of hierarchy discovery and navigation. These methods significantly reduce the need to understand conventions for root nodes, associations, and direction of navigation for a specific source format.
Example showing how to determine and display an unsorted list of root and subsumed nodes, up to a specified depth, for hierarchical relationships. It is written specifically to handle display of relationships for a designated source within the NCI Metathesaurus.
This program accepts two parameters. The first indicates the depth to display hierarchical relations. If 0, only the root nodes are displayed. If 1, nodes immediately subsumed by the root are also displayed, etc. If < 0, a default depth of 0 is assumed.
The second parameter must provide the source abbreviation (SAB) of the Metathesaurus source to be evaluated (e.g. ICD9CM, MDR, SNOMEDCT).
Example showing how to determine and display paths from a given concept back to defined root nodes through any hierarchies registered for the coding scheme.
This program accepts one parameter (required), indicating the code to evaluate.
BACKGROUND: From a database perspective, LexBIG stores relationships internally in a forward direction, source to target. Due to differences in source formats, however, a wide variety of associations may be used ('PAR', 'CHD', 'isa', 'hasSubtype', etc). In addition, the direction of navigation may vary ('isa' expands in a reverse direction whereas 'hasSubtype' expands in a forward direction.
The intent of the getHierarchy* methods on the LexBIGServiceConvenienceMethods interface is to simplify the process of hierarchy discovery and navigation. These methods significantly reduce the need to understand conventions for root nodes, associations, and direction of navigation for a specific source format.
Example how to query stored metadata for a code system. For the example, use the LoadSampleMetaDataData.bat to load the required code system and metadata.
Example attempting to approximate some characteristics of the Metaphrase search algorithm. However, full Metaphrase compatibility is not anticipated.
Requires loading valid scheme (must have root node named @ pointing to top nodes) Profiles a coding scheme based on unique URN, version, relation and scheme name.
Note: If the URN and version values are unspecified, a list of available coding schemes will be presented for user selection.
Used to wrap scored results for consumption as a standard ResolvedConceptReferenceIterator.
Used to manage and sort search results based on a scoring algorithm.
Example showing a simple scoring algorithm that evaluates a provided term against available terms in a code system. A cutoff percentage can optionally be provided.
Example showing how to list concepts with presentation text that 'sounds like' a specified value.
Utility functions to support the examples.