What is a Content Package?

A content package is a comprehensive set of metadata and configurations specifically designed to help healthcare systems manage program-related data and care more effectively. It includes key elements such as concepts, forms, encounter types, workflows, and reports all curated to meet the unique needs of healthcare programs. For instance, the HIV Care and Treatment content package enables streamlined management of HIV patients by facilitating efficient data capture and reporting, ultimately improving health outcomesAn OpenMRS distribution consists of both code, i.e., the OpenMRS platform and modules, all of this code uses various metadata to help it. Metadata in OpenMRS covers a range of things, from the concept dictionary to form schemas to encounter types, visit types, reports, programs, etc. This metadata is important to how the code actually works.

The idea of content packages is to provide a mechanism for sharing metadata between different instances of OpenMRS, whether this be as a way of packaging up the shared configurations for a distribution or to share content between different distributions. For example, a content package might define a set of forms that helps capture disease-specific data, such as for HIV or COVID-19. In addition to containing these forms, the content package might also include the necessary concepts to use the forms and configurations to help display these forms in relevant places in the EMR.

Key Components of a Content Package

HIV Care & Treatment Package

The HIV Content Package is designed to streamline and support the management of HIV care. It achieves this by providing a comprehensive set of clinical forms, encounter types, workflows, and metadata that support the structured capture, tracking, and analysis of patient information.

UCSF

USA CDC

More coming soon!

1. Concepts: These are standardized clinical terms and definitions sourced from resources like the Columbia International eHealth Laboratory (CIEL) Dictionary. Concepts ensure consistency in how clinical information is captured and interpreted across the system, forming the foundational building blocks for patient care, decision support and reporting.

2. Forms: Content package forms are designed to collect essential patient information during clinical visits, supporting accurate data entry for patient management and clinical care. These forms are customized to capture data relevant to the specific health program.

3. Encounter Types: These represent different clinical interactions between a patient and a healthcare provider, each tied to a specific service. Encounter types categorize and track patient interactions, allowing for clear documentation of the services provided during each visit.

4. Workflows: Workflows define the sequence of steps that patients follow as they move through the healthcare system. They ensure that patients receive the appropriate care promptly, guiding the healthcare process from registration through treatment and follow-up.

5. Reports: Reports are designed to provide insights into program performance, patient outcomes, and data trends. They help healthcare providers and administrators make informed decisions by offering a comprehensive view of the program's effectiveness.

6. Configuration: Configuration settings define how the content package integrates with the healthcare system, including how data is stored, processed, and displayed. These settings ensure that the content package is customized to meet the specific needs of the healthcare program.

Available Content Packages

Package Name

Contents Description

Contributing Orgs

PMTCT Package

Underway by UCSF

UCSF

USA CDC

COVID Package

Underway by UCSF

UCSF

USA CDC

Cervical Cancer Screening Package

Underway by UCSF

UCSF

USA CDC

1. Additional Metadata: In addition to the key components outlined here, content packages may contain other metadata necessary to utilize the content. Generally, these metadata will be provided in a format that is consumable by the Initializer module, which covers a wide array of OpenMRS metadata.

How to use a Content Package

A content package Content packages can be added to a new OpenMRS distribution distributions or to an existing OpenMRS distributions. The process to do so varies depending on how your distribution

When initiating a new OpenMRS distribution.

A content package is typically added as a dependency to an OpenMRS distribution. A sample reference application distribution can be located here

To add a content package, add a dependency to the distro pom.xml

<dependencies>
    ...
    <dependency>
      <groupId>org.openmrs.content</groupId>
      <artifactId>hiv</artifactId>
      <version>1.1.0-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
    ...
  </dependencies>

Add an entry for the content package to distro.properties

content?.hiv=1.1.0-SNAPSHOT=1.1.0-SNAPSHOT

Ensure the openmrs-sdk-maven-plugin is configured in the build element

<build>
  <plugins>
    ...
    <plugin>
        <groupId>org.openmrs.maven.plugins</groupId>
        <artifactId>openmrs-sdk-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>openmrs-sdk:build-distro</id>
            <goals>
              <goal>build-distro</goal>
            </goals>
            <phase>package</phase>
            <configuration>
              <distro>${project.build.directory}/distro.properties</distro>
              <dir>${project.build.directory}/sdk-distro</dir>
            </configuration>
          </execution>
        </executions>
      </plugin>
    ...
  </plugins>
</build>

Clean and package the distribution

mvn clean package 

This command cleans and builds the distribution which can be deployed as docker images using docker compose or to an sdk server or manually to a configured instance. The package command has actions that, amongst others, pulls and extracts the content package, pulls dependent modules and other dependencies, validates configurations and builds the distribution.

When adding to an existing distribution.

How to create a new Content Package

Creating a new content package such as an HIV Content Package involves several steps

1. Purpose and Scope Definition: Begin by articulating the primary goal of the content package and identify the key components of this package. The scope of the HIV content package for example may cover HIV Testing, Care and Treatment, MNCH, Community Engagement etc. Scoping also required that you determine the specific population that the package will serve such as Adults living with HIV, Pregnant Women and Children, Key populations at risk for HIV etc

2. Requirements Gathering: Gather inputs from a diverse group of stakeholders, including healthcare providers, data managers, etc to ensure that the content package is comprehensive and meets the needs of all parties. Also, determine the concepts and data elements that will be needed for the content package.

3. Identification and Selection of Concepts: Creating a new content package such as an HIV Content Package, requires careful identification and selection of concepts to ensure it accurately reflects the necessary data elements for effective patient care and management. Concepts serve as the building blocks of the content package, providing standardized definitions for various clinical terms and data elements.

   • At the heart of metadata is the concept dictionary, which includes clinical terms (e.g., diagnoses, drug regimens, lab results) and how they relate to each other.

   • Concepts are selected from existing dictionaries (e.g., Columbia International eHealth Laboratory (CIEL)) and custom concepts are created as needed.

   • Begin by navigating the Columbia International eHealth Laboratory (CIEL) database, which houses a comprehensive library of healthcare concepts relevant to various medical fields, including HIV care. Search for relevant HIV-related concepts (e.g., diagnoses, treatment regimens, laboratory results).

Image Removed

4. Compile a list of concepts: Develop a comprehensive inventory of selected concepts and collaborate with healthcare providers and clinical experts during the selection process to gather insights on the most relevant concepts. Ensure that you reach a reach consensus among stakeholders on the final set of concepts to be included in the Content Package.

5. Identify gaps in concept: If you discover that certain concepts essential for the content package are missing in CIEL dictionary, it’s important to seek solution to address this gap.

   • Document the Gaps: Create a document that outlines the missing concepts.

   • Consult with the CIEL Team: Consider contacting the CIEL team for assistance on how to incorporate or develop these concepts.

   • Engage Clinical Experts: Work together with clinical experts to define and create new custom concepts that address the identified gaps.

6. Export or Integrate Concepts into the Instance: Exportation of the selected concepts involves transferring the curated concepts into the instance’s concept database. This ensures that all the selected concepts are readily available for use in the system. Consequently, the concepts are accessible for form building, data entry, reporting, and patient management.

Image Removed

7. Creation of Forms and Templates: Forms serve as the primary interface for healthcare workers to collect patient data in a structured way. Creation of forms therefore is a crucial step in developing a new content package. The process involves designing and structuring forms that align with the concepts identified for the package. Forms need to be developed in a way that they directly relate to the concepts integrated into the instance. Each field in the form should correspond to a concept (e.g., diagnosis, treatment regimen) in the concept dictionary.

   • With the O3 Form Builder feature in OpenMRS 3.x form creation has been simplified. The O3 Form Builder provides a drag-and-drop interface for creating forms, making it easier for non-technical users to configure forms. Users can add fields such as text inputs, checkboxes, radio buttons, and dropdowns, and map them to the added CIEL concepts.

Image Removed

Image Removed

Technical Step: Create a Content Package module

The command is in non-interactive mode and it initializes a basic OpenMRS content package project with specified details like module ID, name, version, and description, using the OpenMRS SDK Maven plugin.

mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:5.16.0-SNAPSHOT:create-project -Dtype=content-package -DmoduleId=hiv -DmoduleName=Hiv -DgroupId=org.openmrs.content -Dversion=1.0.0-SNAPSHOT -DmoduleDescription="this is a basic content package template project"

How to publish a Content Package

OpenMRS modules are typically published by a continuous integration plan configured in the OpenMRS Bamboo continuous integration server.

At present, there is a project that has been configured as a parent for all content package plans. We envision having multiple content package plans for various content packages (HIV, MH, MCH, NCD etc.)

To configure, create a plan under the project - Content:

Image Removed

Fill in the details of the plan:

Image Removed

Configure repositories:

Image Removed

Add a maven 3.x build configuration task: - This task runs maven (configured in Executable) commands (configured in Goal) that cleans the project, builds it, validates the configuration, creates the archive and deploys it to OpenMRS maven repository, or otherwise, as configured in the distributionManagement element in the project's base pom.xml file.

Image Removed

The configuration for publishing a content package project is complete and any commit to the branch configured in the Configure repositories section will trigger this action which will run the task configured above. is constructed, but below we show how to use the community-supported tooling to add content packages.

Content packages are distributed as zip files stored in Maven repositories. This means that content packages can be easily added to distributions built or managed by the OpenMRS SDK simply by modifying the distribution definition, just like adding a new module to a distribution. Simply modify the distribution’s distro.properties file to include any content packages. Content packages are identified by having the prefix content. For example, you might use an HIV package by adding this line to your distro.properties file:

content.hiv=1.0.0-SNAPSHOT

When you rebuild your distribution in the normal way, the content will now be available.

Backend and Frontend Modules

Content packages may depend on the presence of certain frontend apps or OMODs to fully utilize the content in a content package. If your distribution does not include and required dependencies, the SDK will out put an error message telling you which app or OMOD you need to add an which version. These can be added to your distribution either via editing your distro.properties file or by running the SDK’s add command, which will prompt you for the type name and version of the dependency to add.

Frontend Configurations

Content packages may provide frontend configurations in order to setup certain views in the app. These will be added to your distribution’s frontend directory via the SDK. However, in order to enable them, you will need to add them to the distribution’s configuration URLs. To do this, either add or modify the line for the spa.configUrls to include them. For example, to use the clinical-visits settings from the HIV content package, your spa.configUrls line should look like:

spa.configUrls=/openmrs/spa/hiv/clinical-visits.json

You can also add multiple configurations like this:

spa.configUrls=/openmrs/spa/hiv/clinical-visits.json,/openmrs/spa/hiv/general-counselling.json

Current Content Packages