Content Packages are for you if:
You’re looking for ready-made content, like templates & forms for a specific specialty 🔎
You don’t want to start from scratch 😅
You want to share your clinical content work 🤝
Table of Contents
Key Links
Content Package template repo: openmrs-content-template
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 outcomes.
Key Components of a Content Package:
Concepts: These are standardized clinical terms and definitions sourced from 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 and reporting.
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.
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.
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.
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.
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 |
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! |
How to use a Content Package
A content package can be added to a new OpenMRS distribution or to an existing OpenMRS 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
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
etcRequirements 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.
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).
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.
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.
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.
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.
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:
Fill in the details of the plan:
Configure repositories:
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.
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.