Page History
"
Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Single Database Table vs. Multiple Database TablesLexEVS 6.0 will include an option to load CodingSchemes into a single, common set of tables, or individual sets of tables for each CodingSchemes. Some considerations for each option:
To the underlying API, the actual table that data is stored in will be abstracted. All queries will except a Prefix -- whether that prefix is from the common table, or from an individual table, the query remains the same. The prefix will be stored in the registry table of the database. The prefixed is then obtained given a CodingScheme URI and Version. Every CodingScheme will be loaded in the Registry, and the prefix will be retrievable given its URI and Version. Prefixes are automatically injected into SQL statements to direct the SQL to the appropriate table. For instance:
Prior to the execution of the SQL statement, the '$prefix$' placeholder will be replaced with the actual prefix retrieved from the Registry. Loader Post ProcessorIn order to facilitate extra Processing at the end of an Ontology load, LexEVS 6.0 will support Loader Post Processors. A Loader Post Processor is logic that will be executed when the actual content load to the database is complete, but before the Lucene Indexing occurs. It will be implemented as an Extension - meaning that users may place jars in the LexEVS class path and introduce Loader Post Processors without the need to recompile. The Loader Post Processor interface is straightforward:
A Loader Post Processor may apply any logic that is required -- there are not constraints as to the scope. A Loader Post Processor may update database content, delete content, reference other loaded ontologies, etc. An example Loader Post Processor is shown below -- this example will update the Approximate Number of Loaded Entities field of a Coding Scheme:
Value Set DefinitionValue Set Definition with in the LexGrid logical model defines the contents of Value Set. The contents are concept codes defined in referencing Code System. Value Set can contain concept codes from one or more Code Systems. Compared to ISO 11179 model:The LexGrid "value set definition" is analogous to the 11179 enumerated conceptual domain. We support the notion of an intrinsically defined enumerated domain, so the 11179 enumerated conceptual domain is really the output of the resolve value set definition function. Value meanings are identified by entity codes within a given code system. The mapping between permissible values and value meanings is currently accomplished via a mapping association, where we treat the set of permissible values as a "mini code system". An example of how this might work is that HL7 has a set of permissible values of "M", "F", "U", which are in the administrative gender "code system". In the pure HL7 context, these might well map to the equivalent value meanings identified by "M", "F" and "U". If, however, we were using, say, the UMLS as a source of meaning, the same codes would map to the corresponding UMLS CUIs. Compared to HL7 Value Set:The term "value set", when discussed in the context of HL7 can be somewhat ambiguous. There are at least three related artifacts that are sometimes called "value sets", including 1) a definition or algorithm that, when interpreted, produces a set of concept codes, 2) the actual set of concept codes that result from the execution of a the definition or algorithm, and 3) a subset of this set of concept codes coupled with appropriate designations and identifying information. For this reason, the LexEVS model uses the names "value set definition", "value set resolution" and "pick list definition", "pick list resolution" respectively to represent the three different senses of "value set" described above. Value Set Definition logical modelValue Set Definition logical model descriptionValue Set DefinitionA definition of a given value set. A value set definition can be a simple description with no associated value set entries, or it can consist of one or more definitionEntries that resolve to an enumerated list of entityCodes when applied to one or more codingScheme versions. Attributes of Value Set Definition : Value Set Definition EntryA reference to an entry code, a coding scheme, entity code property name or value, or another value set definition along with the instructions about how the reference is applied. Definition entries are applied in entryOrder, with each successive entry either adding to or subtracting from the final set of entity codes. Attributes of Value Set Definition Entry : Coding Scheme ReferenceA reference to all of the entity codes in a given coding scheme. Attributes of Coding Scheme Reference : Value Set ReferencesA reference to the set of codes defined in another value set definition. Attributes of Value Set Reference : Entity ReferenceA reference to an entityCode and/or one or more entityCodes that have a relationship to the specified entity code. Attributes of Entity Reference : Property ReferenceA reference to a propertyName or propertyValue and matchAlgoritm to use. Attributes of Property Reference : Property Match ValueProperty match value to be used to restrict entity property. matchAlgorithm can be used in conjunction to get matching entity properties. Attributes of Property Match Value : Definition OperatorThe description of how a given definition entry is applied. Attributes of Definition Operator : Possible forms of Value Set Definitions
Definition of the Value Set could be as simple as specifying just individual concept codes or specifying to include all the children of concept 'Body Structure' from Code System 'SNOMED CT' to complex definition containing multiple rule sets. Here are some fictitious examples of Value Set DefinitionsExample 1
Example 2
Value Set Definition Resolution
Value Set Definition VersionsValue Set Definitions are versioned. The version of Value Set Definition changes when ever the definition is changed, it could be adding or removing Code System reference or changes in the rule set. Value Set ServicesLexEVS Value Set Services is an integral part of LexEVS Core API. It provides:
Major functions provided by Value Set Definition Services
Refer to Revision section of this document for information on how revisions can be applied and how LexEVS handles them. CTS 2 specific Value Set ServicesCTS 2 specification uses term "Value Set" which is basically LexEVS implementation of "Value Set Definition". Though, CTS 2 implementation functions uses term "Value Set", internally, the LexEVS Value Set Definition Services are used. CTS 2 specification contains several Value Set specific profiles as described in the above High Level Architecture section. All of these functions can be called using CTS 2 interface as described in the above High Level Architecture section. Here are CTS 2 profiles specific to Value Sets:
Load ScriptsScripts to load Value Set Definitions into LexEVS system will be located under 'Admin' folder of LexEVS install directory. This loader scripts will only load data in XML file that is in LexGrid format. Value Set Definition LoaderLoadValueSetDefinition.bat for Windows environment and LoadValueSetDefinition.sh for Unix environment.
Example:
Pick List DefinitionAn ordered list of entity codes and corresponding presentations drawn from a resolved value set definition. Pick List Definition logical modelHere is a UML representation of Pick List Definition with in LexGrid 201001 model : Pick List Definition logical model descriptionPick List DefinitionAn ordered list of entity codes and corresponding presentations drawn from a resolved value set definition. Attributes of Pick List Definition : Pick List Entry NodeAn inclusion (pickListEntry) or exclusion (pickListEntryExclusion) in a pick list definition Attributes of Pick List Entry Node : Pick List EntryAn entity code and corresponding textual representation. Attributes of Pick List Entry : Pick List Entry ExclusionAn entity code that is explicitly excluded from a pick list. Attributes of Pick List Entry Exclusion: Possible forms of Pick List Definitions
Here are some fictitious examples of Pick List DefinitionsExample 1
Example 2
Pick List Definition VersionsPick List Definitions are versioned. The version of Pick List Definition changes when ever the definition is changed, it could be changing, adding or removing pickListEntryNode. Pick List ServicesLexEVS Pick List Services is an integral part of LexEVS Core API. It provides:
Major functions provided by Pick List Services
Refer to Revision section of this document for information on how revisions can be applied and how LexEVS handles them. CTS 2 specific Pick List ServicesThere are NO functional specifications specific to Pick List in CTS 2 SFM. Load ScriptsScripts to load Pick List Definitions into LexEVS system will be located under 'Admin' folder of LexEVS install directory. This loader scripts will only load data in XML file that is in LexGrid format. Pick List LoaderLoadPickList.bat for Windows environment and LoadPickList.sh for Unix environment.
Example:
Password EncryptionEncryption is the process of taking data (called cleartext) and a short string (a key), and producing data (ciphertext) meaningless to a third-party who does not know the key. Decryption is the inverse process: that of taking ciphertext and a short key string, and producing cleartext. LexGrid utilizes the java security API for encryption and decryption of the database passwords. The Security API is a core API of the Java programming language, built around the java.security package (and its subpackages). This API is designed to allow developers to incorporate both low-level and high-level security functionality into their programs. The Java Cryptography Architecture encompasses the parts of the Java 2 SDK Security API related to cryptography, as well as a set of conventions and specifications provided in this document. It includes a "provider"architecture that allows for multiple and interoperable cryptography implementations.Encryption/Decryption implementation Details:Creating a Cipher ObjectCipher cipher = Cipher.getInstance("PBEWithMD5AndDES"); "PBEWithMD5AndDES" is the widely used algorithm used for the encryption process. Other available algorithms are "PBEWithHmacSHA1AndDESede", "AES", "Blowfish", "DES", "DESede" etc. Anchor | InitaCipher | InitaCipher | Initializing a Cipher Objectcipher.init(<MODE>, <KEY>, <PBEParameterSpec>);
Anchor | EncrDecr | EncrDecr | Encrypting and Decrypting Data cipherBytes = cipher.doFinal(<text to encrypt/decrypt>); Passwords in LexEVS are encrypted /decrypted in one step (single-part operation) by passing the text to encrypt/decrypt as a parameter. Following are the steps to encrypt the password of LexEVS database.
XML ExportXML exporter exports the LexEVS6 contents (coding scheme and components) from LexEVS database to an XML file. The output XML file will be a valid LGXML file. The process of extracting content from LexEVS is done by using LexEVS 6 APIs.The exporter will also have the ability to export a subset of coding scheme content. Users will be able to provide criteria that will determine what content is returned. An example would be to export only associations. The exporter will stream the content from LexEVS to the XML file. This will allow for large ontologies to be exported. Right now the design to accomplish this is as follows:
Figure 1 Note in Figure 1, we show two Listeners. These may be combined into a single listener that will contain both the CodedNodeGraph and CodedNodeSet objects. In Addition to this we plan to develop JUnits and other auxiliary set of resources that will be make it ready to be hooked up to DOA layer when ready. Finally, documentation will be provided to explain how to supply filtering criteria to the exporter. Authoring SolutionsLexEVS API and LexGrid model have been designed to provide capabilities to make changes to the terminology elements such as code system or value sets. However, the current LexGrid architecture and model is based on the premise that the information being provided is valid and consistent and is not designed to support partially formed artifacts such as concepts without associated codes, associations that have a source but no target, etc. LexGrid versioning modelLexGrid versioning model description
LexGrid versionable entriesAuthoring can be performed on all the versionable entries in LexGrid logical model. Here is the LexGrid model showing all the versionable entries: LexGrid versionable entries description
Authoring LexGrid non-versonable entries:LexGrid model entries like 'source', 'usageContext', etc which are not versionable, can also be modified but only in context with its parent entry. And also, any values to these attributes will be totally replacing the existing values. For example, if a coded concept 'abc' has a source 'company A, company B' and if the source 'company B' needs to be replaced by 'company C' but keep 'company A' as it is, we will need to pass in both source 'company A, company C' within concept 'abc' and have the changeType as 'MODIFY' for this concept. LexEVS Authoring Architecture:LexEVS Authoring API can accept changes to the terminology contents only in the form of:
The diagram below shows the architecture of LexEVS authoring environment. LexEVS Authoring process:Important: Before the changed terminology content is sent to LexEVS Authoring API to process, the client application should make sure that the contents are valid.
The intent of the change requests are as follows:
Here is an example xml file containing changed coding scheme: H2. Querying data based on version information:
H3. Query data based on revision identifier: Example: In the above example, coding scheme 'CS1' is revised in 4 different instances R1, R2, R3 and R4 at respective dates. The query API will be able to provide the states of the versionable elements at different revisions. Example, API will be able to return the state of concept 'C1' at revision R2. Query data based on specific date and time:This allows users to get the state of an entity like concept code, coding scheme, pick list etc, at the give date and time. Example: CTS 2 Authoring profile:The CTS2 SFM calls for the ability to create, maintain and update code systems, concepts, and associations as separate entities. The LexGrid and LexEVS model views all three of them as aspects of code systems, and its incremental revision approach allows any or all of them to be changed as a single unit. The LexEVS model also subsumes the notion of a "code system supplement", as a collection of one or more revisions to a code system can be packaged as a "system release", with its own provenance, activation dates, etc., and can be applied to external code systems independently. The Terminology Authoring Profile is intended to provide the capability to robustly query and access terminology content, as well as directly modify the terminology content. This includes the ability to modify code system content, value set content, as well as the metadata pertaining to each. This profile includes the functions necessary to administer and search terminology content as outlined in the CTS2 Query Profile as well as the Terminology Administration Profile. Below is the list of Authoring profiles as in CTS2 SFM:
|