# 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

Please go to the GNU Health development at Codeberg: https://codeberg.org/gnuhealth/his/wiki/GNU-Health-HIS-developer%27s-corner
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
* $ ./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:

### 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)
You can invoke it by
$ uwsgi -c /home/gnuhealth/gh.ini --enable-threads
Thalamus sample ini file

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