Open Hospital builds its all-in-one EHR packages from a Makefile

This repository assembles packages, it does not contain the medical logic

The distinction is stated in the repository description and repeated in the README: this repository is used to build the releases of Open Hospital, and it is used to assemble the portable or all-in-one packages. The application itself lives elsewhere, split across separate repositories. OH CORE is a library holding the business logic and the data abstraction layer. OH GUI is the desktop graphical interface, made with Java Swing. OH DOC holds the user and admin documentation in Asciidoc format. OH API is a web server exposing REST APIs over the Core component, marked as work in progress, and OH UI is a React single page application web interface, also marked as work in progress. The primary language recorded for this repository is Makefile, which is the giveaway. What lives here is the glue that fetches, compiles and lays out those components into something a hospital can install, not the code that stores a patient record.

make is the entire user interface of the build

The README documents a short build path for anyone assembling the packages. On a Linux machine you need JDK 8+, Maven, asciidoctor-pdf, zip and GNU make installed. Then you clone the repository and run make. The build script comments describe the same contract, and the Makefile header offers two useful switches: a -j flag to parallelise some of the tasks, and make help to list the available targets, plus intermediate targets for building a single part of the distribution.

        git clone https://github.com/informatici/openhospital
        cd openhospital
        make

Those three lines are the documented path from a fresh machine to a distribution directory. The parallel form is written in the README as make -j4, and the same paragraph points you at make help for the target list. Nothing else is required at the shell, which is unusual for a project of this size and is a direct consequence of pushing all of the logic into the Makefile.

OH_VERSION has to be exported, or the build is labelled develop

The version handling in the Makefile has a subtlety that will cost you an afternoon if you skip it. The file assigns OH_VERSION twice. The first assignment takes the value from the environment if it is set, otherwise it shells out to git describe --abbrev=0 --tags to find the most recent tag. The second assignment then applies the same conditional again, falling back to develop. Since the first line already replaced an unset OH_VERSION with the last tag string, the second line sees a non empty value and keeps it, so a plain make in a clean checkout does produce a tag derived build. But the comment block above it states the intended usage plainly: to build a specific version you set OH_VERSION as an environment variable before running make, and to build the development version you run make clean, export OH_VERSION=develop and make. The release notes template and the UPDATING file at the top level suggest the packaging metadata is assembled from those values, so an unset variable produces a package labelled develop that you cannot ship.

Package names encode target platform and deployment mode

The output names are defined as Make variables and follow a strict pattern. The client mode package is OpenHospital-$(OH_VERSION)-multiarch-client. The portable builds are OpenHospital-$(OH_VERSION)-windows_i686-portable, OpenHospital-$(OH_VERSION)-windows_x86_64-portable, OpenHospital-$(OH_VERSION)-linux_i686-portable and OpenHospital-$(OH_VERSION)-linux_x86_64-portable. There is also OpenHospital-$(OH_VERSION)-x86_64-EXPERIMENTAL for a full distribution, and the word EXPERIMENTAL in the name is a signal from the maintainers that the all-in-one build is not the same risk level as the others. The mode distinction itself is described in the README: Open Hospital runs as a desktop application in a standalone single user mode called PORTABLE mode, or in a client server configuration called CLIENT mode where multiple clients and users connect to the same database server. Since the README notes that the software is designed to work without an internet connection and requires low resources, the portable package is the one aimed at a clinic with poor connectivity.

The build downloads its own JRE and database from Azul and MariaDB

The Makefile pins two external download endpoints. JAVA_URL points at https://cdn.azul.com/zulu/bin, which is the Azul Zulu OpenJDK distribution, and MYSQL_URL points at https://archive.mariadb.org. That second choice matters for an offline deployment story: the build pulls a database server alongside the application so the resulting package does not depend on the operator having MySQL or MariaDB installed already. The README also lists a zip requirement, which pairs with the portable Windows targets, and asciidoctor-pdf for rendering the Asciidoc documentation into the manuals the users actually read. Because the packages are meant to run without an internet connection, bundling these runtime pieces is not a convenience, it is the design. The flip side is that your build machine needs outbound network access to both hosts, and a hospital network that blocks them will not be able to produce a package locally.

Bash strict mode and delete on error shape the recipe behaviour

The Makefile configures its own shell rather than inheriting a default. SHELL is set to /bin/bash, .SHELLFLAGS to -eu -o pipefail -c, .ONESHELL is enabled so that a single recipe runs in one bash session instead of one shell per line, and .DELETE_ON_ERROR removes the target file when its recipe fails. That last one has a concrete effect on the workflow: a partially written distribution file is removed rather than left on disk looking valid, so a failed build leaves fewer misleading artefacts behind. The -u and pipefail flags mean an unset variable or a failing command inside a pipeline stops the recipe rather than passing silently. For a project whose output is a bundle handed to clinicians, that is a sensible choice, and it also explains why the build stops hard rather than limping on with a missing component. The root directory of the repository holds oh-bundle/ and oh-extra/ directories alongside the Makefile, which is where the assembled output and any additional files are staged.

An alternative is assembling the components yourself from their own repositories

The realistic alternative to this packaging repository is not a competing EHR but a different assembly strategy. You can clone openhospital-core, openhospital-gui and openhospital-doc separately, build each with Maven, and deploy the desktop application against a database you manage yourself, which is what the client server mode implies. The difference in approach is that this repository gives you a reproducible, one command artefact per platform with a bundled runtime, while the manual route gives you control over the Java and database versions and the freedom to integrate with existing infrastructure. The trade runs in both directions. Building by hand means you own the compatibility matrix between the JRE, the MariaDB build and the Swing client, and you have to produce installers and manuals yourself. Using the packages means you accept the Zulu and MariaDB versions the Makefile chooses and you wait for a tagged release, since the releases here are v1.15.0 on 2026-02-03, v1.15.1 on 2026-09-01 and v1.15.2 on 2026-10-12, and the last push was on 2026-10-14. For a clinic that needs a working system rather than a controlled platform, the packaged route is the shorter path.

Editorial conclusion

Adopt this repository when you want to produce an Open Hospital distribution you can hand to a site without an internet connection, and when you can supply a Linux machine with JDK 8+, Maven, asciidoctor-pdf, zip and GNU make. It is the wrong place to start if you want to develop the medical record logic, since the business code lives in the separate openhospital-core repository. Verify first by running make help to see the targets, then export OH_VERSION before a plain make, because the version variable is derived from git describe when it is left unset and you may not want the package labelled that way, and confirm that the JRE and MariaDB download URLs the Makefile fetches are reachable from your build network.

Frequently asked questions

Official sources

1. informatici/openhospital on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases