Changes for page 04. Technické informace
Last modified by Branislav ŠIŠKA on 2024/09/12 19:22
From version 3.1
edited by Branislav ŠIŠKA
on 2022/02/25 15:34
on 2022/02/25 15:34
Change comment:
There is no comment for this version
To version 2.1
edited by Branislav ŠIŠKA
on 2022/02/25 15:09
on 2022/02/25 15:09
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Objects (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -Technické informace 1 +Technické informace a validace systému - Content
-
... ... @@ -1,37 +1,55 @@ 1 +(% style="" %) 1 1 = {{id name="04.Technickéinformace-1.Hardware"/}}1. Hardware = 2 2 4 +(% style="" %) 3 3 The Clindata software runs on computer cluster located on Institute of Molecular and Translational Medicine (IMTM), Faculty of Medicine and Dentistry, Palacky University in Olomouc. The facility is secured and under global surveillance. 4 4 7 +(% style="" %) 5 5 === {{id name="04.Technickéinformace-Descriptionofhardware"/}}Description of hardware === 6 6 10 +(% style="" %) 7 7 **Servers** 8 8 13 +(% style="" %) 9 9 Blade chassis - BM Flex System Enterprise Chassis 10 10 16 +(% style="" %) 11 11 14x Compute node IBM Flex System x240 with 10 GB virtual fabric 12 12 19 +(% style="" %) 13 13 2x CPU Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz / 8C 14 14 22 +(% style="" %) 15 15 6x DDRIII SDRAM – 8GB 16 16 25 +(% style="" %) 17 17 **Data Storages** 18 18 28 +(% style="" %) 19 19 HP 3PAR data storage 700TB. 20 20 31 +(% style="" %) 21 21 HP EML tape library 22 22 34 +(% style="" %) 23 23 **Firewall** 24 24 37 +(% style="" %) 25 25 HP F1000-S-EI VPN Firewall 26 26 40 +(% style="" %) 27 27 **~ ** 28 28 43 +(% style="" %) 29 29 = {{id name="04.Technickéinformace-2.Software"/}}2. Software = 30 30 46 +(% style="" %) 31 31 === {{id name="04.Technickéinformace-Thesoftwarerequirements"/}}The software requirements === 32 32 49 +(% style="" %) 33 33 The only requirement for using the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is Internet browser which supports HTML5 standard. The list of supported browsers: 34 34 52 +(% style="" %) 35 35 * Chrome: (Current - 1) and Current 36 36 * Edge: (Current - 1) and Current 37 37 * Firefox: (Current - 1) and Current ... ... @@ -39,12 +39,16 @@ 39 39 * Safari: (Current - 1) and Current 40 40 * Opera: Current 41 41 60 +(% style="" %) 42 42 (Current means the last available version of given browser) 43 43 63 +(% style="" %) 44 44 === {{id name="04.Technickéinformace-Programminglanguage"/}}Programming language === 45 45 66 +(% style="" %) 46 46 The main programming language used for development of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) application is Java 8. Other technologies used for development are: 47 47 69 +(% style="" %) 48 48 * Spring Framework v5. 49 49 * HTML, CSS 50 50 * JavaScript ... ... @@ -56,34 +56,49 @@ 56 56 * SQL 57 57 * Oracle database 58 58 81 +(% style="" %) 59 59 === {{id name="04.Technickéinformace-Operationsystem"/}}Operation system === 60 60 84 +(% style="" %) 61 61 Operation system installed on production servers is **RedHat Enterprise Linux 7.4.** 62 62 87 +(% style="" %) 63 63 === {{id name="04.Technickéinformace-Proxyserver"/}}Proxy server === 64 64 90 +(% style="" %) 65 65 The **Apache HTTP Server** is used as gateway from outside world to internal application running in the production server. 66 66 93 +(% style="" %) 67 67 === {{id name="04.Technickéinformace-Applicationserver"/}}Application server === 68 68 96 +(% style="" %) 69 69 The **ClinData** application runs on **Apache Tomcat,** which is an open-source Java Servlet Container developed by the Apache Software Foundation 70 70 99 +(% style="" %) 71 71 **~ ** 72 72 102 +(% style="" %) 73 73 = {{id name="04.Technickéinformace-3.Database"/}}3. Database = 74 74 105 +(% style="" %) 75 75 === {{id name="04.Technickéinformace-TheClindataDatabase"/}}The (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) Database === 76 76 108 +(% style="" %) 77 77 The database used for storing data from the (% style="color: rgb(23,43,77);text-decoration: none;" %)**Clindata**(%%)** **software is **Oracle Database** (commonly referred to as **Oracle RDBMS**) which is produced by Oracle Corporation. Version of database is 12.1. Standard edition. 78 78 111 +(% style="" %) 79 79 The Oracle database runs on separated Linux based server which si firewalled from external network (Internet) by hardware firewall. This database server is not accessible from outside of organization but only from enlisted inner servers (application and backup servers). 80 80 114 +(% style="" %) 81 81 **~ ** 82 82 117 +(% style="" %) 83 83 = {{id name="04.Technickéinformace-4.Backup"/}}4. Backup = 84 84 120 +(% style="" %) 85 85 There are more levels of data archiving to ensure data safety and quick database recovery. Data are archived on **database level** and **operation system level** 86 86 123 +(% style="" %) 87 87 1. Database level backups 88 88 1*. **RMAN** utility is integral part of the Oracle database. It creates binary copy of whole database and stores it to filesystem. The RMAN utility is run **every week**. The files are stored internally on database server and are copied to two independent backup sites. 89 89 1*. **EXPDP/IMPDP** is data pump exporting data into text base backups. The EXPDP utility is run **every 4 hours**. The backup target is the same as with RMAN. It is stored to two independent backup sites. ... ... @@ -90,10 +90,13 @@ 90 90 1*. **Redo Logs** are archived **every day** to filesystem. 91 91 1. Operation system backups 92 92 130 +(% style="" %) 93 93 * **IBM Tivoli Storage Manager** (TSM Admin) is enterprise solution from IBM for backups and recovery of physical or virtual servers. The backup created by TSM Admin includes redo logs, RMAN and EXPDP exports. It runs **every day** and the backup data is stored to disk array. 94 94 133 +(% style="" %) 95 95 RMAN configuration file 96 96 136 +(% style="" %) 97 97 CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default 98 98 CONFIGURE BACKUP OPTIMIZATION OFF; # default 99 99 CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default ... ... @@ -109,8 +109,10 @@ 109 109 CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default 110 110 CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/../../oracle/12c/dbs/snapcf_imtm.f'; # default 111 111 152 +(% style="" %) 112 112 EXPDP configuration file 113 113 155 +(% style="" %) 114 114 DIRECTORY=dtpump 115 115 DUMPFILE=registry.dmp 116 116 LOGFILE=registry.log ... ... @@ -119,40 +119,57 @@ 119 119 JOB_NAME=registry_migration 120 120 SCHEMAS=registry,registry_aud 121 121 164 +(% style="" %) 122 122 = {{id name="04.Technickéinformace-05.Secureconnection"/}}05. Secure connection = 123 123 167 +(% style="" %) 124 124 === {{id name="04.Technickéinformace-Security"/}}Security === 125 125 170 +(% style="" %) 126 126 As the (% style="color: rgb(23,43,77);text-decoration: none;" %)**Clindata**(%%)** **application is **web-based** application there is need to **secure communication** between **server** and **client's computer**. It is done by using **HTTPS** communication protocol which is encrypted using Transport Layer Security **(TLS).** This protocol is widely used for all secure transactions on the Internet (payment, emails etc.) and is considered as safe and unbreakable. It protects against man in-the middle attacks. Communication without the security layer (HTTP) is can be interfered by attackers, they can listen to it or change it. 127 127 173 +(% style="" %) 128 128 === {{id name="04.Technickéinformace-Securityredirection"/}}Security redirection === 129 129 176 +(% style="" %) 130 130 All user requests coming via unsecured **HTTP** protocol are automatically **redirected** to secure **HTTPS** protocol. All communication between client and server is secured and there is no way how to connect to the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software via unsecured connection. 131 131 179 +(% style="" %) 132 132 === {{id name="04.Technickéinformace-Certificate"/}}Certificate === 133 133 182 +(% style="" %) 134 134 The secured communication requires a certificate stored on the web server. The certificate must be signed by **trusted certificate authority**. The (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) server uses the certificate digitally signed by **TERENA** authority. 135 135 185 +(% style="" %) 136 136 **~ ** 137 137 188 +(% style="" %) 138 138 = {{id name="04.Technickéinformace-06.Authenticationandauthorization"/}}06. Authentication and authorization = 139 139 191 +(% style="" %) 140 140 === {{id name="04.Technickéinformace-Usersadministration"/}}Users administration === 141 141 194 +(% style="" %) 142 142 All user using the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) application must be registered before they can log in. There is no possibility to get unauthorized access to the server even for some demonstration purposes. There is a specialized application for user management - IMTM Admin tool. 143 143 197 +(% style="" %) 144 144 The **Admin tool** is responsible for: 145 145 200 +(% style="" %) 146 146 * Management of **institutions, companies, hospitals** and their departments. There can be unlimited number of organization levels, for example a university can have such structure university-faculty-department-laboratory. Each organization level can obtain different set of privileges and roles. 147 147 * Management of **users**. Every user is identified by email address as login and password. Users are assigned to their organizations. Users can work on more projects with different roles. It is allowed by** user profiles**. Number of profiles for a user is not limited. Each profile can have different set of **privileges and roles**. 148 148 * Management **roles and profiles**. 149 149 205 +(% style="" %) 150 150 The Admin database with user's data is stored in the Oracle database as separated schema. Access to this schema is restricted only for admin users. The server with the Oracle database is firewalled out of public network and not accessible from Internet. 151 151 208 +(% style="" %) 152 152 An account for new user can be created **only by administrator**. There is no way that user could create his account on its own. 153 153 211 +(% style="" %) 154 154 These steps must be followed to **create new account**: 155 155 214 +(% style="" %) 156 156 * New user asks a project owner to create new account 157 157 * The project owner asks administrator to create new account with specified privileges and roles 158 158 * The administrator creates new account and sets required privileges and roles ... ... @@ -159,37 +159,53 @@ 159 159 * The project owner checks account setting and approve it. 160 160 * New user receives his credentials and can log in. 161 161 221 +(% style="" %) 162 162 === {{id name="04.Technickéinformace-Centralauthenticationservice(CAS)"/}}Central authentication service (CAS) === 163 163 224 +(% style="" %) 164 164 The (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) application must be connected with data from the IMTM Admin to control accounts, roles and privileges. It is done by integrating of the CAS technology into the ClinData software. The CAS technology consists of CAS Server and CAS Client. 165 165 227 +(% style="" %) 166 166 The CAS server is responsible for authenticating users and granting accesses to applications. The CAS clients protect the CAS applications and retrieve the identity of the granted users from the CAS server. 167 167 230 +(% style="" %) 168 168 = {{id name="04.Technickéinformace-07.PrivilegesandRoles"/}}07. Privileges and Roles = 169 169 233 +(% style="" %) 170 170 === {{id name="04.Technickéinformace-Accessrestrictions"/}}**Access restrictions** === 171 171 236 +(% style="" %) 172 172 A user access can be restricted in two different areas: 173 173 239 +(% style="" %) 174 174 * restriction in **access to** ClinData **functionality** 175 175 * restriction in **access to data** stored in the ClinData software 176 176 243 +(% style="" %) 177 177 All restriction is set in the **IMTM Admin tool**. 178 178 246 +(% style="" %) 179 179 === {{id name="04.Technickéinformace-Functionalityrestrictions"/}}Functionality restrictions === 180 180 249 +(% style="" %) 181 181 **Privileges** 182 182 252 +(% style="" %) 183 183 Access privileges determine which (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) objects a user can browse or edit. Each functionality in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is reflected in corresponding privilege so the access to everything is controlled. Any user or group of users can have access to any privilege granted or restricted. 184 184 255 +(% style="" %) 185 185 The picture shows schema of privileges in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software. 186 186 258 +(% style="" %) 187 187 **Roles** 188 188 261 +(% style="" %) 189 189 Roles are virtual entities which serve as container for more privileges. 190 190 264 +(% style="" %) 191 191 There are predefined roles and users, or groups of users can be assigned to them. The most frequently used roles are: 192 192 267 +(% style="" %) 193 193 * ClinData system admin - full access to all functions in ClinData, no restrictions, creating new project 194 194 * ClinData project admin - full access to all function in selected project including study designer 195 195 * ClinData project data manager - access to all functions needed to insert new/update patient’s data. ... ... @@ -196,36 +196,50 @@ 196 196 * ClinData project data monitor - access to all functions needed for study monitoring, validation and finishing CRFs. 197 197 * ClinData project data browser - read only access to selected data. 198 198 274 +(% style="" %) 199 199 \\ 200 200 277 +(% style="" %) 201 201 === {{id name="04.Technickéinformace-Datarestrictions"/}}Data restrictions === 202 202 280 +(% style="" %) 203 203 Default setting for accessing of data in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is maximally restricted. A user can see only data he inserted himself. By default, he doesn't see any data inserted by any other user. Access to any other data must be explicitly permitted. 204 204 283 +(% style="" %) 205 205 These options can be set: 206 206 286 +(% style="" %) 207 207 * user can see only his data 208 208 * user can see data inserted by other user or group of users 209 209 * user can see data linked with an organization 210 210 * user can see all data in a study 211 211 292 +(% style="" %) 212 212 === {{id name="04.Technickéinformace-Personaldata"/}}Personal data === 213 213 295 +(% style="" %) 214 214 There can be studies or registers which contain personal data. Access to this data can be restricted by special privilege. 215 215 298 +(% style="" %) 216 216 These options can be set: 217 217 301 +(% style="" %) 218 218 * user can see personal data 219 219 * user can't see personal data 220 220 305 +(% style="" %) 221 221 \\ 222 222 308 +(% style="" %) 223 223 = {{id name="04.Technickéinformace-8.Logging"/}}8. Logging = 224 224 311 +(% style="" %) 225 225 The ClinData software **records everything** happening in the system. Admin user can browse these records in user friendly way and analyze potential problems, watch user activities etc. 226 226 314 +(% style="" %) 227 227 There are three different types of logging mechanisms: 228 228 317 +(% style="" %) 229 229 * **Software logging** is done on programming language level and is very detailed. The log files contain data about internal state of the whole system in time of logging event. This approach is designed for detailed analyses of problems which happened in past. 230 230 * **Access logging** is designed for controlling of user’s activities. The access record contains data about who did an action and when. It logs all actions done on all objects in the system. Object can be study, patient, CRF form, file. These actions are logged: 231 231 ** create ... ... @@ -241,44 +241,65 @@ 241 241 ** what was changed 242 242 ** what is the new value 243 243 333 +(% style="" %) 244 244 The important information is that the ClinData software** doesn't delete any record**. Every record in the database has system **flag ACTIVE**. Deleting of the row just sets this **ACTIVE** flag to **false**. The inactive rows are not displayed in the ClinData software but are still stored in the database. 245 245 336 +(% style="" %) 246 246 **~ ** 247 247 339 +(% style="" %) 248 248 = {{id name="04.Technickéinformace-9.Softwaredevelopment"/}}9. Software development = 249 249 342 +(% style="" %) 250 250 === {{id name="04.Technickéinformace-Issuetracking"/}}Issue tracking === 251 251 345 +(% style="" %) 252 252 Any problem found in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is documented and created as a **new issue in JIRA software**. JIRA software is developed by Atlassian and is an issue tracking tool. The new issue is analyzed, and priority is assigned. The list of issues is sorted by priorities and processed by developers. When a serious problem is fixed then it is published in new version of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software. The issue is also closed as done in JIRA. 253 253 348 +(% style="" %) 254 254 === {{id name="04.Technickéinformace-Changesmanagement"/}}Changes management === 255 255 351 +(% style="" %) 256 256 All requests for changes planned in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software are stored in JIRA. When a new request is coming then it is analyzed, time estimation is done, and priority assigned. The list of issues is sorted by priorities and processed by developers. 257 257 354 +(% style="" %) 258 258 === {{id name="04.Technickéinformace-Versioning"/}}Versioning === 259 259 357 +(% style="" %) 260 260 The source code of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is stored in** GIT repository** which allows tracking of changes in files. There is possibility to browse history of any source code file in the repository. Every change is also documented so it is easy to understand the development cycle. 261 261 360 +(% style="" %) 262 262 === {{id name="04.Technickéinformace-Codereview"/}}Code review === 263 263 363 +(% style="" %) 264 264 Any change done in source code of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software must be **reviewed** by another developer. This process is called **code review**. This process minimizes number of bugs in source code because everything is double checked. **Bitbucket software** (developed by Atlassian) is used for code reviews. It prevents developers from using not proven code in public versions of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software. 265 265 366 +(% style="" %) 266 266 **~ ** 267 267 369 +(% style="" %) 268 268 = {{id name="04.Technickéinformace-10.Qualityassurance"/}}10. Quality assurance = 269 269 372 +(% style="" %) 270 270 === {{id name="04.Technickéinformace-Testingenvironment"/}}Testing environment === 271 271 375 +(% style="" %) 272 272 All new versions of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software must be tested and proven as functional and correct before they are published. There is a special environment which is used form testing of the new version before it is published. The testing environment must be similar to production environment to avoid configuration issues. 273 273 378 +(% style="" %) 274 274 === {{id name="04.Technickéinformace-Unittesting"/}}Unit testing === 275 275 381 +(% style="" %) 276 276 Unit testing is a software testing method by which individual units of source code are tested to determine whether they are fit for use. There are actually more than one thousand-unit tests in the source code of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software. All critical parts of the source code are covered by unit test close to 100%. Overall source code is covered by unit test by more than 85%. Any problem in unit testing is blocker for publishing of the version of the software. 277 277 384 +(% style="" %) 278 278 === {{id name="04.Technickéinformace-Applicationtesting"/}}Application testing === 279 279 387 +(% style="" %) 280 280 The whole application is tested by application exploratory testing before it is published. The application testing is done in testing environment. Any problem in application testing is blocker for publishing of the version. 281 281 390 +(% style="" %) 282 282 === {{id name="04.Technickéinformace-Publishing"/}}Publishing === 283 283 393 +(% style="" %) 284 284 Publishing process means that a new version of the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software is being released and made accessible for users. The Bamboo software (developed by Atlassian) is used for building and publishing new versions. Unit testing is also involved in publishing of the new version. In case of any problem in any unit test the whole publishing, process is interrupted, and an notification email is sent to responsible persons.
- Confluence.Code.ConfluencePageClass[0]
-
- Id
-
... ... @@ -1,1 +1,1 @@ 1 - 956171061 +58786201 - Title
-
... ... @@ -1,1 +1,1 @@ 1 -Technické informace 1 +Technické informace a validace systému