Skip to Content

Changes for page 04. Technické informace

Last modified by Branislav ŠIŠKA on 2024/09/12 19:22
From version 2.1
edited by Branislav ŠIŠKA
on 2022/02/25 15:09
Change comment: There is no comment for this version
To version 3.1
edited by Branislav ŠIŠKA
on 2022/02/25 15:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Technické informace a validace systému
1 +Technické informace
Content
... ... @@ -1,55 +2,37 @@
1 -(% style="" %)
2 2  = {{id name="04.Technickéinformace-1.Hardware"/}}1. Hardware =
3 3  
4 -(% style="" %)
5 5  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.
6 6  
7 -(% style="" %)
8 8  === {{id name="04.Technickéinformace-Descriptionofhardware"/}}Description of hardware ===
9 9  
10 -(% style="" %)
11 11  **Servers**
12 12  
13 -(% style="" %)
14 14  Blade chassis - BM Flex System Enterprise Chassis
15 15  
16 -(% style="" %)
17 17  14x Compute node IBM Flex System x240 with 10 GB virtual fabric
18 18  
19 -(% style="" %)
20 20  2x CPU Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz / 8C
21 21  
22 -(% style="" %)
23 23  6x DDRIII SDRAM – 8GB
24 24  
25 -(% style="" %)
26 26  **Data Storages**
27 27  
28 -(% style="" %)
29 29  HP 3PAR data storage 700TB.
30 30  
31 -(% style="" %)
32 32  HP EML tape library
33 33  
34 -(% style="" %)
35 35  **Firewall**
36 36  
37 -(% style="" %)
38 38  HP F1000-S-EI VPN Firewall
39 39  
40 -(% style="" %)
41 41  **~ **
42 42  
43 -(% style="" %)
44 44  = {{id name="04.Technickéinformace-2.Software"/}}2. Software =
45 45  
46 -(% style="" %)
47 47  === {{id name="04.Technickéinformace-Thesoftwarerequirements"/}}The software requirements ===
48 48  
49 -(% style="" %)
50 50  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:
51 51  
52 -(% style="" %)
53 53  * Chrome: (Current - 1) and Current
54 54  * Edge: (Current - 1) and Current
55 55  * Firefox: (Current - 1) and Current
... ... @@ -57,16 +57,12 @@
57 57  * Safari: (Current - 1) and Current
58 58  * Opera: Current
59 59  
60 -(% style="" %)
61 61  (Current means the last available version of given browser)
62 62  
63 -(% style="" %)
64 64  === {{id name="04.Technickéinformace-Programminglanguage"/}}Programming language ===
65 65  
66 -(% style="" %)
67 67  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:
68 68  
69 -(% style="" %)
70 70  * Spring Framework v5.
71 71  * HTML, CSS
72 72  * JavaScript
... ... @@ -78,49 +78,34 @@
78 78  * SQL
79 79  * Oracle database
80 80  
81 -(% style="" %)
82 82  === {{id name="04.Technickéinformace-Operationsystem"/}}Operation system ===
83 83  
84 -(% style="" %)
85 85  Operation system installed on production servers is **RedHat Enterprise Linux 7.4.**
86 86  
87 -(% style="" %)
88 88  === {{id name="04.Technickéinformace-Proxyserver"/}}Proxy server ===
89 89  
90 -(% style="" %)
91 91  The **Apache HTTP Server** is used as gateway from outside world to internal application running in the production server.
92 92  
93 -(% style="" %)
94 94  === {{id name="04.Technickéinformace-Applicationserver"/}}Application server ===
95 95  
96 -(% style="" %)
97 97  The **ClinData** application runs on **Apache Tomcat,** which is an open-source Java Servlet Container developed by the Apache Software Foundation
98 98  
99 -(% style="" %)
100 100  **~ **
101 101  
102 -(% style="" %)
103 103  = {{id name="04.Technickéinformace-3.Database"/}}3. Database =
104 104  
105 -(% style="" %)
106 106  === {{id name="04.Technickéinformace-TheClindataDatabase"/}}The (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) Database ===
107 107  
108 -(% style="" %)
109 109  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.
110 110  
111 -(% style="" %)
112 112  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).
113 113  
114 -(% style="" %)
115 115  **~ **
116 116  
117 -(% style="" %)
118 118  = {{id name="04.Technickéinformace-4.Backup"/}}4. Backup =
119 119  
120 -(% style="" %)
121 121  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**
122 122  
123 -(% style="" %)
124 124  1. Database level backups
125 125  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.
126 126  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.
... ... @@ -127,13 +127,10 @@
127 127  1*. **Redo Logs** are archived **every day** to filesystem.
128 128  1. Operation system backups
129 129  
130 -(% style="" %)
131 131  * **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.
132 132  
133 -(% style="" %)
134 134  RMAN configuration file
135 135  
136 -(% style="" %)
137 137  CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
138 138  CONFIGURE BACKUP OPTIMIZATION OFF; # default
139 139  CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
... ... @@ -149,10 +149,8 @@
149 149  CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
150 150  CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/../../oracle/12c/dbs/snapcf_imtm.f'; # default
151 151  
152 -(% style="" %)
153 153  EXPDP configuration file
154 154  
155 -(% style="" %)
156 156  DIRECTORY=dtpump
157 157  DUMPFILE=registry.dmp
158 158  LOGFILE=registry.log
... ... @@ -161,57 +161,40 @@
161 161  JOB_NAME=registry_migration
162 162  SCHEMAS=registry,registry_aud
163 163  
164 -(% style="" %)
165 165  = {{id name="04.Technickéinformace-05.Secureconnection"/}}05. Secure connection =
166 166  
167 -(% style="" %)
168 168  === {{id name="04.Technickéinformace-Security"/}}Security ===
169 169  
170 -(% style="" %)
171 171  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.
172 172  
173 -(% style="" %)
174 174  === {{id name="04.Technickéinformace-Securityredirection"/}}Security redirection ===
175 175  
176 -(% style="" %)
177 177  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.
178 178  
179 -(% style="" %)
180 180  === {{id name="04.Technickéinformace-Certificate"/}}Certificate ===
181 181  
182 -(% style="" %)
183 183  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.
184 184  
185 -(% style="" %)
186 186  **~ **
187 187  
188 -(% style="" %)
189 189  = {{id name="04.Technickéinformace-06.Authenticationandauthorization"/}}06. Authentication and authorization =
190 190  
191 -(% style="" %)
192 192  === {{id name="04.Technickéinformace-Usersadministration"/}}Users administration ===
193 193  
194 -(% style="" %)
195 195  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.
196 196  
197 -(% style="" %)
198 198  The **Admin tool** is responsible for:
199 199  
200 -(% style="" %)
201 201  * 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.
202 202  * 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**.
203 203  * Management **roles and profiles**.
204 204  
205 -(% style="" %)
206 206  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.
207 207  
208 -(% style="" %)
209 209  An account for new user can be created **only by administrator**. There is no way that user could create his account on its own.
210 210  
211 -(% style="" %)
212 212  These steps must be followed to **create new account**:
213 213  
214 -(% style="" %)
215 215  * New user asks a project owner to create new account
216 216  * The project owner asks administrator to create new account with specified privileges and roles
217 217  * The administrator creates new account and sets required privileges and roles
... ... @@ -218,53 +218,37 @@
218 218  * The project owner checks account setting and approve it.
219 219  * New user receives his credentials and can log in.
220 220  
221 -(% style="" %)
222 222  === {{id name="04.Technickéinformace-Centralauthenticationservice(CAS)"/}}Central authentication service (CAS) ===
223 223  
224 -(% style="" %)
225 225  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.
226 226  
227 -(% style="" %)
228 228  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.
229 229  
230 -(% style="" %)
231 231  = {{id name="04.Technickéinformace-07.PrivilegesandRoles"/}}07. Privileges and Roles =
232 232  
233 -(% style="" %)
234 234  === {{id name="04.Technickéinformace-Accessrestrictions"/}}**Access restrictions** ===
235 235  
236 -(% style="" %)
237 237  A user access can be restricted in two different areas:
238 238  
239 -(% style="" %)
240 240  * restriction in **access to** ClinData **functionality**
241 241  * restriction in **access to data** stored in the ClinData software
242 242  
243 -(% style="" %)
244 244  All restriction is set in the **IMTM Admin tool**.
245 245  
246 -(% style="" %)
247 247  === {{id name="04.Technickéinformace-Functionalityrestrictions"/}}Functionality restrictions ===
248 248  
249 -(% style="" %)
250 250  **Privileges**
251 251  
252 -(% style="" %)
253 253  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.
254 254  
255 -(% style="" %)
256 256  The picture shows schema of privileges in the (% style="color: rgb(23,43,77);text-decoration: none;" %)Clindata(%%) software.
257 257  
258 -(% style="" %)
259 259  **Roles**
260 260  
261 -(% style="" %)
262 262  Roles are virtual entities which serve as container for more privileges.
263 263  
264 -(% style="" %)
265 265  There are predefined roles and users, or groups of users can be assigned to them. The most frequently used roles are:
266 266  
267 -(% style="" %)
268 268  * ClinData system admin - full access to all functions in ClinData, no restrictions, creating new project
269 269  * ClinData project admin - full access to all function in selected project including study designer
270 270  * ClinData project data manager - access to all functions needed to insert new/update patient’s data.
... ... @@ -271,50 +271,36 @@
271 271  * ClinData project data monitor - access to all functions needed for study monitoring, validation and finishing CRFs.
272 272  * ClinData project data browser - read only access to selected data.
273 273  
274 -(% style="" %)
275 275  \\
276 276  
277 -(% style="" %)
278 278  === {{id name="04.Technickéinformace-Datarestrictions"/}}Data restrictions ===
279 279  
280 -(% style="" %)
281 281  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.
282 282  
283 -(% style="" %)
284 284  These options can be set:
285 285  
286 -(% style="" %)
287 287  * user can see only his data
288 288  * user can see data inserted by other user or group of users
289 289  * user can see data linked with an organization
290 290  * user can see all data in a study
291 291  
292 -(% style="" %)
293 293  === {{id name="04.Technickéinformace-Personaldata"/}}Personal data ===
294 294  
295 -(% style="" %)
296 296  There can be studies or registers which contain personal data. Access to this data can be restricted by special privilege.
297 297  
298 -(% style="" %)
299 299  These options can be set:
300 300  
301 -(% style="" %)
302 302  * user can see personal data
303 303  * user can't see personal data
304 304  
305 -(% style="" %)
306 306  \\
307 307  
308 -(% style="" %)
309 309  = {{id name="04.Technickéinformace-8.Logging"/}}8. Logging =
310 310  
311 -(% style="" %)
312 312  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.
313 313  
314 -(% style="" %)
315 315  There are three different types of logging mechanisms:
316 316  
317 -(% style="" %)
318 318  * **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.
319 319  * **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:
320 320  ** create
... ... @@ -330,65 +330,44 @@
330 330  ** what was changed
331 331  ** what is the new value
332 332  
333 -(% style="" %)
334 334  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.
335 335  
336 -(% style="" %)
337 337  **~ **
338 338  
339 -(% style="" %)
340 340  = {{id name="04.Technickéinformace-9.Softwaredevelopment"/}}9. Software development =
341 341  
342 -(% style="" %)
343 343  === {{id name="04.Technickéinformace-Issuetracking"/}}Issue tracking ===
344 344  
345 -(% style="" %)
346 346  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.
347 347  
348 -(% style="" %)
349 349  === {{id name="04.Technickéinformace-Changesmanagement"/}}Changes management ===
350 350  
351 -(% style="" %)
352 352  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.
353 353  
354 -(% style="" %)
355 355  === {{id name="04.Technickéinformace-Versioning"/}}Versioning ===
356 356  
357 -(% style="" %)
358 358  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.
359 359  
360 -(% style="" %)
361 361  === {{id name="04.Technickéinformace-Codereview"/}}Code review ===
362 362  
363 -(% style="" %)
364 364  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.
365 365  
366 -(% style="" %)
367 367  **~ **
368 368  
369 -(% style="" %)
370 370  = {{id name="04.Technickéinformace-10.Qualityassurance"/}}10. Quality assurance =
371 371  
372 -(% style="" %)
373 373  === {{id name="04.Technickéinformace-Testingenvironment"/}}Testing environment ===
374 374  
375 -(% style="" %)
376 376  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.
377 377  
378 -(% style="" %)
379 379  === {{id name="04.Technickéinformace-Unittesting"/}}Unit testing ===
380 380  
381 -(% style="" %)
382 382  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.
383 383  
384 -(% style="" %)
385 385  === {{id name="04.Technickéinformace-Applicationtesting"/}}Application testing ===
386 386  
387 -(% style="" %)
388 388  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.
389 389  
390 -(% style="" %)
391 391  === {{id name="04.Technickéinformace-Publishing"/}}Publishing ===
392 392  
393 -(% style="" %)
394 394  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 -58786201
1 +95617106
Title
... ... @@ -1,1 +1,1 @@
1 -Technické informace a validace systému
1 +Technické informace