@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.