Domain Modeling Technical Deep Dive

Post-meeting, in early April 2016, some additional domain model whiteboarding was done.

Requisitions

Fulfilling

Receiving Shipping

To us, "Receiving" doesn't make sense as its own context. Either it is the tail end of the "Fulfilling" context, or else it should be thought of as a broader "Shipping" context.

Inventory Management

API:

• Get all balances at one facility (by batch?)

• Record and process a Stock Event

  • issue, receipt, adjustment (delta or absolute), transfer?

• Get stock card + line details (for one product at one warehouse)

• (something like) Tell me what happened to the stock that I sent out to facilities last period

• What items are included in this kit?

• What products are substitutable for this product?

Different types of facilities?

• National-level Central Receiving

  • typically receives international shipments

  • may even include tracking shipment through customs

    • This is in VIMS

    • Most important for vaccines (e.g. need to track VVM while going through customs)

    • Don't know if this is in scope for OpenLMIS Product

  • maybe >1 per country

  • tracking inventory at this level is probably not a short-term priority

    • but necessary if we want to support forecasting

    • maybe necessary for vaccine workflow too

• National/Provincial/State Storage

  • Usually 1 (per country/province/state)

  • Distribute to lower levels (e.g. district)

  • For most countries, batches are tracked at this level

  • Big warehouse with multiple rooms, shelves, maybe multiple cold rooms, etc

  • Sometimes this level will already have its own electronic inventory system

  • Sometimes they will want to use OpenLMIS for inventory management at this level

    • But OpenLMIS doesn't want to track warehouse management (e.g. which room, which shelf)

• "District" Storage

  • sitting in a major city somewhere

  • probably doesn't have a cold room, but has multiple fridges

  • need to provide to different programs

  • Distribute to SDPs

  • Maybe keeps extra stock on hand to cover shortages in facilities that depend on it

  • Maybe acts as a care-providing facility itself

  • Unlikely to have own electronic inventory system level already 

  • Probably want to use OpenLMIS for inventory management at this level

• SDP (Service Delivery Point)

  • Smaller

    • just a single room +/- a fridge

    • Unlikely to have internet, regular electricity

    • Unlikely to accurately track batch numbers

    • It's important to know what was sent to this level (including batches), but at the programmatic level you may not care what happens after that

      • vaccine program people care more

      • higher levels wants to avoid stock-outs at SDPs, so they may care about total stock quantities, overall consumption, upcoming expiration, etc.

  • Larger

    • hospital with multiple wards, multiple stock points within the hospital

• Mobile outreach program

  • Usually goes out from a facility

• Individual health worker

  • (out of scope to track at this level?)
    
    

(Darius's opinion) In the long run, OpenLMIS will need to tie together different facilities some using third-party inventory management systems, and having different levels of required accuracy and precision; our challenge is not to write code to cover every possible case, but to allow the variations to communicate the necessary information within the OpenLMIS workflows.

The real purpose of OpenLMIS is the workflow and process of the demand and supply cycle; inventory management is supportive of this, but is not the end goal of OpenLMIS. (Jake: actually this is more true today, but it won't always be true.)

Interfaces Between Bounded Contexts

Requisition Service