"

Document Information

Author: Traci St.Martin/Craig Stancl
Email: stancl.craig@mayo.edu
Team: LexEVS
Contract: [Contract number]
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services

Contents

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

Solution Architecture

High Level Architecture

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

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

High Level Design Diagram

CTS 2 Functional Profiles

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

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.

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

A Sub Categorization of Services

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

CTS Service Interfaces

GForge items

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

Use cases

Links to available documents.

Related requirements

One heading for each item.

Solutions Architecture: XML Loads of LexGrid Modeled Content

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.

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.

The bulk of the coding scheme elements are read, stored to database, and de-referenced to allow sufficient memory management.

Entry Points Expanded

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.

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.

Revision can contain a variety of changed elements.

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.

Solutions Architecture: Associations and Mapping

Placeholder for mapping designs

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?

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.

Proposed Solution

Model Changes

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

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

Content Representation

MRSAT Mappings

MRSAT Column	Function	LexGrid Equivalent
MAPSETVERSION		Relations.representsVersion
FROMVSAB	The from code system version	Relations.fromCodingSchemeVersion
FROMRSAB	The from code system	Relations.FromCodingScheme
TOVSAB	The to code system version	Relations.toCodingSchemeVersion
TORSAB	The to code system	Relations.toCodingScheme
MAPSETRSAB	Source of the value set	Relations.owner
(anything else)		Relations.property[key]

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:

MRMAP Flattened Option

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

MRMAP Expanded Option |

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

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.

Sample Mapping 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>

Implications for CTS 2 Mapping Implementation

Unknown macro: {table}

Unknown macro: {tr}

Unknown macro: {td}

CTS 2 Function

Unknown macro: {td}

Description

Unknown macro: {td}

Scope

Unknown macro: {tr}

Unknown macro: {td}

Update Association Status

Unknown macro: {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

Unknown macro: {td}

In scope for authoring API

Unknown macro: {tr}

Unknown macro: {td}

Create Association

Unknown macro: {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.

Unknown macro: {td}

In scope for authoring. Querying already supported

Unknown macro: {tr}

Unknown macro: {td}

Create Lexical Association between Coded Concepts

Unknown macro: {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).

Unknown macro: {td}

Not in scope for CTS 2

Unknown macro: {tr}

Unknown macro: {td}

Create Rules Based Association between Coded Concepts

Unknown macro: {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).

Unknown macro: {td}

Not in scope for CTS 2

Solution Architecture

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)

Cross product dependencies

Include a link to the Core Product Dependency Matrix.

Changes in technology

Include any new dependencies in the Core Product Dependency Matrix and summarize them here.

Assumptions

List any assumptions.

Risks

List any risks.

Content

Space Tools

LexEVS 6.0 Design Document - Solution Architecture

Solution Architecture

High Level Architecture

Structure of the CTS 2 Service

Semantic Profiles

High Level Design Diagram

CTS 2 Functional Profiles

CTS 2 Query Profile

Terminology Administration Profile

Terminology Authoring Profile

A Sub Categorization of Services

CTS Service Interfaces

GForge items

Use cases

Related requirements

Solutions Architecture: XML Loads of LexGrid Modeled Content

Overview:

Streaming XML Implementation

Entry Points Expanded

Coding Scheme Entry Point

Revision Entry Point

System Release Entry Point

Solutions Architecture: Associations and Mapping

Levels of Mapping Implementation implied by current requirements from various stakeholders

Evaluation of Levels of Mapping Implementation for CTS 2

Proposed Solution

Content Representation

MRSAT Mappings

MRMAP Mappings |

MRMAP Flattened Option

MRMAP Expanded Option |

Expression Issues

Sample Mapping XML

Implications for CTS 2 Mapping Implementation

Solution Architecture

Data Access Layer

Cross product dependencies

Changes in technology

Assumptions

Risks