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