User Tools
devzone:requirements:hosting
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
devzone:requirements:hosting [2015/08/07 17:22] Roel structural edit |
devzone:requirements:hosting [2020/03/12 12:06] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Introduction | + | ====== Introduction ====== |
| At the moment the GemsTracker Development Team is searching for suitable hosting companies that are interested in gaining expertise to quickly implement new GemsTracker (GT) installations and that are able to expand the capacity of existing installations on demand. We wrote this document to help hosting companies in the setup of GT installations. | At the moment the GemsTracker Development Team is searching for suitable hosting companies that are interested in gaining expertise to quickly implement new GemsTracker (GT) installations and that are able to expand the capacity of existing installations on demand. We wrote this document to help hosting companies in the setup of GT installations. | ||
| Line 5: | Line 5: | ||
| By preparing a couple of standard virtual server images for GT installations we hope to bring down the installation and maintenance costs of each individual GT installation. | By preparing a couple of standard virtual server images for GT installations we hope to bring down the installation and maintenance costs of each individual GT installation. | ||
| - | About Gemstracker | + | ===== Gemstracker ===== |
| - | GemsTracker, the Generic Medical Survey Tracker, is an open source web server application available from www.gemstracker.org and hosted by SourceForge. On the GT site you will find more information and examples about how GT can be used in research and clinical care. Moreover, you find more user en developer documentation on our wiki (http://gemstracker.org/wiki/doku.php?id=start), which also contains a quick start for setting up GT sites. | + | GemsTracker, the Generic Medical Survey Tracker, is an open source web application available from www.gemstracker.org and GitHub. On the GT site you will find more information and examples about how GT can be used in research and clinical care. Moreover, you find more user en developer documentation on our wiki (http://gemstracker.org/wiki/doku.php?id=start), which also contains a quick start for setting up GT sites. |
| GT consists of a core library with a default installation, but is designed from the ground up to enable developers to extend the core functionality for specific projects. There are currently more than 30 different projects in production, each comprising a different website. The projects range from having only the most minimal project code of maybe 20 lines of code; up to the Pulse and ZSD projects that almost rival the GT library in their project specific code-count. | GT consists of a core library with a default installation, but is designed from the ground up to enable developers to extend the core functionality for specific projects. There are currently more than 30 different projects in production, each comprising a different website. The projects range from having only the most minimal project code of maybe 20 lines of code; up to the Pulse and ZSD projects that almost rival the GT library in their project specific code-count. | ||
| This document describes the requirements for webservers hosting one or more GT installations. It addresses security and explains the GT architecture in order to explain the different deployment scenarios. The document then gradually moves on to more detailed configuration information. | This document describes the requirements for webservers hosting one or more GT installations. It addresses security and explains the GT architecture in order to explain the different deployment scenarios. The document then gradually moves on to more detailed configuration information. | ||
| - | GemsTracker and Security | + | ===== Security ===== |
| GT is an application for collecting survey answers containing personal patient data using the web. This is privacy sensitive information and therefore security is an important consideration. In most countries one is required by law to make a serious effort using the best industry practices to keep the information inaccessible to people without a contractual obligation to respect the privacy of the patients. | GT is an application for collecting survey answers containing personal patient data using the web. This is privacy sensitive information and therefore security is an important consideration. In most countries one is required by law to make a serious effort using the best industry practices to keep the information inaccessible to people without a contractual obligation to respect the privacy of the patients. | ||
| Line 18: | Line 18: | ||
| The decision to NEN 7510 certify a particular project is up to the owners of that individual project, but in our opinion the default hosting and application environment should pose no obstacles to certification. | The decision to NEN 7510 certify a particular project is up to the owners of that individual project, but in our opinion the default hosting and application environment should pose no obstacles to certification. | ||
| - | GemsTracker Architecture | + | ===== Architecture ===== |
| GT is a library that enables health care staff to make sure the right questions about the right patients are asked at the right time. What GT does not do is asking those questions. For survey creation and entry GT uses third party products through a pluggable architecture. This gives hosting companies the freedom to also use their own (proprietary) questionnaire systems and benefit from the GT software functionality. Currently GT has plugins for the LimeSurvey and OpenRosa and at least one project has a project specific survey plugin. LimeSurvey is the most used survey plugin, but where LimeSurvey is mentioned in the rest of this document the intention is that LimeSurvey can be replaced by another survey sytem. | GT is a library that enables health care staff to make sure the right questions about the right patients are asked at the right time. What GT does not do is asking those questions. For survey creation and entry GT uses third party products through a pluggable architecture. This gives hosting companies the freedom to also use their own (proprietary) questionnaire systems and benefit from the GT software functionality. Currently GT has plugins for the LimeSurvey and OpenRosa and at least one project has a project specific survey plugin. LimeSurvey is the most used survey plugin, but where LimeSurvey is mentioned in the rest of this document the intention is that LimeSurvey can be replaced by another survey sytem. | ||
| Line 25: | Line 25: | ||
| GT installations can also create a bridge table for data warehousing containing all the answers from all the sources in a format easy to use by data mining packages. Again this table can and should be stored in a separate database in order to keep treatment data and identifying information separate. | GT installations can also create a bridge table for data warehousing containing all the answers from all the sources in a format easy to use by data mining packages. Again this table can and should be stored in a separate database in order to keep treatment data and identifying information separate. | ||
| - | GemsTracker source code | + | ===== Source code ===== |
| - | The GemsTracker open source code is stored on SourceForge using SVN. Individual projects should also use SVN for their code storage with links to tagged versions of the open source code. | + | The GemsTracker open source code is stored on GitHub. Individual projects should also use version control for their code storage with links to tagged versions of the open source code. |
| - | In a preferred deployment all source updates of the production system should be from tagged SVN versions. | + | In a preferred deployment all source updates of the production system should be from tagged versions. |
| - | GemsTracker application environments | + | |
| + | ===== Application environments ===== | ||
| Testing or developing a GT application usually requires different project settings than during production. Together these different settings form the application environment of an installation. In the Zend Framework this environment is primarily determined using an environment variable in the underlying operating system. | Testing or developing a GT application usually requires different project settings than during production. Together these different settings form the application environment of an installation. In the Zend Framework this environment is primarily determined using an environment variable in the underlying operating system. | ||
| Line 47: | Line 48: | ||
| NEN 7510 certification requires the installations containing the testing and development environments to be on different hardware than the production environment. On the other hand: there are no objections against a demo environment on the same server as the production environment. The acceptance environment can be on the same server as long as a new version is first tested on separate hardware. Of course in all cases the content of the data in the production environment must be separate from the data in any other environments, both when the data is on the same hardware and when it is on a different system. | NEN 7510 certification requires the installations containing the testing and development environments to be on different hardware than the production environment. On the other hand: there are no objections against a demo environment on the same server as the production environment. The acceptance environment can be on the same server as long as a new version is first tested on separate hardware. Of course in all cases the content of the data in the production environment must be separate from the data in any other environments, both when the data is on the same hardware and when it is on a different system. | ||
| - | GemsTracker Deployment Scenarios | + | ===== Deployment Scenarios ===== |
| A GT deployment always consists of these parts: | A GT deployment always consists of these parts: | ||
| - The code specific for the project. | - The code specific for the project. | ||
| Line 71: | Line 72: | ||
| We hope this demonstrates that GT deployment is flexible and can be adapted to different needs and to the infrastructure available. | We hope this demonstrates that GT deployment is flexible and can be adapted to different needs and to the infrastructure available. | ||
| - | Single project – small or medium | + | ===== Single project – small or medium ===== |
| For projects tracking up to a thousand patients a simple setup is usually sufficient. Of course when those patients have to answer ten surveys each day it might be insufficient, while conversely it might be sufficient for a project with ten thousand patients who have to answer a single survey each year. | For projects tracking up to a thousand patients a simple setup is usually sufficient. Of course when those patients have to answer ten surveys each day it might be insufficient, while conversely it might be sufficient for a project with ten thousand patients who have to answer a single survey each year. | ||
| Line 89: | Line 90: | ||
| - www.project.url/phpMyAdmin – IP range limited and password protected phpMyAdmin or another database administration console | - www.project.url/phpMyAdmin – IP range limited and password protected phpMyAdmin or another database administration console | ||
| - | Single project – large | + | ===== Single project – large ===== |
| For large projects with a heavy server load the first step is to separate the (virtual) database server from the (virtual) web server as the technical requirements of web and database servers are different in that a database server primarily needs a large memory and quick storage, while the primary webserver requirement is processor speed. | For large projects with a heavy server load the first step is to separate the (virtual) database server from the (virtual) web server as the technical requirements of web and database servers are different in that a database server primarily needs a large memory and quick storage, while the primary webserver requirement is processor speed. | ||
| Line 99: | Line 100: | ||
| Any further optimizations would need adjustments to the core GT code. So far this has not been necessary, but adjusting GT e.g. to employment in a webserver farm should be possible. | Any further optimizations would need adjustments to the core GT code. So far this has not been necessary, but adjusting GT e.g. to employment in a webserver farm should be possible. | ||
| - | Multi project | + | ===== Multi project ===== |
| While some GT projects are huge, most are limited in scope. What those projects need is a simple solution to be hosted, e.g. on https://www.hoster.org/project1, with an option to be able to use a project specific full url: https://project.organization.org/. | While some GT projects are huge, most are limited in scope. What those projects need is a simple solution to be hosted, e.g. on https://www.hoster.org/project1, with an option to be able to use a project specific full url: https://project.organization.org/. | ||
| Line 111: | Line 112: | ||
| A server of this type would require some extensions to the GT code, like a setup script for creating new projects and shared GT libraty files. However, the main problem to be solved would be the billing of the users as we see this as a server where people can sign up and get started without extensive consultation, but that doesn’t mean everybody can sign on for free. | A server of this type would require some extensions to the GT code, like a setup script for creating new projects and shared GT libraty files. However, the main problem to be solved would be the billing of the users as we see this as a server where people can sign up and get started without extensive consultation, but that doesn’t mean everybody can sign on for free. | ||
| - | Database security | + | ===== Database security ===== |
| While some projects install all the project data in a single database, this is not the preferred storage configuration for GT. A safe GT installation consists of two or three databases. The number of database users will be the same, but their configuration will be different as their will not be one user for each database, but rather the different users have different roles in accessing the database. | While some projects install all the project data in a single database, this is not the preferred storage configuration for GT. A safe GT installation consists of two or three databases. The number of database users will be the same, but their configuration will be different as their will not be one user for each database, but rather the different users have different roles in accessing the database. | ||
| Line 129: | Line 130: | ||
| The best practice for the GT database is to define the database server, name, user and password in the file var/settings/db.inc.php. | The best practice for the GT database is to define the database server, name, user and password in the file var/settings/db.inc.php. | ||
| - | Email transport | + | ===== Email transport ===== |
| GT applications can send out heavy mail loads and servers may not hinder these mails and should do what they can to make sure the mails are not seen as spam. | GT applications can send out heavy mail loads and servers may not hinder these mails and should do what they can to make sure the mails are not seen as spam. | ||
| Line 137: | Line 138: | ||
| In all other cases the provider should monitor mail blacklists to make certain that the GT server does not appear on them and take action when this does happen. | In all other cases the provider should monitor mail blacklists to make certain that the GT server does not appear on them and take action when this does happen. | ||
| - | Hosting GemsTracker | + | ===== Hosting GemsTracker ===== |
| - | + | GT 1.8 is written in PHP 5.6, uses a MySQL 5.1 or higher database and works on most webserver platforms including Windows/IIS, Windows/Apache, Unix/Apache and Unix/Nginx. The application is built using the Zend Framework version 1. | |
| - | GT 1.6 is written in PHP 5.3, uses a MySQL 5.1 or higher database and works on most webserver platforms including Windows/IIS, Windows/Apache, Unix/Apache and Unix/Nginx. The application is built using the Zend Framework version 1. | + | |
| Requirements and tasks for hosting companies: | Requirements and tasks for hosting companies: | ||
| Line 165: | Line 165: | ||
| Lastly we would prefer companies able to provide consultancies services to parties starting with a GT project, either directly or through third parties. A separate document for consultancies is in the make. | Lastly we would prefer companies able to provide consultancies services to parties starting with a GT project, either directly or through third parties. A separate document for consultancies is in the make. | ||
| - | Technical requirements for hosting GemsTracker | + | ===== Technical requirements for hosting GemsTracker ===== |
| There are no hardware requirements; or rather there is a strong preference to using virtual servers so that we can quickly adjust the hardware to the requirements of a specific project. So we specify only the software requirements for hosting GT, both minimal and preferred. | There are no hardware requirements; or rather there is a strong preference to using virtual servers so that we can quickly adjust the hardware to the requirements of a specific project. So we specify only the software requirements for hosting GT, both minimal and preferred. | ||
| Line 202: | Line 201: | ||
| SVN Preferred Preffered | SVN Preferred Preffered | ||
| - | Directory structure | + | ===== Directory structure ===== |
| The GT code is by default installed in multiple sub directories, only one of which is accessible from the web. The other code, library and storage directories should be stored in a location accessible by the web server, but not from the web. | The GT code is by default installed in multiple sub directories, only one of which is accessible from the web. The other code, library and storage directories should be stored in a location accessible by the web server, but not from the web. | ||
| Line 229: | Line 228: | ||
| - | Scheduled jobs | + | ===== Scheduled jobs ===== |
| GT projects use cron or Windows Schedule for automated tasks. | GT projects use cron or Windows Schedule for automated tasks. | ||
devzone/requirements/hosting.1438960976.txt.gz · Last modified: 2020/03/12 12:08 (external edit)
