Welcome to the GNU Health Developer's corner

This chapter focus on the development of the upcoming version in different components of GNU Health

The developer's corner is highly volatile. It's chaotic and unstable, and we love it like that ;)

Please respect the target build of each component.

Migration to GNU Health 5.0 - Tryton 7.0

This section will cover the process to migrate the HIS server from 4.4 to 5.0

Initialization

Download the latest LTS (Long term support) Tryton server (https://www.tryton.org/download) and uncompress it.

-> $ tar -xzvf trytond-last.tar.gz

Create a dedicated DB for the migration ("migration50")
backup your current trytond and create a symlink to the new Tryton server (adapt the directories to your needs)

-> $ ln -si /home/healthdev/workplace/tryton-server/trytond-7.0.17 /home/healthdev/gnuhealth/tryton/server

logout and login to the new environment and initialize the new database
Download the tryton packages required by the GH HIS core module

- company
- currency
- party
- product
- country

$ ./trytond-admin --all --database=migration5 -vv

-> (enter the email and password for the server admin)

Launch the Tryton 7.0 client
Load all the additional modules shown (company, currency, party, product, country)
Open a terminal and run the scripts to import:

 - currencies
 - countries
 They can be found in the currency and country "scripts" directory
 
 $ python3 ./import_countries.py --database=migration5
 $ python3 ./import_currencies.py --database=migration5

Actions in the Kernel and Data dictionary upgrade

Actions to Migrate Tryton 6.2 to 6.4 do not apply because we don't use Account payment package ( https://discuss.tryton.org/t/migration-from-6-2-to-6-4/5241)
Actions to Migrate Tryton 6.6 to 6.8 do not apply because we don't use packaging_* modules

Remove "select" option from Fields instances.

Todos:

- merge orthanc & dhis2 module

- migrate modules to Tryton 7.0 & pyproject.toml, start with core module

- resolve tryton module tests

- upload (test)pypi & run tryton module tests using CI?

- confirm new installation

- update other installation related stuff

- set up community server with alpha testpypi version

Uwsgi config

The following templates are samples used for GH HMIS (on Tryton) and for Thalamus

HMIS server sample ini file (gh.ini)

[uwsgi]
master = true
processes = 3
socket          = /tmp/uwsgi.sock
http-socket=0.0.0.0:8020
chmod-socket=666
daemonize = /home/gnuhealth/logs/gnuhealth-hmis.log
module=trytond.application:app

You can invoke it by

$ uwsgi -c /home/gnuhealth/gh.ini --enable-threads

Thalamus sample ini file

[uwsgi]
master = 1
https = 0.0.0.0:8443,/opt/gnuhealth/certs/gnuhealthfed.crt,/opt/gnuhealth/certs/gnuhealthfed.key 
chdir = /home/gnuhealth/.local/lib/python3.9/site-packages/thalamus/
wsgi-file = thalamus.py 
callable = app 
processes = 4 
threads = 2 
socket = /tmp/thalamus.sock
daemonize = /home/gnuhealth/logs/thalamus.log

Hospital Management Information System

Target build : 4.0

openSUSE Leap <=15.3 and other OS using Python 3.6 It's highly recommended to use Python versions >=3.7

If your distribution uses Python 3.6, then you must enforce the following dependencies versions:

apiron==5.1.0
beren==0.7.0

Wishlist

New GNU Health WebGUI which supports all GNU Health features and works as well on Tablet and Smartphone. It should have a new UX Design and clearly not replicate the GTK design
Redesign GTK Client - Etienne mentioned some improvements
Interface to AI providers like Planet-AI
Integration of the Tryton pos module with the pharmacy module
Integration with DHIS2

Upgrade

BEFORE THE UPGRADE:

Execute the script "before.sql"
update tryton server (./trytond-admin --all)

AFTER THE UPGRADE:

Execute the script "after.sql"
The Calendar and Webdav menus might shown twice. Just deactivate the obsolete first instance (Administration -> User Interface -> Menu)

GTK Client

The GNU Health GTK client beta is at testpypi

You can download it using the following command:

python3 -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ gnuhealth-client==4.0b1

Plugins

The search path for plugins goes like this:

1. <config dir>/plugins

Example: /home/lfm/.config/gnuhealth/3.5/plugins

2. <current_gnuhealth_dir>/tryton/plugins

Example: /home/lfm/health/gnuhealth-client/tryton/plugins

3. $HOME/gnuhealth_plugins

Example: /home/lfm/gnuhealth_plugins

The third one ($HOME/gnuhealth_plugins) is the recommended place for most users. It makes easy automation and allows convenient drag and drop for plugins.

The first option is recommended for users that have different GH GTK client versions installed.

Web Client

The webclient is based on the Tryton SAO Webclient. It does not have the current functionality, desktop integration and security features as the GTK client. For developers only...

INSTALLING SAO (as gnuhealth user)

download https://downloads.tryton.org/6.0/tryton-sao-last.tgz
cd $HOME
mkdir sao
cd sao/package
npm install
cd /home/gnuhealth/sao/package/node_modules/.bin
./grunt

On the [web] section :

root = /home/gnuhealth/sao/package

Interfaces

GNU Health Federation

Thalamus

GH Federation Portal

MyGNUHealth mobile application

Installation of MyGNUHealth PinePhone and Manjaro Plasma Mobile

Install requirements

Update de system (pacman -Syu)
Install gcc (pacman -S gcc)
Install base devel tools (pacman -S base-devel)
Install pyside2 package (pacman -S pyside2-es2) (Make sure you use this package! The regular "pyside2" won't work. Thanks Anupam!)

Installation on PinePhone and KDE Neon

Install in a SD card the plasma-mobile latest image (https://images.plasma-mobile.org/pinephone/)

Install required packages

apt-get install python3-pip
apt-get install qt5-qmake
apt-get install cmake
apt-get install qtbase5-dev
apt-get install clang clang libclang-6.0-dev
apt-get install qtbase5-private-dev
apt-get install qtdeclarative5-dev qtdeclarative5-private-dev

Create a swapfile (it will be needed during the building process)

sudo bash
cd /opt
dd if=/dev/zero of=swapfile bs=1G count=1
mkswap swapfile
swapon swapfile

(you can later add it to the fstab if you want to have it permanent) add to /etc/fstab
/opt/swapfile swap swap defaults 0 0

Download,extract and build PySide2 https://doc.qt.io/qtforpython/gettingstarted-linux.html#getting-pyside2

Fix the following symlinks that are broken:

$ cd pyside2/pyside-setup/pyside3_install/py3.6-qt5.14.2-64bit-release/bin$

$ ln -si /usr/bin/qtchooser ./designer
$ ln -si /usr/bin/qtchooser ./rcc
$ ln -si /usr/bin/qtchooser ./uic

Installation on the Desktop

Nightly Builds to install MyGNHealth on a GNU/Linux Desktop are available at OpenBuildService

Orthanc integration

Notes obtained from C:

PACS / DICOM goals

For providers:

Consistent access to imaging studies in multiple views / tabs
- Including accurate imaging information including type of imaging (CT, MRI, ultrasound, etc), date/time, location, and final report (essential if available)
- Quickly copy/paste images and reports (eg, into notes)
Easy imaging viewing through a robust PACS viewer
Upload new (or newly obtained) imaging studies to local PACS server from outside sources
- Patients frequently bring imaging discs with previous studies which should be stored for better continuity of care and medical decision-making. Furthermore, outside images should be able to be stored for quicker access and local evaluation.
Send imaging studies to other locations and / or patients
- CD / DVD saving / “burning” (likely location specific)
- Send to outside medical office / provider via network (or CD/DVD)
- This assists in transfers of care and patient access to medical records.
Notify provider on new imaging results (configurable as appropriate)

For developers (see implementing the above goals with some notable details below)

Synchronization of relevant data in fault-tolerant and error-free way
- Reliability and accuracy are much more important than speed
- Support Orthanc and other servers (as possible)
Providers should interface with data in intuitive manner with appropriate data viewers
- Zero config for the providers
- Imaging studies → PACS viewer
- Final reports / etc→ PACS viewer or PDF / text viewer (if not built-in to PACS viewer)
Bidirectional interactions with PACS server
- PACS authentication should be seamless for the multiple types of users (providers, admin, etc)
- Connecting remote studies to local patients
- Uploading imaging studies (as above) should be attached to local patient
- Expose multiple PACS endpoints / tasks to administrators
Other:
- Appropriate access restrictions for data and tasks
- Continuous access to data for providers (no downtime for updates or similar)
- Minimize bandwidth used (via avoiding unnecessary transfers) given resource restricted environments
- Network interactions should be encrypted via TLS or other similarly appropriate mechanism

Ideas from G, rather details than general concept:

Target error codes, until here only 401, "Invalid Domain" or "Success"
When creating a patient in HMIS from patient in Orthanc: Adopt/suggest name, dob & ID automatically
Support DICOM preview inside client (Orthanc: Only link to open in browser yet, health_imaging: DICOM not supported)
Add series & instances as ressources? Orthanc module supports only patients & studies, but Orthanc itself has patients, studies, series & instances as ressources

Open task/bug:

“When requesting a DX image, have the possibility to send this to Orthanc “
“When creating the DX imaging result, have the possibility to link the images/studies to data coming from orthanc”

Bug #59872

Issues

The following are issues that need to be fixed:

FIXED: ~~DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory at startup~~. Using CMA=340m as a kernel boot param gives enough CMA memory. Colleagues at the KDE plasma channel said they would include it in next image.