Warning | ||
---|---|---|
| ||
Under discussion and not final. The following will evolve with discussion and collaboration. |
...
Mobile Proof of Concept Demo (February March Delivery)
A proof of concept demo will be developed in February as a preview of the full integration. This proof of concept demo will be lightweight with the following features:
- Minimum Functional Workflows:
This section defines the minimum functional workflows for the proof of concept demo. Stretch activities are clearly marked with (Stretch)- (Optional) OpenSRP Android Client Demo prep to show current functionality
- The OpenSRP user will login to the stock management module to see the current number of vials available for the antigen
- The OpenSRP user will perform a number of sample immunizations in the OpenSRP child immunization app for a single antigen (OPV)
- The OpenSRP user will return to the Stock management module, click the card for the antigen and touch the Issued button to show a reduction in the stock
- OpenSRP Android Client Requesting Stock
- The OpenSRP user is already at the Stock Management Module screen
- The user will touch a button to request stock based on Ideal Stock Amounts
- A message will appear verifying that the user is requesting stock "Please confirm that you would like to request stock based on your Ideal Stock Amounts"
- The device syncs with OpenSRP Server
- Nifi queries the OpenSRP Server endpoint every 'n' seconds and identifies that a new stock request has been received
- Nifi performs internal business logic to map the stock request to the facility, user and ideal stock amount (ISA)
- Nifi pushes an order to the OpenLMIS Orders API endpoint in the Fulfillment Microservice. An Order number is returned to Nifi.
- OpenLMIS user logs in to verify the order was created
- OpenLMIS Demo to convert Order to Shipment
- OpenLMIS user walks through the order fulfillment process
- A shipment is created
- OpenSRP Android Client Receiving Shipment
- Nifi queries the OpenLMIS Shipments API in the Fulfillment Service to see if a new shipment has been generated
- (Note: Should this be the API endpoint, or should we query the Proof of Delivery Endpoint?)
- When a new Shipment is identified, Nifi queries the Shipment/{id} API endpoint in the Fulfillment service to get the shipment details
- Nifi performs business logic on the Shipment details to convert it to the appropriate JSON format required by OpenSRP
- Nifi posts the JSON to the OpenSRP Server
- OpenSRP Server receives the shipment information
- On a regular schedule, OpenSRP Android Client Syncs with the OpenSRP Server
- A new shipment is received
- A notification is generated in the Stock Management Module's Shipment section (new section)
- OpenSRP user touches the shipments section in the stock management module and they are redirected to a page showing that a shipment is available
- OpenSRP user touches the shipment and they view details of the shipment
- User can accept shipment
- (Stretch) User can adjust the amounts of each orderable and touch save
- On Save action, the antigen amounts update on the tablet
- OpenSRP Android client will sync with OpenSRP server
- (Stretch) Nifi Queries OpenSRP Server on a regular schedule for Proof of Delivery
- (Stretch) Nifi performs the appropriate business logic to accept the proof of delivery and creates the appropriate JSON to post to OpenLMIS
- (Stretch) Nifi posts the Proof of Delivery to the OpenLMIS Proof of Delivery API endpoint in the Fulfillment Service.
- Nifi queries the OpenLMIS Shipments API in the Fulfillment Service to see if a new shipment has been generated
- (Optional) OpenSRP Android Client Demo prep to show current functionality
- Terminology (verbs):
We need to identify a common terminology for the end user who is stationed at the facility level to ensure they have a common experience across OpenSRP and OpenLMIS.- Receipts - When an end user receives stock from any source
- Current OpenSRP Language is "Received" in the UI
- Current OpenLMIS Language?
- Proof of Delivery is the order plus the shipment and it's signed off on (CRAIG: See Fulfillment Process and Statuses Wiki Page)
- Issues or Transfers - When a Stock is dispensed from an entity to another
- Current OpenSRP language is "Issued" in the UI representing an issue from the facility to a nurse or lower level
- OpenLMIS uses:
- "Shipment" to represent the issuing of stock from a higher level entity to the end facility
- "Issue" This removes something from my stock, but doesn't actually move anywhere in the supply chain. Most often used at the lowest level of the supply chain (the facility level)
- (What gets reported up the chain?)
- "Transfer" to represent the issuing of stock from two entities at the same level (facility to facility)
- A transfer may be an activity that shows poor planning where one facility has too much stock and another has too little
- Request Stock - When an entity wishes to request stock from a higher level entity in the OpenLMIS supply chain
- OpenSRP does not currently have language
- OpenLMIS uses the following depending on the configuration for that facility
- "Requisition"
- "Order"
- (Do end users need to know the difference?)
- Discard - When a user wishes to throw away an orderable for a number of reasons that will be implementation specific.
- Current OpenSRP language is "Loss/Wastage"
- Current OpenLMIS language is "Adjustment" - There's always a reason
- OpenLMIS adjusts primarily on physical stock counts, not day-to-day operations
- Reporting is key here
- Receipts - When an end user receives stock from any source
- How do we differentiate between the activities at the facility that have no effect up the chain and those that do.
- CHAI came up with an idea of "Ad hoc issues and receive" (See this on the wiki)
Mobile Phase 1 (March demo, April delivery)
...