GNU Health/Developer's corner

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.

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:

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

AFTER THE UPGRADE:

1. Execute the script "after.sql"
2. 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

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)

1. sudo bash
2. cd /opt
3. dd if=/dev/zero of=swapfile bs=1G count=1
4. mkswap swapfile
5. 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.