Your view: O3 Packages / Content Templates / ...

[mksd (Dimitri R)]

Dear all – let’s speak about O3 packages

The concept of O3 care or functional packages has been touched upon in our discussions before, perhaps a bit prematurely in regards to what our tech stack was allowing then. However, I believe now is a good time to revisit this conversation with fresh perspectives and more defined needs.

I’d like to use this thread to dive deeper into what we all envision when discussing “O3 packages”, “content packages” or “content templates”. These terms seem to resonate with many within our community, and it’s crucial we unpack what they mean to each of us.

---

As an example I’ll try to give a summary of what this would mean for an OpenMRS service provider like @Mekom. I would hope to hear the same from you all.

At Mekom, we assemble distributions for the projects we support, focusing on sustainable maintenance of these systems. Our goal is to avoid forking any software. Instead, we rely on officially released components to create our software suites. This approach ensures that the responsibility for the release lifecycle of these components does not fall on us, allowing us to concentrate on integration and support (rather than mitigating the negative impact of tech debt).

In OpenMRS, traditionally, this involved creating so-called (Maven) distros that depended on released OMODs. With the introduction of O3, the approach has evolved to assembling distros that incorporate both released ESMs and released OMODs. These O3 distros consist of:

• OMODs
  • and a backend config
• ESMs
  • and a frontend config

It’s important to note that the backend configuration also includes forms and concepts, so the medical questionnaires and their associated clinical terminology.

This approach is fine, but quite granular in the way we pick and choose what goes into a distro. There may be an opportunity to bundle these elements more effectively to maximize impact and improve maintainability. Now that we have fully embraced configuration over customization (the latter essentially equates to forking) perhaps can we focus on creating impactful binaries & configuration bundles.? These could then be shared across different groups and countries.

Sample use-case: If we look at our work in Cambodia within the NCD space, it would have been beneficial to segregate all NCD-specific elements into a comprehensive package for the Cambodia distribution to depend on it. Such segregation not only clarifies the distribution from an implementer’s perspective when examining the distro manifest (the POM file), but it also allows for the NCD package to be decoupled from the Cambodia national distro. This decoupling could facilitate its reuse in other regions, enhancing overall utility and impact.

---

Having said all this as a way of an introduction into the subject, what’s your view on what those bundles could be, and how would you make use of them?

Cc @AMPATH @Brown @METS @Mekom @OpenMRSInc @PalladiumKenya @PIH @Sonder @UCSF @UWash

[michaelbontyes]

Hi @mksd - Thank you for bringing up this topic.

This is certainly of interest to @MSF as well, considering our aim to maximize modularity and reusability.

We began by packaging content with program-specific collections in OCL for programs like NCD, trauma, and Mental Health. Authored by multiple MSF teams, these collections are made to be reusable across projects. To improve adaptability, the concepts are generally mapped to standards such as SNOMED and ICD, thanks to all the efforts from @akanter and CIEL.

Having more or less sorted out the management of medical content, our next challenge is now around configuration definition, build, and execution across implementations and levels of configuration.

As an example of vertical configuration, an NCD program could include specific binaries and configs for Concepts, Forms, Lab Tests, Diagnosis, Drugs, Patient Queues, Appointment Types, Clinical Views, and predefined Provider Roles and Privileges. Beyond the EMR level, it could also include program-specific ETL configurations and other integrations.

To address this, we have begun testing a hierarchy and inheritance of configurations based on the Ozone approach, with the help of @mksrom. So far, we have this work-in-progress repository where we define configurations at 3 levels:

1. Organizational/Distro level (e.g., MSF)
2. Country level (e.g., Iraq, Yemen, DRC, etc.)
3. Facility level (e.g., Mosul, Ataq, Goma, etc.)

Currently, the lower levels inherit from the parent ones to facilitate reusability.

To build on your point, could we imagine combining both that hierarchical/inheriting approach with program-specific packages? For instance, if there is an organizational or national program in NCD, we could integrate an NCD package at the org or country level in the POM, then add facility-specific specifications in the site-specific POM files.

Considering the shared interest among multiple implementers and the goal to expand use cases for OpenMRS, would it also be beneficial to establish a central location or a set of repositories for these package examples early on? Similar to how feature squads operate, this could allow groups to publish reusable package examples that can be adapted to different contexts through configurations.

For MSF, the first priority is the Mental Health program, focusing initially on concepts and forms, and I’m eager to keep exploring and testing a packaging approach with it. Then for visibility, the next most likely programs will be Nutrition and IPD Maternity.

[eudson (Eudson Bambo)]

@mksd great to see this work started.

For @UCSF // TAP, this has consistently been a priority as part of our commitment to provide “generic” programmatic packages (e.g., HIV C&T, HIV HTS, COVID) to PEPFAR-supported countries and the broader community. Our efforts began with the @OHRI project, aiming to create foundational programmatic packages upon which countries can build. The goal was always to deliver these packages as described by both you and @michaelbontyes, with a stable O3 being a prerequisite. Now that O3 is stable, our focus can shift to content packages.

To streamline clinician workflow and access to necessary forms, we have implemented form-based packages. Each programmatic area is equipped with clinical views, providing forms through sub-menus and tabs. Some packages feature patient-centric summary pages displaying crucial patient information relevant to the specific program area, as well as summary pages illustrating the program holistically.

Program summary page (HIV)

Patient centric summary page (PMTCT)

As previously stated, our primary use-cases, in order of priority, are HIV C&T, HIV HTS, PMTCT, and TB. All developed frontend packages (ESMs) can be accessed here. These frontend packages only contain the clinical views (hardcoded) with some dynamism provided by reusable components that can be found in our commons lib. All the configurations follow the distro approach and concepts are similarly managed thru OCL (@wamz feel free to add more here).

Although these packages are somehow decoupled to each other we still don’t have a clear approach on how to package the backend dependencies (mainly metadata). @michaelbontyes I like your comment about ETL configuration, I think that is something we have not yet thought about but its very important because for PMTCT for our Namibia implementation that is somehow hardcoded and we can leverage MambaETL for this.

Another aspect that needs to be taken in account for our use-cases / packages is that they are powered by reusable components (ReactComponents) and the development time fairly reduced it still requires a developer to build them. I think it’s time for us to replace developers , am joking here. We can never be replaced

Similarly to the form-engine we need to start thinking on a declarative way of building these program workflows (clinical views, forms, dashboards, etc). My proposal would be a json-schema powered program workflow / package builder, something like.

hiv-ct-ui-workflow: {
    clinical-view : {
        title: "HIV Care and Treatment",
        sub-menus: [{
            title: "HIV Patient Summary",
            component: xxx
        },{
            title: "Program Management",
            tabs: [
                {
                    title: "HIV Enrolment", 
                    tableDefinition: {
                        columns: [{name: "Enrolment Date", concept: "16XXXX"}, ...],
                        actions: ["edit", "view", "delete"]
                    }, 
                    actions: ["add"]
                },
                {title: "ART Therapy", ...},
            ]
        }]
    }
    dashboard-view: {
        title: "HIV Care and Treatment",
        pages : [{title: "Care and treatment", tiles:[...], tabs:[...]}]
    }
}

With this approach we wouldn’t need this ESMs since most of the heavy lifting would be done by the openmrs-program-builder-engine (look at me giving names) and the RefApp could have this json’s available on marketplace of sorts that implementers can then download an include into their distros or it could be part of parent-distro and via configuration one can enable or not a particular workflow. This would mean less tech debt. We at @UCSF are currently exploring this avenue, happy to hear what others think.

Hope this makes sense.

[mksrom (Romain Buisson)]

After discussions with community members, here is the proposed approach for enabling content extensibility in OpenMRS via “Content Packages”:

• Repository Structure: Each package will have its own GitHub repository, facilitating contributions, as different groups will likely drive specific content packages based on their expertise.
• Maven Projects: Packages will be Maven projects, published as zip files on a Maven repository (the OpenMRS one at first)
• Package Contents: The structure of each package will include:
  • A configuration/ folder containing any OpenMRS backend configurations.
  • A content.properties file detailing the package components, primarily specific ESMs and OMODs.
• SDK: Add or remove artifacts to distributions: The OpenMRS SDK will be improved to enable adding/removing content packages, OMODs, ESMs to an OpenMRS instance, whether new or existing with a distro.properties file.
• SDK: Validate distributions: The SDK will support running the Validator to ensure the newly added content packages does not disrupt the distribution. Key enhancements:
  • Capability to run against a distro.properties-driven distribution.
  • Ability to start the distribution based on a specified SQL dump.
  • Continuation beyond the first validation issue.
  • Clearer and more concise error reports.
• Comprehensive Documentation: Detailed documentation will be created to cover:
  • Usage of existing content packages:
    • When initiating a new OpenMRS distribution.
    • When adding to an existing distribution.
  • Guidelines for contributing to content packages.

Hopefully this work plan will put OpenMRS in position where content packages can be advertised and widely adopted across the community.