NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Old Version 1

changes.mady.by.user Unknown User (stanclc)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (wileyal)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Scrollbar
iconsfalse

Page info
title
title

Panel
titleContents of this Page
Table of Contents
minLevel2

...

Panel
titleDocument Information

...

Author:

...

Craig

...

Stancl

...


Email:

...

Stancl.craig@mayo.edu

...


Team:

...

LexEVS

...


Contract: CBITT BOA Subcontract# 29XS223
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services

Revision History

Version

Date

Description of Changes

Author

1.0

5/14/10

Initial Version Approved via Design Review

Team

Solution Architecture

Proposed technical solution to satisfy the following requirements:

  • Provide support for Value Sets.
  • Develop within LexEVS the ability to provide local extensions to code sets and maps among code sets.
  • Develop within LexEVS other capabilities called for in the CTS2 Specification.

Required CTS 2 Functionality

The required LexEVS functionality to support CTS2 addresses several broad categories.

Administrative Operations

Import Operations The CTS2 SFM calls for the ability to import code systems, code system revisions, value set versions and association versions. The current LexEVS model does not differentiate between the importation of a complete code system and an incremental update in the form of a code system revision, but the functionality is sufficient to fully meet the requirements of both operations. Note, however, that the incremental update functionality of LexEVS has not been fully implemented as of version 5.1, and will be completed in order to meet these requirements. The import of association versions will be also be absorbed as part of the code system revision functionality. The current LexEVS implementation already supports the import of value domain definitions, although incremental updates have not been implemented and will be provided.

Export Operations The CTS2 SFM calls for the ability to export code systems, associations and value sets. The current LexEVS implementation supports the ability to export complete code systems in LexGrid XML and OBO formats. At the moment, it does not support the ability to export value domain definitions or pick lists which will be provided. The CTS2 SFM also calls for the ability to provide filter criteria in the exports although the use and functions of such filters are not totally clear.

While the SFM does not spell a minimal set of export requirements, we believe that it will be necessary to support LexGrid XML and RDF / OWL. We also believe that there are use cases that will require the ability to export a set of changes as a "delta" from a previous version - a set of changes that can be applied to another image that will supply the appropriate update.

Code System Status Changes The current LexEVS implementation already supports a superset of this functionality.

Notification While the need to support notification has been anticipated in the current LexGrid architecture, it has not been completely modeled or implemented. Analysis, however, has identified a set of requirements that extend beyond the basic ones identified in the CTS 2 SFM. As an example, a use case was identified where an administrator needed to be notified when the contents of a concept that was referenced by a value set changed.

Architectures and corresponding implementations for notification and event generation already exist. While it will be necessary to tie these events in to the LexEVS implementation, we do not plan to implement any of the notification tooling directly but, instead will implement it in such a way that it can be tied into a standards compliant event and messaging architecture.

Search and Query Operations

Code Systems LexEVS already implements a superset of the code system search and access requirements with the exception that search criteria and the "query control" aspects are combined as a single operation.

Value Sets The CTS2 SFM calls for the ability to list value sets, return value set details and list value set contents. It also calls for a determination of value set subsumption and queries about concept membership. The current LexEVS implementation supports all of these functions with the exception of value set subsumption. It should be noted, however, that there are two possible interpretations of "subsumption" - an extensional and intensional subsumption. Testing extensional subsumption determines whether one value set subsumes another based on their current resolutions. Testing extensional subsumption, however, is more difficult, as it involves the determination whether subsumption is necessary. We intend to postpone subsumption pending further clarification of the use case.

Concept Domains and Usage Contexts The HL7 notion of "Concept Domain" was originally architected to align with the ISO 11179 Enumerated Conceptual Domain. It has since evolved, however, to be a more abstract entity that, if anything, is closer to the ISO 11179 Data Element Concept. The CTS SFM shows the role of Concept Domain as coupling a value set with a set of designations. While LexEVS supports this particular functionality through pick list implementation, we are not certain that this model will meet all of HL7's needs, as HL7 Edition 3 views concept domains as controlling the coupling of data elements with particular enumerated conceptual domains. We intend to model concept domain, usage context and jurisdictional domain as code system entities instead of making them first class model elements. The concept domain binding and concept to concept domain functionality is partially implemented in the LexEVS pick list model, but additional modeling and development will be done to provide the full functionality required by the SFM.

Association Related Queries The CTS2 SFM calls for the ability to enumerate associations, compute the transitive path between two concept codes, determine whether one coded attribute is subsumed by another and return the details of an association. Some of the requirements are a bit unclear on whether they are calling for the ability to query association types or the actual set of associations (relation) coupled with the type. LexEVS provides a rich set of functionality to perform the latter and provides all of what we believe to be necessary to support the former.

Full subsumption queries imply the use of a reasoner. We see this as a non-trivial task, as the different terminologies are based on different types of description logics and, even within the same family of description logic there are different algorithms that can produce different results based on completeness requirements. The LexEVS package does not currently support (a) reasoners and (b) the ability to supply a pre-coordinated expression as either the input or output of a function. We will postpone the implementation of compositional expression pending the clarification of whether LexEVS can or should support formal reasoning.

Authoring and Curation Operations

"Authoring" and "incremental update" are closely related notions, but there is an important distinction between them. Incremental update, as specified in the current version of the LexEVS model, assumes that any set of changes will transform the underlying entity (code system, value domain, pick list) from one consistent state to another. Authoring, however, requires an additional ability to save entities in states that are neither valid nor complete. 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.

It is assumed that there is an external authoring tool that persists partially formed content and performs the necessary validation and reasoning tasks prior to their being incrementally loaded into the LexEVS services. We see this as being a necessary separation, as the potential combination of editors, reasoners, terminology models, etc. is almost limitless, and each of these will have its own requirements when it comes to completeness and validity.

Code System Authoring and Curation 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.

High Level Architecture

Structure of the CTS 2 Service

The CTS 2 specification defines several functional profiles which are a focused subset of the functionality of a CTS 2 implementation. Functional profiles are defined to subset a group of operations which must be supported in order to claim conformance to the profile.

The following functional profiles are considered in scope for LexEVS 6.0:

CTS 2 Query Profile

  • Searching and querying terminologies
  • Provide access to terminology content and representational structures (description logic) consistent with the terminology author's intent.

Terminology Administration Profile

  • Restricting administrative access
  • Obtaining and loading terminologies
  • Maintaining terminology access
  • Control Content Access

Terminology Authoring Profile

  • Functional terminology analysis/query
  • Direct terminology edits

Each profile specifies the minimal functional coverage as represented in the following tables.

CTS 2 Query Profile

Function

Description

List Code Systems

The ability to provide a listing of the available code
systems that meet input search criteria.

Return Code System Details

The ability to retrieve a specific code system attributes
(synonyms, associations) and other metadata.

List Code System Concepts

The ability to retrieve a list of all of the concepts,
with associated attributes (synonyms, associations) and other metadata that
meet input criteria.

Return Concept Details

The ability to retrieve a specific concept, with
associated attributes (synonyms, associations) and other metadata.

List Value Sets

The ability to determine what value sets are available to
a Terminology Service. This includes seeing a listing of the available value
sets that match some search criteria, as well as the details pertaining to
each value set available to the terminology service.

Return Value Set Details

The ability to retrieve a specific value set, with
associated attributes and other metadata.

List Value Set Contents

The ability to see a listing of specific concepts, as well
as the details pertaining to each concept in any of the given value sets
available to a terminology service.

Check Concept Value Set Membership

The ability to validate that a given concept exists in a
given value set.

List Concept Domains

The ability to determine what concept domains are
available to a Terminology Service.

Return Concept Domain Details

The ability to retrieve a specific concept domain, with
associated attributes and other metadata.

List Concept Domain Bindings

The ability to see a listing of specific value sets that
are bound to a concept domain in specified usage contexts.

Check Concept Domain Membership

The ability to validate that a given concept code is bound
to a given concept domain.

List Usage Contexts

The ability to determine what usage contexts are available
to a Terminology Service.

Return Usage Context Details

The ability to retrieve a specific usage context, with
associated attributes and other metadata.

List Associations

The ability to determine what associations are available
on the terminology service by browsing a list of available associations on
the CTS 2 instance that meet specified search criteria.

Return Association Details

The ability to retrieve metadata on available associations
in the CTS 2 service instance.

List Association Types

Returns the details for the known attributes (metadata) of
a coded concept

Return Association Type Details

The ability to return all information for a Association
type.

Check Value Set Subsumption

Determine whether one of the two supplied value sets
subsumes the other

Check Concept to Concept Domain Association

Determine whether the supplied coded concept exists in a
code system in use for the specified concept domain, optionally within
specific usage contexts.

Determine Transitive Concept Relationship

Determine whether there exists a transitive relationship between two
concepts

Compute Subsumption Relationship

Determine Whether One Concept Subsumes a Second

Terminology Administration Profile

Function

Description

Import Code System

Terminology content would be loaded into the terminology
server as an entire terminology load or skeleton load (i.e. load of structure
without loading the nodes).

Import Code System Revision

Terminology content would be loaded into the terminology
server as a delta or set of changes from the previous version of the
terminology.

Import Value Set Version

Ability to import values sets

Import Association version

Ability to import Associations

Export Association

Ability to export Association Type instances

Export Code System Content

Terminology content would be exported either in whole or
in part based on filtering against terminology properties. The export format
may also be specified.

Change Code System Status

Terminology content status would be changed, thus changing
its availability for access by other terminology service functions.

Register for Notification

A client registers for notification so that an electronic
notification would be sent to subscribed users in the event of a change to
the specified terminology element.

Update Notification Registration

Subscription notification information can be updated for a
subscriber's notification account.

Update Notification Registration Status

Updates the status of a notification registration.

Terminology Authoring Profile

Function

Description

Create Code System

The ability to create a new Code System to contain a set
of new coded concepts. The Code System is created by defining the set of
meta-data properties that describe it.

Maintain Code System Version

The ability to maintain the content and metadata of a
version for a code system.

Update Code System Version Status

The ability to modify the status of a code system.

Create Concept

The ability to define and add a new concept to a code
system.

Maintain Concept

The ability to modify a concept that exists in a code
system.

Update Concept Status

The ability to modify the status of a concept that exists
in a code system.

Create Value Set

The ability to create a dynamic value set that is defined
by a computable expression that can be resolved to an exact list of coded
concepts at any given point in time.

Maintain Value Set

Update properties or expression of a value set definition
(extensional and intensional value sets).

Update Value Set Status

The ability to modify the status of a value set.

Create Concept Domain

The ability to define and add a new concept domain.

Maintain Concept Domain

The ability to modify a concept domain, including bindings
to value sets within usage contexts.

Create Usage Context

The ability to define and add a new usage context.

Maintain Usage Context

The ability to modify a usage context.

Terminology Administration Profile

The Terminology Administration profile is intended to
provide the functional operations necessary for terminology administrators to
be able to access and make available terminology content obtained from a Terminology Provider.

Create Association

The ability to create an association between concepts.

Update Association Status

The ability to update the status of an association between
concepts.

Create Association Type

The ability to create a new Association type that may be
used to link two concepts.

Maintain Association Type

The ability to modify or deprecate an existing Association
type that may be used to link two concepts.

Create Lexical Association Between Coded Concepts
(optional for this profile)

The ability to instantiate an association between two sets
of coded concepts using a set of lexical rules (matching algorithms) to
generate the associations .

Create Rules Based Association Between Coded Concepts
(optional for this profile)

The ability to instantiate an association between two sets
of coded concepts using a set of description logic or inference rules that either assert or infer mappings between two Code Systems.

Create Code System Supplement

Create a new Code System Supplement as a container of a
set of concepts and concept properties to be appended to a target code system

Maintain Code System Supplement

Update Code System Supplement meta-data properties and add
concepts and properties to code system

CTS2 Architecture Diagram
CTS2 Architecture DiagramImage Added

Semantic Profiles

Semantic profiles identify a named set of metamodels that are to be supported by the operations specified in the functional profiles.

The following semantic profile is considered in scope for LexEVS 6.0:

Mature Terminology Profile

  • Best practices conformance for the terminology
  • Terminologies in the Mature Terminology Profile make an attempt to conform to many of terminology best practices that are, for example, outlined in Desiderata for Controlled Medical Vocabularies in the Twenty-First Century, James J. Cimino.
  • Sample Terminologies include: SNOMED CT, ICD 10 CM, LOINC, RxNorm, NDF / NDF-RT

This profile best fits the existing NCI terminologies.

Conformance Profiles

Conformance profiles are intended to focus specific implementations to address a specific class of functionality and minimum trait sets for each functional class. LexEVS 6.0 intends to implement to the following conformance:

Profile

Mature Terminology Semantic Profile

CTS 2 Query Functional Profile

CTS2 Query - Mature Terminology Conformance Profile

Terminology Administration Functional Profile

Terminology Administration - Mature Terminology Conformance Profile

Terminology Authoring Functional Profile

Terminology Authoring - Mature Terminology Conformance Profile

Sub-Categorization of CTS 2 Services

CTS 2 Services can be further categorized from the above profile details.

CTS Services Diagram
Image Added

Service Interfaces for CTS 2

Interfaces to be considered for CTS 2 Services
CTS2 Service Interfaces DiagramImage Added

High Level Design Diagram

The LexEVS 6.0 infrastructure exhibits an n-tiered architecture with client interfaces, server components, domain objects, data sources, and back-end systems (architecture diagram). This n-tiered system divides tasks or requests among different servers and data stores. This isolates the client from the details of where and how data is retrieved from different data stores.

The system also performs common tasks such as logging and provides a level of security for protected content. Clients (browsers, applications) receive information through designated application programming interfaces (APIs). Java applications communicate with back-end objects via domain objects packaged within the client.jar. Non-Java applications can communicate via SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) services.

Most of the LexEVS API infrastructure is written in the Java programming language and leverages reusable, third-party components. The service infrastructure is composed of the following layers:

Application Service Layer - accepts incoming requests from all public interfaces and translates them, as required, to Java calls in terms of the native LexEVS API. Non-SDK queries are invoked against the Distributed LexEVS API, which handles client authentication and acts as proxy to invoke the equivalent function against the LexEVS core Java API. The caGrid and SDK-generated services are optionally run in an application server separate from the Distributed LexEVS API.

The LexEVS caCORE SDK services work directly against the database, via Hibernate bindings, to resolve stored objects without intermediate translation of calls in terms of the LexEVS API. However, the LexEVS SDK services do still require access to metadata and security information stored by the Distributed and Core LexEVS API environment to resolve the specific database location for requested objects and to verify access to protected resources, respectively.

From the client prospective, the LexEVS services will function as "ports" accessible through the caGrid 1.3 service architectural model. LexEVS services will follow the caGrid architecture for analytical and data services. See the caGrid 1.3 documentation for architectural details: https://cabig.nci.nih.gov/workspaces/Architecture/caGrid/

Core API Layer - underpins all LexEVS API requests. Search of pre-populated Lucene index files is used to evaluate query results before incurring cost of database access. Access to the LexGrid database is performed as required to populate returned objects using pooled connections.

Data Source Layer - is responsible for storage and access to all data required to represent the objects returned through API invocation.

High Level Design Diagram
High Level Design DiagramImage Added

Scrollbar
iconsfalse

...

titleContents
Table of Contents
maxLevel3
Column
Wiki Markup

|| Sign off || Date || Role \\ || CBIIT or Stakeholder Organization \\ || Reviewer's Comments (If disapproved indicate specific areas for improvement.) \\ ||
| | \\ | | \\ | |
| | \\ | | \\ | |
| | \\ | | \\ | |
\\

\\

h1. Solution Architecture

h1. High Level Architecture


h4. *Structure of the CTS 2 Service*

\\

The functional CTS 2 Model defines several functional profiles.  These profiles are a focused subset of the functionality of a CTS 2 implementation.

 CTS 2 Query Profile:
* Searching and querying terminologies
* Provide access to terminology content and representational structures (description logic) consistent with the terminology author's intent.

 Terminology Administration Profile:
*  Restricting administrative access
*  Obtaining and loading terminologies
*  Maintaining terminology access
* Control Content Access

 Terminology Authoring Profile:
* functional terminology analysis/query
* direct terminology edits

!CTS2_Arch_Diagram.png!
 

h4. *Semantic Profiles*

 HL7 Profile:
* Functional coverage and specificity necessary for HL7 conformance
* Searching terminology content
* Interchange content in the the Model Interchange Format.
* Use of HL7 Datatypes
* (Model Interchange Format (MIF) Representation of terminology content

Mature Terminology Profile:
* Best practices conformance for the terminology

Developing Terminology Profile:
* ad hoc or degraded terminologies

h4.   *High Level Design Diagram*

\\ !High_Level_Design_diagram.png|width=987,height=772!
 

h2.  CTS 2 Functional Profiles


h4. CTS 2 Query Profile

| List Code Systems | The ability to provide a listing of the available code \\
systems that meet input search criteria. |
| Return Code System Details | The ability to retrieve a specific code system attributes \\
(synonyms, associations) and other metadata. |
| List Code System Concepts | The ability to retrieve a list of all of the concepts, \\
with associated attributes (synonyms, associations) and other metadata that \\
meet input criteria. |
| Return Concept Details | The ability to retrieve a specific concept, with \\
associated attributes (synonyms, associations) and other metadata. |
| List Value Sets | The ability to determine what value sets are available to \\
a Terminology Service. This includes seeing a listing of the available value \\
sets that match some search criteria, as well as the details pertaining to \\
each value set available to the terminology service. |
| Return Value Set Details | The ability to retrieve a specific value set, with \\
associated attributes and other metadata. |
| List Value Set Contents | The ability to see a listing of specific concepts, as well \\
as the details pertaining to each concept in any of the given value sets \\
available to a terminology service. |
| Check Concept Value Set Membership | The ability to validate that a given concept exists in a \\
given value set. |
| List Concept Domains | The ability to determine what concept domains are \\
available to a Terminology Service. |
| Return Concept Domain Details | The ability to retrieve a specific concept domain, with \\
associated attributes and other metadata. |
| List Concept Domain Bindings | The ability to see a listing of specific value sets that \\
are bound to a concept domain in specified usage contexts. |
| Check Concept Domain Membership | The ability to validate that a given concept code is bound \\
to a given concept domain. |
| List Usage Contexts | The ability to determine what usage contexts are available \\
to a Terminology Service. |
| Return Usage Context Details | The ability to retrieve a specific usage context, with \\
associated attributes and other metadata. |
| List Associations | The ability to determine what associations are available \\
on the terminology service by browsing a list of available associations on \\
the CTS 2 instance that meet specified search criteria. |
| Return Association Details | The ability to retrieve metadata on available associations \\
in the CTS 2 service instance. |
| List Association Types | Returns the details for the known attributes (metadata) of \\
a coded concept |
| Return Association Type Details | The ability to return all information for a Association \\
type. |
| Check Value Set Subsumption | Determine whether one of the two supplied value sets \\
subsumes the other |
| Check Concept to Concept Domain Association | Determine whether the supplied coded concept exists in a \\
code system in use for the specified concept domain, optionally within \\
specific usage contexts. |
| Determine Transitive Concept Relationship | Determine whether there exists a  transitive relationship between two \\
concepts, if it exists |
| Compute Subsumption Relationship | Determine Whether One Concept Subsumes a Second |

h4. Terminology Administration Profile

| Import Code System | Terminology content would be loaded into the terminology \\
server as an entire terminology load or skeleton load (i.e. load of structure \\
without loading the nodes). |
| Import Code System Revision | Terminology content would be loaded into the terminology \\
server as a delta or set of changes from the previous version of the \\
terminology. |
| Import Value Set Version | Ability to import values sets |
| Import Association version | Ability to import Associations |
| Export Association | Ability to export Association Type instances |
| Export Code System Content | Terminology content would be exported either in whole or \\
in part based on filtering against terminology properties. The export format \\
may also be specified. |
| Change Code System Status | Terminology content status would be changed, thus changing \\
its availability for access by other terminology service functions. |
| Register for Notification | A client registers for notification so that an electronic \\
notification would be sent to subscribed users in the event of a change to \\
the specified terminology element. |
| Update Notification Registration | Subscription notification information can be updated for a \\
subscriber's notification account. |
| Update Notification Registration Status | Updates the status of a notification registration. |

h4. Terminology Authoring Profile

| Create Code System | The ability to create a new Code System to contain a set \\
of new coded concepts. The Code System is created by defining the set of \\
meta-data properties that describe it. |
| Maintain Code System Version | The ability to maintain the content and metadata of a \\
version for a code system. |
| Update Code System Version Status | The ability to modify the status of a code system. |
| Create Concept | The ability to define and add a new concept to a code \\
system. |
| Maintain Concept | The ability to modify a concept that exists in a code \\
system. |
| Update Concept Status | The ability to modify the status of a concept that exists \\
in a code system. |
| Create Value Set | The ability to create a dynamic value set that is defined \\
by a computable expression that can be resolved to an exact list of coded \\
concepts at any given point in time. |
| Maintain Value Set | Update properties or expression of a value set definition \\
(extensional and intensional value sets). |
| | |
| Update Value Set Status | The ability to modify the status of a value set. |
| Create Concept Domain | The ability to define and add a new concept domain. |
| Maintain Concept Domain | The ability to modify a concept domain, including bindings \\
to value sets within usage contexts. |
| Create Usage Context | The ability to define and add a new usage context. |
| Maintain Usage Context | The ability to modify a usage context. |
| Terminology Administration Profile | The Terminology Administration profile is intended to \\
provide the functional operations necessary for terminology administrators to \\
be able to access and make available terminology content obtained from a Terminology Provider. |
| Create Association | The ability to create an association between concepts. |
| Update Association Status | The ability to update the status of an association between \\
concepts. |
| Create Association Type | The ability to create a new Association type that may be \\
used to link two concepts. |
| Maintain Association Type | The ability to modify or deprecate an existing Association \\
type that may be used to link two concepts. |
| Create Lexical Association Between Coded Concepts \\
(optional for this profile) | The ability to instantiate an association between two sets \\
of coded concepts using a set of lexical rules (matching algorithms) to \\
generate the associations . |
| Create Rules Based Association Between Coded Concepts \\
(optional for this profile) | The ability to instantiate an association between two sets \\
of coded concepts using a set of description logic or inference rules that either assert or infer mappings between two Code Systems. |
| Create Code System Supplement | Create a new Code System Supplement as a container of a \\
set of concepts and concept properties to be appended to a target code system |
| Maintain Code System Supplement | Update Code System Supplement meta-data properties and add \\
concepts and properties to code system |

h4. A Sub Categorization of Services

CTS Services can be further categorized from the profile details above:

\\ !CTS_Services.png!

h4. CTS Service Interfaces

\\ !CTS2_Services2LexEVS.png|width=711,height=789!

h2. GForge items

One heading for each item, to include functional and non-functional requirements and bug fixes.

h2. Use cases

Links to available documents.

h2. Related requirements

One heading for each item.

h3. Solutions Architecture: XML Loads of LexGrid Modeled Content


h4. *Overview:*

*Loads of LexGrid XML were formerly limited by the size of the Coding Scheme model element that could be constructed in memory.  *
\\
*Loaded models had a single entry point at the CodingScheme element.  With the intention of providing improved loading performance,*
\\
*access points to other levels of LexGrid Model elements, and a convenient format for authoring, the design of the 5.1 XML Loader has been*
\\
*updated for LexEVS 6.0 and will be implemented with the following considerations:   *
* * A streaming implementation of the loading mechanism allowing larger loads in a smaller memory footprint.*
* *A variety of entry points to facilitate loading of Revisions, System Releases, Value Sets, Pick Lists, and Coding Schemes.*
* *A loading mechanism for Authoring based manipulation of LexGrid based xml files allowing entities and associations to be added*
\\
*to a given coding scheme in XML, then loaded into a LexGrid data repository.*

h5. Streaming XML Implementation

\\

*The latest implementation of the LexGrid XML loader provides a partitioned load of a coding scheme or other potentially large elements.*

*The 6.0 loader will read coding scheme meta data into memory, load it to the LexGrid database and then begin stepping through entities and associations *

*persisting elements to the database and then removing them from the coding scheme object as the unmarshaller reads objects from XML and into the coding scheme*

*object in memory.  Streaming XML reads while controlling the build of the coding scheme (and potentially other objects) in memory allowing the load of*

*far larger terminologies constructed in LexGrid xml.  This also allows users to eventually export larger coding schemes, revise them with authoring tools,*

*and reload them as LexGrid Revision elements.   This and other authoring scenarios will be exercised upon LexGrid XML with subsequent loads to the*

*LexGrid database possible.  (See authoring design below.)*
\\

*LexGrid coding scheme meta data contains an number of required and optional elements as defined in the LexGrid schema.  The last of these elements, before entity and associations*

*are expressed, are the coding scheme mappings and the coding scheme properties.  Mappings are required elements in the coding scheme and as*

*such are a default stopping point of coding scheme reads. Coding scheme properties are not required and as such may not exist in a given rendering of LexGrid XML.*

*Before persistence of meta data to the LexGrid database takes place, a high speed pass is made over the coding scheme meta data portion of the XML with the STAX*

*parser api to determine coding scheme properties presence.  *
\\
\\ !XMLMetaDataReads.png!\\
\\
*The bulk of the coding scheme elements are read, stored to database, and de-referenced to allow sufficient memory management.*
\\

\\ !EntityReadandDeref.png!\\
\\ !assocReadandDeref.png!\\

h4. Entry Points Expanded


h5. Coding Scheme Entry Point

*Previously, coding scheme was the only entry point for persisting loading to the LexGrid data base.  Since pick lists, value domains, and revisions*

*required more flexibility in XML based loads,  entry points for revisions and system releases were also added.*
\\

!CodingSchemeEP.png!\\

h5.  Revision Entry Point

\\

*Revisions can be applied to Coding Schemes, Pick Lists and Value Sets.  A single revision element can load a set of revisions of coding schemes, pick lists and value sets.*

\\ !RevisionEP.png|width=898,height=880!

\\
*Revision can contain a variety of changed elements.*
\\
\\ !RevisionEPAll.png!

h5.  System Release Entry Point

\\

*System Release is primarily intended as a release point for collections of pick lists and value sets.  It is beyond*

*the scope of this implementation to load multiple coding schemes contained within a system release.  The technical*

*problems implied by the loads of a System Release containing multiple large coding schemes suggests that such a use case*

*is impractical in many scenarios.*
\\

\\ !SystemReleaseEP.png!
 

h3. Solutions Architecture: Associations and Mapping

Placeholder for mapping designs
\\ !Arch_sol_Association_mapping.png|width=799,height=767!\\

h5.  Levels of Mapping Implementation implied by current requirements from various stakeholders

There are multiple levels at which mapping, as evaluated here, could be considered to be "supported":
# The ability to store map sets, look up map sets by id, from, to
\\
and other attributes and to look up entries by source, target and/or
\\
relationship. We would have to store all of the additional information
\\
such as options, rules, categories, advice, etc, but it would be up to
\\
external software to interpret and evaluate the contents.
\\
# Everything in option 1) above plus the ability to query
\\
additional fields - give me an ordered, structured list of a mapping
\\
entry in a way that someone could write a standard interpreter to
\\
evaluate it - this would basically require the addition of a model and
\\
would most likely cause us to split from the existing relations model,
\\
as it gets into the domain of table driven rule sets.
# Everything in 1) and, possibly 2) with the added ability to
\\
actually interpret the rules - an API that answers questions such as
\\
"What information is needed to map 231754000 (poisoning by sodium
\\
valproate) correctly?" (answer - whether barbituates, sulfonamides were
\\
present, whether combined with various substances, etc). "What does
\\
231754000 in the presence of ... map to?

h5.


h5. Evaluation of Levels of Mapping Implementation for CTS 2

For LexEVS 6.0 (CTS 2), (3) is out of scope. This is
\\
the function of a rules engine and the complexities of even the supplied
\\
examples are overwhelming. We may want to examine the DSS RFP to see
\\
whether there is anything there that applies. It appears that (2)
\\
is out of scope as well, as, whether we interpret the semantics of the
\\
rules or not, the structure required to represent the rules still lies
\\
well within the rule base and DSS space. The question is, then, whether
\\
item (1) adds sufficient value to be worth doing. My take is "no" as
\\
well, as trying to fit all of the various aspects of the mapping rules
\\
that we've seen to date into the nooks and crannies of the LexGrid
\\
mapping model seems to be an exercise with little return.
What we need to do is to return to the set of use cases, if any,
\\
that LexEVS could reasonably resolve. As there _are_ simpler use
\\
cases, such as those presented by various stakeholders, we will clearly need to
\\
resolve them and, if it would be useful, could answer the same questions
\\
for complex mappings. Once, however, we get to the point of
\\
determining what participates in a particular map, it seems like we are
\\
getting out of our scope - the best we might do is supply the
\\
associationId that could be used as an index into another table.

h5. Proposed Solution

\\

{color:#0066cc}{*}Model Changes{*}{color}

!Model_changes_mapping_1.PNG|width=987,height=588!\\

The relations attribute in the model will have the following elements and attributes added:
* representsVersion - if present, the source asserted version of the collection of relations or mappings
* isMapping - if true, this collection of relations represents a mapping and will be evaluated for "mapping" related queries.
* sourceCodingScheme - if present, the local identifier of the namespace that the sourcEntityCodes are derived from.
*  sourceCodingSchemeVersion - the source asserted version identifier of the source coding scheme.  If present, this becomes the default for sourceEntityCodeNamespace.
* targetCodingScheme - if present, the local identifier of the namespace that the targetEntityCodes are derived from. If present, this becomes the default for targetEntityCodeNamespace.
* targetCodingSchemeVersion - the source asserted version identifier of the target coding scheme
* properties - all other properties on the "relations bucket" level that don't fit one of the items in the Relations container

!Model_changes_mapping_2.PNG!
 
There are no additional changes for the second part of the model, shown above.

h2. Content Representation


h3. MRSAT Mappings

| {color:#31849b}{*}MRSAT Column{*}{color} | {color:#31849b}{*}Function{*}{color} | {color:#31849b}{*}LexGrid Equivalent{*}{color} |
| {color:#31849b}{*}MAPSETVERSION{*}{color} | | {color:#31849b}Relations.representsVersion{color} |
| {color:#31849b}{*}FROMVSAB{*}{color} | {color:#31849b}The from code system version{color} | {color:#31849b}Relations.fromCodingSchemeVersion{color} |
| {color:#31849b}{*}FROMRSAB{*}{color} | {color:#31849b}The from code system{color} | {color:#31849b}Relations.FromCodingScheme{color} |
| {color:#31849b}{*}TOVSAB{*}{color} | {color:#31849b}The to code system version{color} | {color:#31849b}Relations.toCodingSchemeVersion{color} |
| {color:#31849b}{*}TORSAB{*}{color} | {color:#31849b}The to code system{color} | {color:#31849b}Relations.toCodingScheme{color} |
| {color:#31849b}{*}MAPSETRSAB{*}{color} | {color:#31849b}Source of the value set{color} | {color:#31849b}Relations.owner{color} |
| {color:#31849b}*(anything else)*{color} | | {color:#31849b}Relations.property\[key\]{color} |

h3. MRMAP Mappings \|

There are at least two possibilities for the MRMAP transformations into LexGrid.  The first, the "flattened transformation" puts the entire MRMAP row into the table:

h4. MRMAP Flattened Option

| {color:#31849b}{*}MRMAP Column{*}{color} | {color:#31849b}{*}Function{*}{color} | {color:#31849b}{*}LexGrid Equivalent{*}{color} |
| {color:#31849b}{*}MAPSETCUI{*}{color} | | {color:#31849b}Relations.containerName{color} |
| {color:#31849b}{*}MAPID{*}{color} | {color:#31849b}Row identifier{color} | {color:#31849b}Target.associationInstanceId{color} |
| {color:#31849b}{*}FROMEXPR{*}{color} | {color:#31849b}Source code or expression{color} | {color:#31849b}Source.sourceEntityCode{color} |
| {color:#31849b}{*}REL{*}{color} | {color:#31849b}UMLS asserted relationship{color} | {color:#31849b}associationPredicate (if RELA absent){color} |
| {color:#31849b}{*}RELA{*}{color} | {color:#31849b}Source asserted relationship{color} | {color:#31849b}associationPredicate(if not blank){color} |
| {color:#31849b}{*}TOEXPR{*}{color} | {color:#31849b}Target code or expression{color} | {color:#31849b}Target.targetEntityCode (if code){color}\\ {color:#31849b}TargetData.associationDataText (else){color} |
| {color:#31849b}{*}TOTYPE{*}{color} | {color:#31849b}Type of the data{color} | {color:#31849b}targetData.associationDataText.dataType (if target is not code){color} |
| {color:#31849b}*(entire MRMAP row{*}{color} | | {color:#31849b}Target(Data).associationQualification\[MRMAP entry\]{color} |

h4. MRMAP Expanded  Option \|

| {color:#31849b}{*}MRMAP Column{*}{color} | {color:#31849b}{*}Function{*}{color} | {color:#31849b}{*}LexGrid Equivalent{*}{color} |
| {color:#31849b}{*}MAPSETCUI{*}{color} | | {color:#31849b}Relations.containerName{color} |
| {color:#31849b}{*}MAPID{*}{color} | {color:#31849b}Row identifier{color} | {color:#31849b}Target.associationInstanceId{color} |
| {color:#31849b}{*}FROMEXPR{*}{color} | {color:#31849b}Source code or expression{color} | {color:#31849b}Source.sourceEntityCode{color} |
| {color:#31849b}{*}REL{*}{color} | {color:#31849b}UMLS asserted relationship{color} | {color:#31849b}associationPredicate (if RELA absent){color} |
| {color:#31849b}{*}RELA{*}{color} | {color:#31849b}Source asserted relationship{color} | {color:#31849b}associationPredicate(if not blank){color} |
| {color:#31849b}{*}TOEXPR{*}{color} | {color:#31849b}Target code or expression{color} | {color:#31849b}Target.targetEntityCode (if code){color}\\ {color:#31849b}TargetData.associationDataText (else){color} |
| {color:#31849b}{*}TOTYPE{*}{color} | {color:#31849b}Type of the data{color} | {color:#31849b}targetData.associationDataText.dataType (if target is not code){color} |
| {color:#31849b}*(anything else)*{color} | | {color:#31849b}Target(Data).associationQualification\[associationQualifier\]{color} |

h5. Expression Issues

One of the requirements for mapping has been the ability to discover what maps a given entity (may) participate in.
\\
This will not be completely answerable in situations where the codes are carried in text expressions. One alternative
\\
would be to parse the target expression when possible and to create multiple rows, one for each target. Besides the parsing
\\
complexity, however, the other issue is that it is not possible to record the expression operators (AND, OR, ...)
\\
in the expansion. This, however, would arguably be the best use of the mappings for this level of complexity.
\\

h5.  Sample Mapping XML

\\
\\
{code:xml}
<?xml version="1.0" encoding="UTF-8" ?>
- <codingScheme xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://LexGrid.org/schema/2010/01/LexGrid/codingSchemes file:/C:/devel/v6/lexgrid_model/lgModel/master/relations.xsd" xmlns="http://LexGrid.org/schema/2010/01/LexGrid/codingSchemes" xmlns:lgBuiltin="http://LexGrid.org/schema/2010/01/LexGrid/builtins" xmlns:lgCS="http://LexGrid.org/schema/2010/01/LexGrid/codingSchemes" xmlns:lgCon="http://LexGrid.org/schema/2010/01/LexGrid/concepts" xmlns:lgCommon="http://LexGrid.org/schema/2010/01/LexGrid/commonTypes" codingSchemeName="UMLS" codingSchemeURI="urn:oid:2.16.840.1.113883.6.2" representsVersion="http://SharedNames.org/ontology/umls/2009AB">
  <mappings />
- <!--  MRSAT entry
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT115321814||MAPSETVERSION|MTH|2010_2009_08_17|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT115321815||TOVSAB|MTH|MSH2010_2009_08_17|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361323||FROMRSAB|MTH|MTH|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361327||FROMVSAB|MTH|MTH|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361343||MAPSETGRAMMAR|MTH|ATX ::= expr; expr ::= disj; disj ::= conj , conj "OR" conj; conj ::= unary , unary "AND" unary; unary ::= neg , pos; neg ::= "NOT" pos; pos ::= "(" expr ")" , slash , atom; slash ::= atom , atom "/" atom; atom ::= "<" (any non ">" character) ">";|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361355||MAPSETRSAB|MTH|MTH|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361364||MAPSETTYPE|MTH|ATX|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37361368||MAPSETVSAB|MTH|MTH|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37408395||TORSAB|MTH|MSH|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT37424062||SOS|MTH|This map set contains mappings from Metathesaurus CUIs to MSH associated expressions.|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT56870375||MTH_MAPFROMEXHAUSTIVE|MTH|N|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT56870378||MTH_MAPSETCOMPLEXITY|MTH|ONE_TO_ONE|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT56870384||MTH_MAPTOEXHAUSTIVE|MTH|N|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT65576316||MTH_MAPFROMCOMPLEXITY|MTH|SINGLE CUI|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT65576317||MTH_MAPTOCOMPLEXITY|MTH|BOOLEAN_EXPRESSION STR|N||
        C1306694|L8923988|S11111536|A17029750|CODE|1000|AT67813929||MAPSETSID|MTH|1000|N||
        C1306694||||CUI||AT116199817||MR|MTH|20090921|N||
        C1306694||||CUI||AT31823722||DA|MTH|20040415|N||
        C1306694||||CUI||AT31952620||ST|MTH|R|N||
  -->
- <!--  OPTION 1: Everything flattened
  -->
- <lgCS:relations containerName="C1306694" isMapping="true" sourceCodingScheme="MTH" sourceCodingSchemeVersion="MTH" targetCodingScheme="MSH" targetCodingSchemeVersion="MSH2010_2009_08_17" representsVersion="2010_2009_08_17" xmlns="http://LexGrid.org/schema/2010/01/LexGrid/relations">
- <!--  This should be MAPSETNAME but, curiously, it is missing from the MRSAT list. We are assuming that "SOS" is the equivalent
  -->
  <lgCommon:entityDescription>This map set contains mappings from Metathesaurus CUIs to MSH associated expressions.</lgCommon:entityDescription>
- <properties>
- <lgCommon:property propertyName="MAPSETGRAMMER">
  <lgCommon:value>ATX ::= expr; expr ::= disj; disj ::= conj , conj "OR" conj; conj ::= unary , unary "AND" unary; unary ::= neg , pos; neg ::= "NOT" pos; pos ::= "(" expr ")" , slash , atom; slash ::= atom , atom "/" atom; atom ::= ">" (any non ">" character) ">";</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETRSAB">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETTYPE">
  <lgCommon:value>ATX</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETVSAB">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPFROMEXHAUSTIVE">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPSETCOMPLEXITY">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOEXHAUSTIVE">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPFROMCOMPLEXITY">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOCOMPLEXITY">
  <lgCommon:value>MTH</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MR">
  <lgCommon:value>20090921</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="DA">
  <lgCommon:value>20040415</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="ST">
  <lgCommon:value>R</lgCommon:value>
  </lgCommon:property>
  </properties>
- <!--  MAPSETCUI|MAPSAB|MAPSUBSETID|MAPRANK|MAPID      |MAPSID|FROMID  |FROMSID|FROMEXPR|FROMTYPE|FROMRULE|FROMRES|REL|RELA
             C1306694 |MTH   |           |       |AT102971857|      |C0264643|       |C0264643|CUI     |        |       |SY |
             |TOID|TOSID|TOEXPR                                                    |TOTYPE                |TORULE|TORES|MAPRULE|MAPRES|MAPTYPE|MAPATN|MAPATV
             |3026|     |<Hypertension, Renovascular> AND <Hypertension, Malignant>|BOOLEAN_EXPRESSION_STR|      |     |       |      |ATX    |      |      ||
  -->
- <associationPredicate associationName="SY">
- <!--  MRMAP Option 1 - Expand each non-semantic MRMAP entry
  -->
- <source sourceEntityCode="C0264643">
- <targetData associationInstanceId="AT102971857">
- <associationQualification associationQualifier="FROMTYPE">
  <qualifierText>CUI</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMID">
  <qualifierText>C0264643</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOTYPE">
  <qualifierText>BOOLEAN_EXPRESSION_STR</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOID">
  <qualifierText>3026</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="MAPTYPE">
  <qualifierText>ATX</qualifierText>
  </associationQualification>
  <associationDataText dataType="BOOLEAN_EXPRESSION_STR">>Hypertension, Renovascular> AND >Hypertension, Malignant></associationDataText>
  </targetData>
  </source>
- <!--  MRMAP Option 2 - Keep MRMAP entry as it is
  -->
- <source sourceEntityCode="C0264643">
- <targetData associationInstanceId="AT102971857">
- <associationQualification associationQualifier="MRMAP Entry">
  <qualifierText>C1306694|MTH|||AT102971857||C0264643||C0264643|CUI|||SY||3026||>Hypertension, Renovascular> AND >Hypertension, Malignant>|BOOLEAN_EXPRESSION_STR|||||ATX||||</qualifierText>
  </associationQualification>
  <associationDataText dataType="BOOLEAN_EXPRESSION_STR">>Hypertension, Renovascular> AND >Hypertension, Malignant></associationDataText>
  </targetData>
  </source>
- <!--  TARGET Option 2 - Semantic interpretation of the target entry
  -->
- <!--  NOTE That this loses the operators, but (assuming that the target entries were codes), would maintain the participation
  -->
- <source sourceEntityCode="C0264643">
- <target targetEntityCode="Hyptertension, Renovascular" associationInstanceId="AT102971857.1">
- <associationQualification associationQualifier="MRMAP Entry">
  <qualifierText>C1306694|MTH|||AT102971857||C0264643||C0264643|CUI|||SY||3026||>Hypertension, Renovascular> AND >Hypertension, Malignant>|BOOLEAN_EXPRESSION_STR|||||ATX||||</qualifierText>
  </associationQualification>
  </target>
- <target targetEntityCode="Hypertension, Malignant" associationInstanceId="AT102971857.2">
- <associationQualification associationQualifier="MRMAP Entry">
  <qualifierText>C1306694|MTH|||AT102971857||C0264643||C0264643|CUI|||SY||3026||>Hypertension, Renovascular> AND >Hypertension, Malignant>|BOOLEAN_EXPRESSION_STR|||||ATX||||</qualifierText>
  </associationQualification>
  </target>
  </source>
  </associationPredicate>
  </lgCS:relations>
- <!--
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT110721471||FROMVSAB|MDR|MDR12_0|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT110721473||MAPSETVERSION|MDR|200903|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT110721475||MAPSETVSAB|MDR|MDR12_0|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90562335||FROMRSAB|MDR|MDR|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90562339||MAPSETRSAB|MDR|MDR|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90562341||MAPSETTYPE|MDR|MedDRA to ICD9CM Mappings|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90580448||MTH_MAPFROMCOMPLEXITY|MDR|SINGLE CODE|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90580450||MTH_MAPFROMEXHAUSTIVE|MDR|N|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90580452||MTH_MAPSETCOMPLEXITY|MDR|ONE_TO_ONE|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90580454||MTH_MAPTOCOMPLEXITY|MDR|SINGLE CODE|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT90580456||MTH_MAPTOEXHAUSTIVE|MDR|N|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT91157709||TORSAB|MDR|ICD9CM|N||
        C2242749|L8609359|S10707041|A16492852|CODE|MTHU000002|AT91157711||TOVSAB|MDR|ICD9CM_1998|N||
        C2242749||||CUI||AT101551784||DA|MTH|20081103|N||
        C2242749||||CUI||AT102850765||ST|MTH|R|N||
        C2242749||||CUI||AT116202416||MR|MTH|20090926|N||

  -->
- <!--  Should this be the code or "MTHU000002"?
  -->
- <lgCS:relations containerName="C2242749" sourceCodingScheme="MDR" sourceCodingSchemeVersion="MDR12_0" targetCodingScheme="ICD9CM" targetCodingSchemeVersion="ICD9CM_1998" representsVersion="200903" xmlns="http://LexGrid.org/schema/2010/01/LexGrid/relations">
  <lgCommon:owner>MDR</lgCommon:owner>
- <!--  This should be MAPSETNAME but, curiously, it is missing from the MRSAT list
  -->
  <lgCommon:entityDescription>This map set contains mappings from Metathesaurus CUIs to MSH associated expressions.</lgCommon:entityDescription>
- <properties>
- <lgCommon:property propertyName="MAPSETTYPE">
  <lgCommon:value>MedDRA to ICD9CM Mappings</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPFROMCOMPLEXITY">
  <lgCommon:value>SINGLE CODE</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPFROMEXHAUSTIVE">
  <lgCommon:value>N</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPSETCOMPLEXITY">
  <lgCommon:value>ONE_TO_ONE</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOCOMPLEXITY">
  <lgCommon:value>SINGLE CODE</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOEXHAUSTIVE">
  <lgCommon:value>MedDRA to ICD9CM Mappings</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETTYPE">
  <lgCommon:value>N</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="DA">
  <lgCommon:value>20081103</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="ST">
  <lgCommon:value>R</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MR">
  <lgCommon:value>20090926</lgCommon:value>
  </lgCommon:property>
  </properties>
- <!--  MAPSETCUI|MAPSAB|MAPSUBSETID|MAPRANK|MAPID      |MAPSID|FROMID  |FROMSID|FROMEXPR|FROMTYPE|FROMRULE|FROMRES|REL|RELA
            C2242749 |MDR   |           |       |AT91157713 |      |10032725|       |10032725|CODE    |        |       |RQ |mapped_to
            |TOID |TOSID|TOEXPR |TOTYPE                |TORULE|TORES|MAPRULE|MAPRES|MAPTYPE|MAPATN|MAPATV
            |728.7|     |728.7  |CODE                  |||||||||
  -->
- <associationPredicate associationName="mapped_to">
- <!--  Note that "RQ" gets lost in this approach...
  -->
- <source sourceEntityCode="10032725">
- <target targetEntityCode="728.7" associationInstanceId="AT91157713">
- <associationQualification associationQualifier="FROMTYPE">
  <qualifierText>CODE</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMID">
  <qualifierText>10032725</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOID">
  <qualifierText>728.7</qualifierText>
  </associationQualification>
  </target>
  </source>
  </associationPredicate>
  </lgCS:relations>
- <!--  C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958256||MAPSETRSAB|ICD10PCS|ICD10PCS|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958265||MTH_MAPFROMCOMPLEXITY|ICD10PCS|SINGLE SDUI|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958266||MTH_MAPFROMEXHAUSTIVE|ICD10PCS|N|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958268||MTH_MAPSETCOMPLEXITY|ICD10PCS|N_TO_N|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958270||MTH_MAPTOEXHAUSTIVE|ICD10PCS|N|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT106958273||TORSAB|ICD10PCS|ICD10PCS|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240306||FROMRSAB|ICD10PCS|ICD9CM|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240309||FROMVSAB|ICD10PCS|ICD9CM_2009|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240314||MAPSETTYPE|ICD10PCS|ICD-9-CM to ICD-10-PCS Mappings (GEMs)|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240316||MAPSETVERSION|ICD10PCS|2009|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240319||MAPSETVSAB|ICD10PCS|ICD10PCS_2009|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240322||MAPSETXRTARGETID|ICD10PCS|NoPCS|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240327||MTH_MAPTOCOMPLEXITY|ICD10PCS|SINGLE SCUI|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240330||SOS|ICD10PCS|This set maps ICD-9-CM codes to ICD-10-PCS. These are "General Equivalence Mappings" (GEMs) and are rule-based.|N||
        C2603385|L8770856|S10872372|A16736317|CODE|MTHU000001|AT112240336||TOVSAB|ICD10PCS|ICD10PCS_2009|N||
        C2603385||||CUI||AT109499260||DA|MTH|20090401|N||
        C2603385||||CUI||AT110315629||ST|MTH|R|N||
        C2603385||||CUI||AT116202419||MR|MTH|20090926|N||
  -->
- <lgCS:relations containerName="C2603385" sourceCodingScheme="ICD9CM" sourceCodingSchemeVersion="ICD9CM_2009" targetCodingScheme="ICD10PCS" targetCodingSchemeVersion="ICD10PCS_2009" representsVersion="ICD10PCS_2009" xmlns="http://LexGrid.org/schema/2010/01/LexGrid/relations">
  <lgCommon:owner>ICD10PCS</lgCommon:owner>
  <lgCommon:entityDescription>This set maps ICD-9-CM codes to ICD-10-PCS. These are "General Equivalence Mappings" (GEMs) and are rule-based.</lgCommon:entityDescription>
- <properties>
- <lgCommon:property propertyName="MTH_MAPFROMCOMPLEXITY">
  <lgCommon:value>SINGLE SDUI</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPFROMEXHAUSTIVE">
  <lgCommon:value>N</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPSETCOMPLEXITY">
  <lgCommon:value>N_TO_N</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOEXHAUSTIVE">
  <lgCommon:value>N</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETVERSION">
  <lgCommon:value>2009</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MAPSETXRTARGETID">
  <lgCommon:value>NoPCS</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MTH_MAPTOCOMPLEXITY">
  <lgCommon:value>SINGLE SCUI</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="DA">
  <lgCommon:value>20090401</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="ST">
  <lgCommon:value>R</lgCommon:value>
  </lgCommon:property>
- <lgCommon:property propertyName="MR">
  <lgCommon:value>20090926</lgCommon:value>
  </lgCommon:property>
  </properties>
- <!--  MAPSETCUI|MAPSAB  |MAPSUBSETID|MAPRANK|MAPID      |MAPSID|FROMID  |FROMSID|FROMEXPR|FROMTYPE|FROMRULE|FROMRES|REL|RELA
         C2603385 |ICD10PCS|0:0        |       |AT106958276|      |86.63   |       |86.63   |SDUI    |        |       |RO |approximately_mapped_to
         |TOID   |TOSID|TOEXPR |TOTYPE |TORULE|TORES|MAPRULE|MAPRES|MAPTYPE|MAPATN|MAPATV
         |0HR6X73|     |0HR6X73|SCUI   |||||||||
  -->
- <associationPredicate associationName="approximately_mapped_to">
- <!--  Note that "RO" gets lost in this approach...
  -->
- <source sourceEntityCode="86.63">
- <target targetEntityCode="0HR6X73" associationInstanceId="AT106958276">
- <!--  NOTE: This does NOT imply any ordering in the way that map entries are returned !
  -->
- <associationQualification associationQualifier="MAPSUBSETID">
  <qualifierText>0:0</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMTYPE">
  <qualifierText>SDUI</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMID">
  <qualifierText>86.63</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOTYPE">
  <qualifierText>SCUI</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOID">
  <qualifierText>0HR6X73</qualifierText>
  </associationQualification>
  </target>
  </source>
  </associationPredicate>
- <associationPredicate associationName="XR">
- <!--  Note that approximately_mapped_to goes away.  This may not be what we want?
  -->
- <!--  MAPSETCUI|MAPSAB  |MAPSUBSETID|MAPRANK|MAPID      |MAPSID|FROMID  |FROMSID|FROMEXPR|FROMTYPE|FROMRULE|FROMRES|REL|RELA
                 C2603385 |ICD10PCS|0:0        |       |AT112240364|      |89.03   |       |89.03   |SDUI    |        |       |XR ||||||||||||||
                |TOID   |TOSID|TOEXPR |TOTYPE |TORULE|TORES|MAPRULE|MAPRES|MAPTYPE|MAPATN|MAPATV
                |||||||||||||
  -->
- <source sourceEntityCode="89.03">
- <target targetEntityCode="NoPCS" associationInstanceId="AT112240364">
- <associationQualification associationQualifier="MAPSUBSETID">
  <qualifierText>0:0</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMTYPE">
  <qualifierText>SDUI</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="FROMID">
  <qualifierText>86.63</qualifierText>
  </associationQualification>
- <associationQualification associationQualifier="TOID">
  <qualifierText>NoPCS</qualifierText>
- <!--  This is derived from the MAPSETXRTARGETID property in MRSAT
  -->
  </associationQualification>
  </target>
  </source>
  </associationPredicate>
  </lgCS:relations>
  </codingScheme>
{code}\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
\\
h5. &nbsp;Implications for CTS 2 Mapping Implementation
{table: border=1|width = 20%}{tr}{td}
*CTS 2 Function{*}{td}{td}
*Description{*}{td}{td}
*Scope{*}{td}{tr}{tr}{td}
Update Association Status{td}{td}
Update the status of a association (active, inactive, canceled etc). This allows a Terminology User to activate or inactivate a given association, thus changing its availability for access by other terminology service functions{td}{td}
In scope for authoring API{td}{tr}{tr}{td}
Create Association{td}{td}
Relates a single specific coded concept within a specified code system (source) to a corresponding single specific coded concept (target) within the same or another code system, including identification of a specified Association type.{td}{td}
In scope for authoring. Querying already supported{td}{tr}{tr}{td}
Create Lexical Association between Coded Concepts{td}{td}
Relates a set of one or more coded concepts within a specified code system (source)to a corresponding set of one or more coded concepts (target) within that system or another code system using a set of lexical rules (matching algorithms) to generate the Association. The "Source Search Criteria" allows for identification of a subset of the Source Code System to apply the matching algorithm to, if required (this may include limiting the version of the code system).{td}{td}
Not in scope for CTS 2{td}{tr}{tr}{td}
Create Rules Based Association between Coded Concepts{td}{td}
Relates a set of zero or more coded concepts within a specified code system (source)to a corresponding set of zero or more coded concepts (target) within that system or another code system using a set of description logic or inference rules that either assert or infer Associations. The "Source Search Criteria" allows for identification of a subset of the Source Code System to apply the matching algorithm too, if required (this may include limiting the version of the code system).{td}{td}
Not in scope for CTS 2{td}{tr}{table}
\\

h1. Solution Architecture


h5. Data Access Layer

LexEVS lacks a generalized Read/Write interface that can support Authoring and incremental Coding Scheme changes. Also, database access is not isolated. Database-specific code is intermixed with the Service Layer, as well as Extensions. To make LexEVS more able to handle Authoring, while at the same time providing a clean, centralized Database Access Layer, these are the requirements:
* Service Layer code should not call any JDBC code other than a Data Access Interface
* The Data Access Layer should allow connection pooling
* The Data Access Layer should expose 'Service' or 'Repository' Interfaces to the Service Layer.
* Transactions should be well defined
* Allow for Backwards Compatibility
* Inserts, Updates, Selects, and Deletes should cascade the Object hierarchy if desired
* Service-Exposed Interfaces should use the Castor-generated beans.
* Batch inserts should be supported
* Lucene access should be included in the Data Access Layer
* Registry accesss should be included in the Data Access Layer.
* Expose an Event-Driven framework to allow users to insert business rules to control access to the database
* In terms of System Resource responsibilities, the Data Access Layer should be responsible for:
** Detecting the LexGrid Schema version
** Detecting the Database Type (MySQL, Oracle... etc)
** Producing appropriate implementations of the Database Access code given the above
** Loading and initializing all schemas on install
** Tracking loaded Coding Schemes and other resources
** All database admin functions (remove Coding Scheme, index, compute transitivity, etc)

h2. Cross product dependencies

Include a link to the [Core Product Dependency Matrix|https://wiki.nci.nih.gov/x/hIx8].

h2. Changes in technology

Include any new dependencies in the [Core Product Dependency Matrix|https://wiki.nci.nih.gov/x/hIx8] and summarize them here.

h2. Assumptions

List any assumptions.

h2. Risks

List any risks.

...