1. Hardware

The Clindata software runs on computer cluster located on Institute of Molecular and Translational Medicine Software Clindata běží na serverech umístěných v Institutu molekulární a translační medicíny (IMTM), Faculty of Medicine and Dentistry, Palacky University in Olomouc. The facility is secured and under global surveillance.

Description of hardware

Servers

Blade chassis - BM Flex System Enterprise Chassis

14x Compute node IBM Flex System x240 with 10 GB virtual fabric

2x CPU Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz / 8C

6x DDRIII SDRAM – 8GB

Data Storages

HP 3PAR data storage 700TB.

HP EML tape library

Firewall

Lékařské a stomatologické fakulty, Univerzity Palackého v Olomouci. Zařízení je zabezpečeno a pod dohledem globálního sledování.

Popis hardwaru

Server zapojený ve virtualizaci proxmox

Paměť: 48 GB

Procesory: 8 jader

Datová úložiště

Objektové úložiště

Firewall

FortiGate 600EHP F1000-S-EI VPN Firewall

2. Software

...

Požadavky na software

...

Jediným požadavkem pro použití softwaru Clindata je webový prohlížeč podporující standard HTML5. Seznam podporovaných prohlížečůThe only requirement for using the Clindata software is Internet browser which supports HTML5 standard. The list of supported browsers:

• Chrome: (Current Aktuální - 1) and Currenta aktuální
• Edge: (Current Aktuální - 1) and Currenta aktuální
• Firefox: (Current Aktuální - 1) and Currenta aktuální
• Internet Explorer: 11+
• Safari: (Current Aktuální - 1) and Currenta aktuální
• Opera: Current

(Current means the last available version of given browser)

Programming language

• Aktuální

(Aktuální znamená poslední dostupná verze daného prohlížeče)

Programovací jazyk

Hlavním programovacím jazykem používaným pro vývoj aplikace Clindata je Java 8. Další technologie používané při vývoji jsouThe main programming language used for development of the Clindata application is Java 8. Other technologies used for development are:

• Spring Framework v5.
• HTML, CSS
• JavaScript
• jQuery
• jQuery UI
• Bootstrap
• MathJS
• Datatables
• SQL
• Oracle database

Operation system

Operační systém

Operační systém nainstalovaný na produkčních serverech je Operation system installed on production servers is  RedHat Enterprise Linux 79.4. 

Proxy server

The Jako brána z vnějšího světa do vnitřní aplikace běžící na produkčním serveru se používá Apache HTTP Server is used as gateway from outside world to internal application running in the production server.

...

Aplikační server

The ClinData application runs on Aplikace ClinData běží na Apache Tomcat,  which is an což je open-source Java Servlet Container developed by the vyvíjený nadací Apache Software Foundation.

3.

...

Databáze

...

Databáze Clindata

...

Databáze používaná pro ukládání dat ze softwaru Clindata je Oracle Database (obvykle označovaná jako Oracle RDBMS), kterou vyvíjí společnost Oracle Corporation. Verze databáze je The database used for storing data from the Clindata software is Oracle Database (commonly referred to as Oracle RDBMS) which is produced by Oracle Corporation. Version of database is 12.1. Standard editionEdition.

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

 

4. Backup

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

1. Database level backups
• 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. 
• 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.
• Redo Logs are archived every day to filesystem. 
2. Operation system backups

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

Oracle databáze běží na odděleném serveru založeném na Linuxu, který je chráněn firewallem před vnější sítí (Internetem). Tento databázový server není přístupný zvenčí organizace, ale pouze ze zapsaných vnitřních serverů (aplikační a záložní servery).

4. Zálohy

Existují více úrovní archivace dat, které zajišťují bezpečnost dat a rychlé obnovení databáze. Data jsou archivována na úrovni databáze a operačního systému.

1. Zálohy na úrovni databáze
   Nástroj RMAN je nedílnou součástí Oracle databáze. Vytváří binární kopii celé databáze a ukládá ji do souborového systému. Nástroj RMAN je spuštěn každý týden. Soubory jsou uloženy interně na serveru databáze a jsou zkopírovány na dvě nezávislá záložní místa.
   EXPDP/IMPDP je datová pumpa, která exportuje data do textových záloh. Nástroj EXPDP je spuštěn každých 24 hodin. Cílem zálohování je stejné jako u RMAN. Data jsou uložena na dvou nezávislých záložních místech.
   Redo Logy jsou každý den archivovány do souborového systému.
2. Zálohy na úrovni operačního systému
   Aplikační server je zálohován na úrovni operačního systému pravidelně ve virtualizaci Proxmox.
   
   

RMAN konfigurační souborRMAN configuration file

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/../../oracle/12c/dbs/snapcf_imtm.f'; # default

...

DIRECTORY=dtpump
DUMPFILE=registry.dmp
LOGFILE=registry.log
CONTENT=ALL
COMPRESSION=NONE
JOB_NAME=registry_migration
SCHEMAS=registry,registry_aud

05.

...

Security

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

Security redirection

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 Clindata software via unsecured connection. 

Certificate

The secured communication requires a certificate stored on the web server. The certificate must be signed by trusted certificate authority. The Clindata server uses the certificate digitally signed by TERENA authority. 

06. Authentication and authorization

Users administration

All user using the 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.

The Admin tool is responsible for:

• 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. 
• 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.
• Management roles and profiles. 

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. 

An account for new user can be created only by administrator. There is no way that user could create his account on its own. 

These steps must be followed to create new account:

• New user asks a project owner to create new account
• The project owner asks administrator to create new account with specified privileges and roles
• The administrator creates new account and sets required privileges and roles
• The project owner checks account setting and approve it.
• New user receives his credentials and can log in.

Central authentication service (CAS)

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

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.

07. Privileges and Roles

Access restrictions

A user access can be restricted in two different areas:

• restriction in access to ClinData functionality
• restriction in access to data stored in the ClinData software

All restriction is set in the IMTM Admin tool.

Functionality restrictions

Privileges

Access privileges determine which Clindata objects a user can browse or edit. Each functionality in the 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.

The picture shows schema of privileges in the Clindata software.

Roles

Roles are virtual entities which serve as container for more privileges.

There are predefined roles and users, or groups of users can be assigned to them. The most frequently used roles are:

• ClinData system admin - full access to all functions in ClinData, no restrictions, creating new project
• ClinData project admin - full access to all function in selected project including study designer
• ClinData project data manager - access to all functions needed to insert new/update patient’s data.
• ClinData project data monitor - access to all functions needed for study monitoring, validation and finishing CRFs.
• ClinData project data browser - read only access to selected data.

Data restrictions

Default setting for accessing of data in the 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.

These options can be set:

• user can see only his data
• user can see data inserted by other user or group of users
• user can see data linked with an organization
• user can see all data in a study

Personal data

There can be studies or registers which contain personal data. Access to this data can be restricted by special privilege.

These options can be set:

• user can see personal data
• user can't see personal data

8. Logging

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.

There are three different types of logging mechanisms:

• 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.
• 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:
• create
• open
• change
• add
• remove
• delete
• export
• Auditing is focused to changes done in CRF forms. It records complete history of what was changed by users. One record contains data about:
• when the change was done
• who changed the data
• what was changed
• what is the new value

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.

9. Software development

Issue tracking

Any problem found in the 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 Clindata software. The issue is also closed as done in JIRA.

Changes management

All requests for changes planned in the 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.

Versioning

The source code of the 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.

Code review

Any change done in source code of the 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 Clindata software.

10. Quality assurance

Testing environment

All new versions of the 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.

Unit testing

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

Application testing

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.

Publishing

Bezpečnost připojení

Zabezpečené připojení 

Jelikož aplikace Clindata je webová aplikace, je nezbytné zajistit zabezpečenou komunikaci mezi serverem a klientovým počítačem. To je dosaženo pomocí komunikačního protokolu HTTPS, který je šifrován pomocí protokolu Transport Layer Security (TLS). Tento protokol je široce používán pro veškeré bezpečné transakce na internetu (platby, e-maily atd.) a je považován za bezpečný a nedekódovatelný. Chrání proti útokům prostředníka. Komunikace bez bezpečnostní vrstvy (HTTP) může být narušena útočníky, kteří ji mohou odposlouchávat nebo měnit.

Přesměrování zabezpečení

Všechny požadavky uživatele přicházející prostřednictvím nezabezpečeného protokolu HTTP jsou automaticky přesměrovány na zabezpečený protokol HTTPS. Veškerá komunikace mezi klientem a serverem je zabezpečena a není možné se připojit k softwaru Clindata prostřednictvím nezabezpečeného spojení.

Certifikát

Pro zabezpečenou komunikaci je vyžadován certifikát uložený na webovém serveru. Certifikát musí být podepsán důvěryhodnou certifikační autoritou. Server Clindata používá certifikát, který je digitálně podepsán autoritou TERENA.

06. Autenzizace a autorizace

Správa uživatelů

Všichni uživatelé používající aplikaci Clindata musí být registrováni před přihlášením. Není možné získat neoprávněný přístup k serveru ani pro demonstrační účely. Existuje specializovaná aplikace pro správu uživatelů - nástroj IMTM Admin.

Nástroj Admin je zodpovědný za:

• Správu institucí, společností, nemocnic a jejich oddělení. Může existovat neomezený počet úrovní organizací, například univerzita může mít strukturu univerzita-fakulta-oddělení-laboratoř. Každá úroveň organizace může získat odlišnou sadu oprávnění a rolí. Správa uživatelů. Každý uživatel je identifikován e-mailovou adresou jako přihlašovacím jménem a heslem.
• Uživatelé jsou přiřazeni ke svým organizacím. Uživatelé mohou pracovat na více projektech s různými rolemi. To je umožněno pomocí uživatelských profilů. Počet profilů pro jednoho uživatele není omezen. Každý profil může mít odlišnou sadu oprávnění a rolí.
• Správa rolí a profilů.

Databáze Admin s uživatelskými údaji je uložena v Oracle databázi jako samostatné schéma. Přístup k tomuto schématu je omezen pouze pro správce. Server s Oracle databází je oddělen firewallem od veřejné sítě a není přístupný z internetu.

Nový účet uživatele může být vytvořen pouze administrátorem. Uživatel nemá možnost vytvořit si účet sám.

Následující kroky musí být dodrženy při vytváření nového účtu:

• Nový uživatel požádá vlastníka projektu o vytvoření nového účtu.
• Vlastník projektu požádá administrátora o vytvoření nového účtu s určenými oprávněními a rolími.
• Administrátor vytvoří nový účet a nastaví požadovaná oprávnění a role.
• Vlastník projektu zkontroluje nastavení účtu a schválí ho.
• Nový uživatel obdrží přihlašovací údaje a může se přihlásit.

Centrální autentizační služba (CAS)

Aplikace Clindata musí být propojena s daty z IMTM Admin k ovládání účtů, rolí a oprávnění. To se provádí integrací technologie CAS do softwaru ClinData. Technologie CAS se skládá z CAS serveru a CAS klienta. CAS server je zodpovědný za ověřování uživatelů a poskytování přístupu k aplikacím. CAS klienti chrání aplikace CAS a získávají identitu povolených uživatelů ze serveru CAS.

07. Role a oprávnění

Omezení přístupu

Přístup uživatele může být omezen ve dvou různých oblastech:

• omezení přístupu k funkcionalitě ClinData
• omezení přístupu k datům uloženým v softwaru ClinData

Veškerá omezení jsou nastavena v nástroji IMTM Admin.

Omezení funkcí

Oprávnění

Oprávnění k přístupu určují, ke kterým objektům v ClinData může uživatel prohlížet nebo je upravovat. Každá funkcionalita v softwaru ClinData je odrážena v odpovídajícím oprávnění, takže přístup ke všem funkcím je kontrolován. Každý uživatel nebo skupina uživatelů může mít přístup k přiděleným nebo omezeným oprávněním.

Role

Role jsou virtuální entity, které slouží jako kontejnery pro více oprávnění.

Existují předdefinované role a uživatelé nebo skupiny uživatelů mohou být jim přiřazeny. Nejčastěji používané role jsou:

• admin systému ClinData - plný přístup ke všem funkcím v ClinData, žádná omezení, vytváření nových projektů
• projekt admin systému ClinData - plný přístup ke všem funkcím ve vybraném projektu včetně tvorby studií
• manažer dat projektu ClinData - přístup ke všem funkcím potřebným pro vkládání nebo aktualizaci dat pacienta
• monitor dat projektu ClinData - přístup ke všem funkcím potřebným pro sledování studie, validaci a dokončení CRFs (formuláře pro sběr dat)
• prohlížeč dat projektu ClinData - pouze čtení vybraných dat

Omezení dat

Výchozí nastavení pro přístup k datům v softwaru ClinData je maximálně omezené. Uživatel vidí pouze data, která sám vložil. Výchozí nastavení neumožňuje vidět žádná data vložená jiným uživatelem. Přístup k ostatním datům musí být explicitně povolen.

Tato nastavení lze upravit:

• uživatel vidí pouze svá data
• uživatel vidí data vložená jiným uživatelem nebo skupinou uživatelů
• uživatel vidí data spojená s organizací
• uživatel vidí všechna data ve studii

Osobní údaje

Studie nebo registry mohou obsahovat osobní údaje. Přístup k těmto údajům může být omezen pomocí speciálního oprávnění.

Tato nastavení lze upravit:

• uživatel vidí osobní údaje
• uživatel nevidí osobní údaje

8. Logování

Systém ClinData zaznamenává všechny události, které se v systému odehrávají. Administrátor může tyto záznamy procházet v uživatelsky přívětivé formě a analyzovat potenciální problémy, sledovat aktivity uživatelů atd.

Existují tři různé typy mechanismů pro zaznamenávání událostí:

• Záznamy softwaru se provádějí na úrovni programovacího jazyka a jsou velmi podrobné. Soubory se záznamy obsahují údaje o vnitřním stavu celého systému v době události. Tento přístup slouží pro podrobnou analýzu problémů, které se v minulosti vyskytly.
• Záznamy přístupu jsou určeny k řízení činnosti uživatelů. Záznam o přístupu obsahuje údaje o tom, kdo provedl akci a kdy. Zaznamenává veškeré akce provedené na objektech v systému. Objektem může být studie, pacient, formulář CRF, soubor. Zaznamenávají se následující akce:
  • vytvoření
  • otevření
  • změna
  • přidání
  • odebrání
  • smazání
  • export
• Audit je zaměřený na změny provedené ve formulářích CRF. Zaznamenává kompletní historii toho, co bylo uživateli změněno. Jeden záznam obsahuje údaje o:
  • kdy byla změna provedena
  • kdo změnil data
  • co bylo změněno
  • jaká je nová hodnota

Důležitou informací je, že systém ClinData neodstraňuje žádné záznamy. Každý záznam v databázi má systémový příznak AKTIVNÍ. Smazání řádku pouze nastaví tento příznak AKTIVNÍ na hodnotu false. Neaktivní řádky se nezobrazují ve softwaru ClinData, ale stále jsou uloženy v databázi.

9. Vývoj softwaru

Sledování problémů

Jakýkoli problém nalezený ve softwaru ClinData je zdokumentován a vytvořen jako nový problém v softwaru JIRA. JIRA software je vyvíjen společností Atlassian a slouží jako nástroj pro sledování problémů. Nový problém je analyzován a je mu přiřazena priorita. Seznam problémů je řazen podle priorit a zpracováván vývojáři. Pokud je závažný problém opraven, je publikován ve nové verzi softwaru ClinData. Problém je také uzavřen jako vyřešený v JIRA.

Správa změn

Všechny požadavky na změny plánované ve softwaru ClinData jsou uloženy v JIRA. Když přichází nový požadavek, je analyzován, provedena časová odhad a přiřazena priorita. Seznam problémů je řazen podle priorit a zpracováván vývojáři.

Verzování

Zdrojový kód softwaru ClinData je uložen v repozitáři GIT, který umožňuje sledování změn v souborech. Je možné procházet historii libovolného souboru se zdrojovým kódem v repozitáři. Každá změna je také zdokumentována, aby bylo snadné pochopit vývojový cyklus.

Revize kódu

Jakákoliv změna provedená ve zdrojovém kódu softwaru ClinData musí být zkontrolována jiným vývojářem. Tento proces se nazývá revize kódu. Tento proces minimalizuje počet chyb ve zdrojovém kódu, protože vše je dvojnásobně zkontrolováno. Pro revize kódu se používá software Bitbucket (vyvinutý společností Atlassian). Tento software brání vývojářům v používání neprokázaného kódu ve veřejných verzích softwaru ClinData.

10. Zajištení kvality

Testovací prostředí

Všechny nové verze softwaru ClinData musí být otestovány a ověřeny jako funkční a správné před jejich zveřejněním. Existuje zvláštní prostředí, které se používá k testování nové verze před jejím zveřejněním. Testovací prostředí musí být podobné produkčnímu prostředí, aby se předešlo problémům s konfigurací.

Unit testování

Unit testování je metoda testování softwaru, při které jsou testovány jednotlivé části zdrojového kódu, aby se zjistilo, zda jsou vhodné k použití. Ve zdrojovém kódu softwaru ClinData existuje více než tisíc unit testů. Všechny kritické části zdrojového kódu jsou pokryty unit testem téměř na 100 %. Celkový zdrojový kód je pokryt unit testem více než 85 %. Jakýkoli problém v unit testování je blokující pro zveřejnění verze softwaru.

Testování aplikace

Celá aplikace je testována prostřednictvím průzkumného testování aplikace před jejím zveřejněním. Testování aplikace se provádí v testovacím prostředí. Jakýkoli problém při testování aplikace je blokující pro zveřejnění verze.

Zveřejnění

Proces zveřejnění znamená, že nová verze softwaru ClinData je uvolněna a zpřístupněna uživatelům. Pro sestavení a zveřejnění nových verzí se používá software Bamboo (vyvinutý společností Atlassian). Jednotkové testování je také součástí procesu zveřejnění nové verze. V případě jakéhokoli problému v jednotkovém testování je celý proces zveřejnění přerušen a zodpovědným osobám je zasláno oznámení emailemPublishing process means that a new version of the 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.