Skip to content

Customizing Ozone HIS

After you have generated your own distribution of Ozone HIS with the Ozone Maven Archetype, the next step is to explore the possibilities for customizing your distribution to meet your specific needs and specifications.

There are four main areas of customization and configuration available to you to do so:

Configurability in Ozone HIS

  1. Customizing the default distribution behavior.
  2. Enabling & disabling HIS components.
  3. Configuring HIS components.
  4. Configuring the EIP layer.

Ozone HIS is a Maven Distribution

It is an essential prerequisite to understand that your distribution of Ozone HIS is managed as a Maven project.

Every standard Ozone HIS distribution is generated with the Ozone Maven Archetype as a child of the Ozone Maven Parent. The default behavior of such a distribution is a combination of

  • What is inherited from the parent.
  • What is auto-generated within the archetype.

What constitutes your software distribution of Ozone HIS is stated and defined in the main Maven POM file of your distribution, the one that has been was generated by the archetype.

Did you know?

Your distribution POM file is a manifest that states all that makes your Ozone HIS distribution.

Customizing the Maven Distribution

Practically every element of the POM file can be modified to achieve the changes you wish to make to your Ozone HIS distribution. We will not attempt to define an exhaustive list of all possible customizations, as virtually anything can be achieved with Maven. Instead, we will use this space to build an inventory of useful examples of such customizations that have occured through real-world use cases.

Adding further software dependencies

Adding custom OpenMRS backend modules

The KenyaHMIS Ozone distribution required additional OpenMRS backend modules (JAR files) beyond those provided by default in OpenMRS. This can be achieved by adding Maven dependencies in the main POM file of the Ozone HIS distribution.

See here how this can be done.

Overriding the version of default software dependencies

Using another version of the OpenMRS Initializer module

The KenyaHMIS Ozone distribution needed to temporarily depend on a bleeding-edge version of the Initializer module rather than the released version packaged with OpenMRS by default. This can be achieved in two steps:

  1. Excluding the packaged Initializer JAR file, see here .
  2. Re-adding a dependency on the desired version of Initializer, see here .

Excluding default configuration files

Ignoring default OpenMRS backend configuration files

The KenyaHMIS Ozone distribution did not require several OpenMRS backend configuration files that come by default with OpenMRS. Since these configuration files are already packaged through the OpenMRS dependency, one way to handle this is to exclude the unwanted configuration files from the package.

See here how this can be done.