Mapping Products from PCMT to Programs and FTAP in OpenLMIS?

Hi @ibewes, @Sebastian_Brudzinski, and @Klaudia_Palkowska,

With the pull of a product list from PCMT->OpenLMIS making technical progress I wanted to re-surface what I’ve assumed is the proper partitioning of concerns: the mapping of a Product pulled from a product list into an OpenLMIS.

We’ve structured that in an ideal world a country runs PCMT as a National Product Catalog (NPC), and their OpenLMIS as their national public health LMIS, and therefore the proper positioning of product data would be:

  • The NPC would be the authoritative source of product and item data.
  • The LMIS would be the authoritative source of how that product data was used transactionally.

It doesn’t have to be so cut-and-dried, you could stick everything (but the actual transactions of course) in the NPC. However doing so could make it awkward for OpenLMIS:

  • Mapping a Product to a Program - in OpenLMIS this is where we define things like if it’s a full-supply product, the display order on the LMIS form, etc.
  • Mapping a Product to a Facility Type Approved Product (FTAP) - in OpenLMIS this is a bespoke concept, and it’s where OpenLMIS defines things such as the min and max supply levels as well as a reference price.

My preference is to leave Programs and FTAP’s in OpenLMIS - that keeps the definition of those things close to those operating the LMIS. That would mean that OpenLMIS would ideally have someway for the administrator to find new Products and ensure that their mapping to Programs and FTAPs was done (and correct).

Does this make sense to you?


Hi @joshzamor

If I understand correctly: the administrator will have to associate new products with preconfigured programs and FTAPs.

We think that this approach would be OK, but we’ll have to figure out how to highlight new products for the administrator.

We will skip mapping programs and FTAPs. If the product already exists in the LMIS and has its program, we will fetch the associated program and add it to the mapped object before updating.


I agree with the suggestion from Josh. In addition, the comment from Wojciech highlights an important point: if OpenLMIS is “subscribed” to a PCMT feed of catalog updates, the administrators inside OpenLMIS will still need to see what the
changes are and make updates inside OpenLMIS configuration to respond.

A few examples:

  • As an OpenLMIS administrator, when a new product is added into a PCMT catalog, I want to see those additions and configure them in OpenLMIS programs (for example, I will decide whether to associate the new product(s) to a Program, FTAP,
    and add them onto my Requisition form(s) as a full-supply or optional product, and add any other fields of data needed in OpenLMIS such as optional fields or ExtraData fields about the product);

  • As an OpenLMIS administrator, when a product is removed/deactivated in the PCMT catalog, I want to see those removals and disable/remove the product(s) from the Requisition form.

  • As an OpenLMIS administrator, when a product is modified in the PCMT catalog, then I want to see the changes and approve or reject before they will take effect in my requisition forms. (This is a tricky, more advanced workflow. We need
    to consider what MVP features we will support for allowing OpenLMIS administrators to see if there were changes/modifications in the PCMT catalog that took effect in their OpenLMIS requisition forms.
    Josh, how is that aspect addressed?)