Page History
...
The following table is a mapping between the elements in the Component & Connector Client-Server view shown in section 3.1.1, and the Modules Decomposition and Uses views shown in sections 3.2.1 and 3.2.2.
The relationship shown is is-implemented-by, i.e. the elements from the C&C view shown at the top of the table are implemented by any selected elements from the Modules views, denoted by an "X" in the corresponding cell.
| ONT Server | Project Management Server | Metadata Database |
ONT Service | X | X |
|
Ontology Webservice | X |
|
|
Request Handler | X |
|
|
Request DAO | X |
| X |
Vocabulary Data Object | X |
|
|
...
Both the metadata and the patient data are distributed to projects through the existence of independent databases (in SQL Server) or schemas (in Oracle). These will be referred to in the rest of the text as the "persistent storage location" or PSL. These PSL's are organized so that the data from two metadata representations can be merged to a "Super" data set. While a person is working on a specific project, they will be directed to data in a PSL associated with that project.
In order to support the i2b2 project distribution strategy, the user is enrolled in numerous projects recorded within the i2b2 project management cell". The projects available to the user are returned in the web service call to the Project Management cell. The logic of selecting the correct PSL for the project is embodied in the following table:
DB_LOOKUP |
|
|
PK | c_domain_id | VARCHAR(255) |
PK | c_project_path | VARCHAR(255) |
PK | c_owner_id | VARCHAR(255) |
| c_db_fullschema | VARCHAR(255) |
| c_db_datasource | VARCHAR(255) |
| c_db_servertype | VARCHAR(255) |
| c_db_nicename | VARCHAR(255) |
| c_db_tooltip | VARCHAR(255) |
| c_comment | CLOB |
| c_entry_date | DATE |
| c_change_date | DATE |
| c_status_cd | CHAR(1) |
The logic for selecting the PSL is as follows:
- There are two methods to select the correct PSL, an implicit one, and an explicit one. Both rely only on information available within the i2b2 header.
...
- The implicit one relies upon the data within the <domain> tag, the <username> tag, and the <project_id> tag.
- The explicit one relies upon the data only within the <project_id> tag. It has the format represented as the following string:
"DOMAIN" | "Project" \"subproject"\"sub-sub Project" | "USER_ID" |
- These may not actually match the domain and username that is actually being used (since it is being built by the client), and must be checked when the PM cell is accessed.
...
Other columns are specified as follows:
- The column _c_db_fullschema_ is used to contain the path to a table when the data source is used. Software is written so that the absence of the delimiter (usually a ".") does not need to be explicitly stated.
- The column _c_db_datasource_ is used to contain a short string that represents a data source configured in some other location.
- The column _c_db_servertype_ can be "ORACLE" or "SQLSERVER".
- The column _c_db_nicename_ is a string that can be used in client software to describe a data source.
- The column _c_db_tooltip_ contains a longer (hierarchical) representation of the nicename.
...
The Metadata table encapsulates the vocabulary used in the data repository. A term (concept or provider) is a row from the Metadata table. It is the primary object used to pass vocabulary information to the requesting client. Typically a PSL will contain numerous Metadata tables, each with a name that indicates the domain that the vocabulary contained within represents.
METADATA |
|
|
PK | c_fullname | VARCHAR(700) |
PK | c_name | VARCHAR(2000) |
| c_hlevel | INT |
| c_synonym_cd | CHAR(1) |
| c_visualattributes | CHAR(3) |
| c_tooltip | VARCHAR(900) |
| c_total_num | INT |
| c_basecode | VARCHAR(50) |
| c_comment | CLOB |
| c_metadataxml | CLOB |
| c_facttablecolumn | VARCHAR(50) |
| c_tablename | VARCHAR(50) |
| c_columnname | VARCHAR(50) |
| c_columndatatype | VARCHAR(50) |
| c_operator | VARCHAR(10) |
| c_dimcode | VARCHAR(700) |
| update_date | DATE |
| download_date | DATE |
| import_date | DATE |
| sourcesystem_cd | VARCHAR(50) |
| valuetype_cd | VARCHAR(50) |
...
Release 1.5 introduced the ablility to create new metadata or edit existing metadata within the i2b2 workbench. Once metadata has been created or edited it is necessary to synchronize these changes with the appropriate dimension table. The concept_dimension table would need to be updated with new concept terms; likewise provider_dimension table would need to be updated with new provider terms and the modifier_dimension table could need to be updated with new modifier terms.
The Process Status table provides information about the synchronization between the ontology metadata tables and the dimension tables.
PROCESS STATUS |
|
|
PK | process_id | INT |
| process_type_cd | VARCHAR(50) |
| start_date | DATE |
| end_date | DATE |
| process_step_cd | VARCHAR(50) |
| process_status_cd | VARCHAR(50) |
| crc_upload_id | VARCHAR(5) |
| status_cd | VARCHAR(50) |
| message | VARCHAR(2000) |
| entry_date | DATE |
| change_date | DATE |
| changedby_char | CHAR(50) |
...
ontology.aarontology-server.jarontology-core.jar<<deployment>><<deployment>><<deployment>>JBoss Application ServerOracleDatabaseServer
