Skip to Content

Changes for page 04. Technické informace

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

Summary

Details

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