Versions Compared

Key

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

Table of Contents

...

  • String lotCode (required—if the shipment really does not have a code, and only has an expiration date, then users could paste that date into this code field)
  • Date expirationDate (optional)
  • Date manufactureDate (optional)
  • reference to a TradeItem (required) — this object gives us access to the Manufacturer name, etc, which will be helpful for display. (in V2 this was a reference to a product)
  • boolean active flag — potentially a future feature to be able to set a Lot as inactive after it has gone out of circulation; or maybe this is connected to how you archive the lot instead of a DELETE endpoint
  • UUID will get assigned to the Lot in ReferenceData, but it won't be visible to the user

...

Let us take Drug A as an example. There are at least two lots belong to Drug A existing in Facility HC, their lot number are lot2 and lot3 and their SOH are 20 and 80 respectively60 respectively. There is also 20 that were donated and do not have a blessed lot number. However, the storeroom can not record 20 and 80 60 separately because the system does not have lot information yet. In order to track Drug A, the storeroom manager creates a stock card for Drug itself and the SOH is the summary of lot2, lot3 and lot3the donation

Later, the MOH decides to track stock at the lot level and system admin adds three lots (lot1, lot2, lot3) for Drug A. After sync with the server, store room manager in facility HC is able to choose three lots under Drug A for HIV program for creating stock events. 

If so,  how will the system deal with the stock card of Drug A?

Open Question : Is it reasonable to assume that when the MOH decides to track lots that they load up lots that have already been distributed? Do we have any information on how an implementer would want to start rolling out lot management? Review the following three solutions and let us know which you have questions on, If using lots, would we want to enforce that all items with lots MUST fall within the approved lots?

Product Committee please review the following three solutions and let us know which you have questions on, which you prefer and why.

...

Before creating stock cards for lot2 and lot3, store room manager must balance the Drug A’s SOH correctly to lot2 and lot3 SOH summary. In this case, the system will provide a UI for storeroom manager to input the initial SOH of lot2 (20) and lot3 (8060) and that initial SOH summary must equal with Drug A current SOH (10080). This validation is mandatory and storeroom manager is not allowed to create new stock events until he records all the lot information and pass the validation check. After he passes the validation check, then the system will deactivate the stock card of Drug A and storeroom manager will not record stock event for Drug A’s stock card.  Open Question : what if there is stock on hand which doesn't have an approved lotThis would not allow an allocation of the 20 that was donated since it would not have an approved lot amount. The user would need to make an adjustment to remove the 20 from the SOH.

Open Question : Would it be acceptable to only track the movements of products within the approved lots and not support items coming in from unapproved ways or purchases?


The SOH summary page will change to:

...

Product codeProductLot numberExpiry DateSOH Action
A001Drug A

10080


Lot212/201920View


Lot303/20208060View
A002Drug B

200View
A003Drug C

300View

...

There is no balance validation check between Drug A SOH and its lot SOH summary but when a lot stock card is created under an existing Drug then the existing stock card of that Drug become invisible for end user. In this case, storeroom manager can choose lo2 lot2 or lot3 to create stock event and the initial SOH quantity can be any positive integer and there is no validation check whether the SOH summary of lot2 and lot3 matches Drug A SOH (100). However, after the stock card of lot2 or lot3 is created then Drug A’ s stock card become invisible for storeroom manager and its SOH remains 100 until later custom implementation solution. A SOH (100). However, after the stock card of lot2 or lot3 is created then Drug A’ s stock card become invisible for storeroom manager and its SOH remains 100 until a decision is made on how to deal with those stock amounts. A user would not need to make an adjustment to remove the 20 since it would be ignored

Open Question : Would it be acceptable to only track the movements of products within the approved lots and not support items coming in from unapproved ways or purchases?

The SOH summary page will change to:

...

There is no mandatory balance validation check between Drug A SOH and its lot SOH summary. Storeroom manager can create stock event on either Drug’s original stock card or the lot’s stock card but the original stock card is independent from lots’ stock card. In the case, there will be three stock cards for Drug A in the system: Drug A' No Lot defined' stock card, Lot2 stock card, Lot3 stock card. Essentially we do not assume the stock on hand belongs to Lot2 and Lot3. IF it does, then the end user must make adjustments to the DrugA No Lot defined SOH to bring it down reduces to the appropriate level.

Open Question : this puts a lot of responsibility on the storeroom managers. They would be responsible for 'balancing' out the stock. Would it be okay if stock is tracked without lots and lots?

The SOH summary changes to:

...

Product codeProductLot numberExpiry DateSOH Action
A001Drug A

200100


No lot defined
10020View


Lot212/201920View


Lot303/20208060View
A002Drug B

200View
A003Drug C

300View


Which solution do you think is best and why?



...


Archived NOTES

Technical Option1: technical preferred - mixed policy and usability

...