Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties
label


Status

Status
colourYellowGreen
titleIn ProgressComplete

Stakeholders
Outcome

(Work in progress)

  • Do not do ReactNative in OpenSRP. It's too risky and doesn't have a clear valueDo not do the API gateway approach. That has long term technical debt that we don't want to take on.'t have a clear value
  • Do not do the API gateway approach. That has long term technical debt that we don't want to take on.

Decision and Path Forward:

  • Develop in OpenSRP
    • Reduce scope of Lots and Batches
    • Potentially add scope from our next priorities (such as receiving a shipment; interoperability with mCSD/FHIR standards; single sign-on with OAuth2; or demonstrating how multiple apps interoperate smoothly)
    • If there is re-usable code in the SIGLUS Maven .jar library, consider using/reusing that
  • Focus on standards for:
    • Auth - User Accounts
    • Representation of Locations
  • Prioritize the immunization nurse use case (and later the SIGLUS-v3 upgrade will need to focus on the pharmacy/storeroom/dispensary use cases, and we will need to demonstrate how different solutions work at different levels of the supply chain; some levels might use OpenSRP where higher-volume levels might use SIGLUS)

Next Steps:

  • Craig will write a SRS and we will reconvene to ensure the scope is appropriate and achievable
Due date
Owner


...

ItemOpenSRP OrderablesUpgrade SIGLUS
Stock On Hand Interface (Stock Cards in OpenSRP)Requires redesign of the interface to accept dynamic list of orderablesDoes not require major redesign
Stock Card Interface DesignAlready AvailableRecommending usability redesign
Stock Card Immutable LedgerAlready AvailableAlready Available
Stock Event Business LogicAlready AvailableNeeds to be modified 
Stock Management Business LogicNeeds to be rewritten for Orderables data modelNeeds to be rewritten for orderables data model
Orderable Data ModelNeeds to be created from scratchNeeds to be created from scratch
Mobile to server authenticationAlready availableNeeds to be rewritten to accept V3 oauth2 process
Mobile to server syncingAlready availableNeeds to be added to OpenLMIS as a microservice
OpenSRP to OpenLMIS server syncingNeeds to be created from scratch in NifiN/A
Bulk inventory business logicNeeds to be created from scratchAlready Available, needs to be modified for orderables data model
Bulk inventory user interfaceNeeds to be created from scratchAlready Available
Intents and activities to link OpenSRP app to SIGLUSN/ANeeds to be created from scratch
Ability to add trade items in Android appitems in Android app
(The plan is to have this ability in OpenLMIS in the future)
Will not develop. All trade items will be defined server side and synced to the app.Current feature of SIGLUS. We could block this activity if we state that it's out of scope.
Ability to add lots in Android app
(The plan is to have this ability in OpenLMIS in the future)
Will not develop. All lots will be defined server side and synced to the app.Current feature of SIGLUS. We could block this activity if we state that it's out of scope

Ability to add commodityTypes in Android app
(The plan is to have this ability in OpenLMIS in the future)

Will not develop.Will not develop.

Major areas of risk for the Ona teamUpgrade SIGLUS:

  • Generally, there's a schedule and cost risk of having to develop OpenLMIS microservices for this project:
    • Authentication upgrade to work with OpenLMIS v3 may require Auth microservice development
    • We will need to create a microservice from scratch to manage the mobile deployment syncing, which is a huge undertaking
  • Schedule Risks:
    • Ramping up on SIGLUS to be proficient in development will take 2-3 weeks for the full time Android developers who are already proficient with OpenSRP, Nifi and the OpenLMIS APIs