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

**URL:** <https://talk.openmrs.org/t/your-view-o3-packages-content-templates/42516>\
**Category:** O3\
**Tags:** configuration, package\
**Created:** [April 21, 2024, 11:46am UTC](https://talk.openmrs.org/t/your-view-o3-packages-content-templates/42516 "2024-04-21T11:46:00Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![eudson](https://talk.openmrs.org/user_avatar/talk.openmrs.org/eudson/32/16527_2.png) [@eudson](https://talk.openmrs.org/u/eudson)\
**Post date:** [May 2, 2024, 7:31pm UTC](https://talk.openmrs.org/t/your-view-o3-packages-content-templates/42516/3 "2024-05-02T19:31:32Z")

</div>

@mksd great to see this work started.

For [@UCSF](https://talk.openmrs.org/groups/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](https://talk.openmrs.org/groups/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)**

 ![image](https://talk.openmrs.org/uploads/default/original/3X/c/e/ce44c198fe7505f5da250343ba392eb2604d0814.png)

**Patient centric summary page (PMTCT)**

 ![image](https://talk.openmrs.org/uploads/default/original/3X/3/6/36dc2f1c340ae56e71c2f99f1df8eaf128a9ce14.png)

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](https://github.com/UCSF-IGHS/openmrs-esm-ohri/tree/master/packages). These frontend packages only contain the clinical views (hardcoded) with some dynamism provided by reusable components that can be found in our [commons lib](https://github.com/UCSF-IGHS/openmrs-esm-ohri/tree/master/packages/esm-commons-lib). All the configurations follow the [distro](https://github.com/UCSF-IGHS/openmrs-distro-referenceapplication/tree/dev/distro) approach and concepts are similarly managed thru [OCL](https://app.openconceptlab.org/#/orgs/OHRITechGroup/) (@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](https://talk.openmrs.org/t/mambaetl-v1-0-0-released/41205) 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.

```auto
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](https://talk.openmrs.org/groups/ucsf) are currently exploring this avenue, happy to hear what others think.

Hope this makes sense.

---

_[View the full topic](https://talk.openmrs.org/t/your-view-o3-packages-content-templates/42516)._