This page provides a high level design of the OpenLMIS and OpenSRP integration for the minimum viable product integration for stock management (Phase 1).
...
Feature Auth-1: OpenSRP Server or the Mobile Backend will need to be able to authenticate with OpenLMIS
Is there a specific user that we will authenticate as to get an OAuth grant?
Reference Data Alignment
OpenSRP and OpenLMIS need to align metadata in order to function. Core alignment will happen at the server side with the that pushed down to the mobile client. OpenSRP has an internal mechanism for dynamically defining views without having to update the application (originally developed for the TB Reach application). We intend to use this feature to inform a number of touch points in the mobile client. OpenLMIS is the clear source of truth truth.
Facility Information
OpenSRP server has a representation of a facility within the health system. A facility is a physical location. OpenSRP inherits the facility list from OpenMRS, which is able to pull the facility lists from DHIS2 using the DHIS2 location sync module.
...
Feature Facility-3: OpenSRP will need to regularly poll the OpenLMIS and OpenMRS servers for changes to the facility list and notify an administrator
Alternatively, something that is neither OpenSRP nor OpenLMIS can be responsible for syncing data. Can we make explicit that realt-time sync is not in scope if we are using a polling strategy
Changes to the facility lists in either system will require an intervention by the system administrator to ensure mapping is appropriately flowed. Changes can happen in OpenLMIS and in OpenMRS and we need a standard mechanism to notify a human in the event that there are changes in either system. This should be raised as a database flag, email or ticket in the operational support systemflag, email or ticket in the operational support system.
Is this any change? If we have an ID to ID mapping, I'd assume changing the facility name in either system wouldn't require human intervention. I'm not entirely clear on why we would need human intervention, if there's a way to avoid, or what would need to be changed in the future to avoid it.
Orderables/Immunizations
The core integration focuses on immunization workflows. The LMIS domain includes a concept of orderables, which are medical commodities. The OpenSRP stock management system doesn't include a concept of orderables. Instead, stock is managed by the immunization type and the system assumes the health care worker is able to link the immunization type against the orderable product. This integration will maintain the current health-specific workflows and add a new section that allows for the management of a specific set of orderables in the OpenSRP app. BIT CONFUSED WHAT YOU MEAN BY NEW SECTION. PLEASE ELABORATE A BIT MORE
...
We need to develop a data model and REST API to store orderables in OpenSRP to be able to track the orderable products on the server side. This will allow us to populate the fields in the android client, map orderables to immunizations and interact with the OpenLMIS server. Note: We only need to store a subset of orderables in the OpenSRP server, not the entire OpenLMIS orderable list.
These This data model needs to be based off of the following data models in OpenLMIS:
...
We must store the following program information in OpenSRP Server:
- program_name
- program_code
Both of the above are needed when sending information to the OpenLMIS API?
We need to store Program specific Stock Adjustment Reasons (Named Stock Card Line Item Reasons). This allows us to track the adjustment reasons that need to be collected in the client.
...
- Information from OpenLMIS to be sent to OpenSRP
- Orderables - This will be dynamically populated from OpenLMIS, but only a subset of Orderables will be populated.
- Facilities - This will be populated by OpenLMIS
- Program - This will be populated by OpenLMIS, but will include a maximum of 1 program for this phase. The program information is required for exchanging information between systems.
- Program Adjustment Reasons - This will be populated by OpenLMIS and will drive elements in the Android client single select menu and UI. Specifically, is this a drop-down menu in OpenSRP that's generate from data pulled from the OpenLMIS API?
- Information in OpenSRP to be sent to OpenLMIS (See Discussion Point Below)
- Report Stock levels per Orderable
- Report wastage levels per Orderable
Discussion: What is the actual OpenLMIS API destination of the information from OpenSRPis the actual OpenLMIS API destination of the information from OpenSRP?
When we talk about exchanged, is this exchanged once then never again, will it check and update on a schedule, will it check and update with human intervention?
WE NEED TO DISCUSS HOW THESE STATIC JSON FILES WILL BE GENERATED. THESE CAN BE DONE VIA OPENSRP OR POTENTIALLY VIA A NIFI PROCESS (PETER LET'S DISCUSS IF THIS IS VIABLE)
...
This section includes the functional requirements and views to be developed in the OpenSRP Stock Management Module. The current stock management views focus on presenting a simplified "stock card" system, where the high level landing page lists the stock cards available and subsequent screens focus on tracking the stock related transactions for that stockType. The core development in the Android client focuses on building dynamic views of stock card items based on the information in OpenLMIS. The first major features will focus on augmenting the current stock management features available in the OpenSRP Android client with dynamic views and updated business logic to support the concept of orderables. The second major feature will focus on creating a dispensary focused "bulk update" view that allows for issuing, adjusting and receiving multiple orderables in a single transaction.
| Info | ||
|---|---|---|
| ||
The views in this section are for illustrative purposes and are not final. This information box will be removed when they are finalized. |
...
- Does OpenLMIS provide any business logic as a service that can be consumed at the "orderable level"?
- Can we scope a specific sample set of vaccines that we will target in the MVP?
- Which business logic is OpenLMIS specific and which is OpenSRP specific (orderable vs. consumption)?
I'm wary of dynamic business logic, would this look like a set of algerbraic functions that all must be satisfied?
Bulk Orderable Update
The current stock control view focuses on single stock card transactions one orderable at a time. We will add a new area to the Android client that allows dispensary technicians to make changes to multiple orderables. This user interface is targeted at store managers who need to issue, adjust or receive multiple orderables in a single transaction. Examples include issuing multiple orderables to a single third party, stock take adjustments, large wastage adjustments and receive a shipment.
...
The SOW includes an activity to track the status of cold chain equipment at the facility. These workflows need to be defined jointly. The feature could be as simple as an SMS interaction from OpenLMIS directly to the health worker, a Boolean toggle on in the OpenSRP Android client, or more complex to keep track of Cold Chain Equipment serial numbers.
Could also view functionality over time in the Android, probably not needed, but I'd assume time series functionality will be important in the reporting.
Advanced Stock Notification / Proof of Delivery
The Advanced Stock Notification (ASN) and Proof of Delivery (POD) are currently being specified by OpenLMIS. These workflows will need to be jointly defined by the OpenLMIS and OpenSRP teams. In theory, OpenSRP server could receive a JSON payload from the OpenLMIS server, push that down to the Android client, and prep the proof of delivery for easy validation in the UI. The teams need to specify the workflows and features independent of the activities that have been specified in this document.
Which may include extensions so that OpenLMIS can push data to external servers
Mobile Role Based Access Controls
...