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
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.
|