2.9. Generic database installation

This section is distribution/OS independant.

2.9.1. GnuMed database 101

GnuMed does not simply store all of it's data in a monolithic database. It rather uses the concept of a service. A service is a set of tables relating to a semantically reasonably distinct part of the data. It's probably easiest to understand via the example of the "blobs" service. This service stores medical documents relating to patients. These can be scans of referral letters or discharge summaries, paper-based lab results or incoming faxes. Any aggregate of diverse medical data on a patient that's not easily split up and stored.

Other services include "default" (the core database tables that tell your client software which service is to be found where), "personalia" (holding all the patient demographics), and various clinical services for drug data, clinical history, etc. The authoritative list of services is found in server/sql/gmconfiguration.sql. Any service living in the same database as the "default" service does not need to be mapped explicitely (but it can). If there's no mapping it is assumed that a service lives in the "default" service's database.

Services can coexist in one and the same database on a single server or be spread out across several databases or even servers both on-site and off-site. However, non-monolithic services have not been tested well yet and will require the non-standard dblink PostgreSQL extension (found in contrib/ in the PostgreSQL source tree). Until further notice it is recommended to stick to non-distribution of services via monolithic databases except for services that don't require cross-database referential integrity links such as a drug database for informational purposes. What has been tested successfully, however, is access to GnuMed databases over WAN links, including via internet from arbitrary locations.

2.9.2. Database setup

The theory roughly goes like this:

All of this is handled automatically by the script bootstrap_gm_db_system.py living in server/utils/. This script does not yet set up mappings of services to their databases/servers (although in theory it can install services on remote servers already). As this is not yet fully supported by GnuMed anyways (due to dblink being non-standard) one should stick to a monolithic service layout. Several sample config files for bootstrapping are supplied in server/utils/.

Before running the bootstrap script make sure you've installed the symbolic links to modules and sql. You can do this by typing
sh make-links.sh
		

Now use a sample config file by calling the script like this:
         bootstrap_gm_db_system.py --conf-file=<a config file>
		

You should see some line like
Done bootstrapping: We probably succeeded.	
		
at the end of the output if everything went right.

Make sure you check the following section in your config file points to the pgsql libraries.
language library dirs = $language library dirs$
/usr/lib/postgresql/                                                            
/usr/lib/postgresql/lib/                                                        
/usr/lib/pgsql/                                                                 
/usr/local/pgsql/lib                                                            
$language library dirs$ 
		
Many known locations are already listed so you might not have to change anything.

To set up a straightforward monolithic system on the local machine use the config file localhost-monolithic.conf.sample.

Make sure to remove test accounts and to set up your own config file if you want to go life.

If you want to tweak things by hand read the config files and the source of the bootstrapping scripts. All the config file parameters are documented in bootstrap_gm_db_system.conf.sample.