Sign off |
Date |
Role |
CBIIT or Stakeholder Organization |
Reviewer's Comments (If disapproved indicate specific areas for improvement.) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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
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)
|