DSU Fabric Dynamic Expiration Date Management

[maherpa2]

workspace/files/6175296/Dynamic.Expiration.Date.Process.v0.1.pdf) PL user story: #93 (see full overview for additional information)

Description: Update to the DSU Fabric in order to implement Dynamic Expiration Date Management

• 

• The flow diagram can be found here: Dynamic Expiration Date Process v0.1.pdf

• This will require an update to the Batch Management screen in order to have the ability to include an updated Expiry date. The Batch Screen must show the Original Expiry Date and also the Updated Expiry Date. If the updated Expiry date is not used for the batch then it should be blank.

Acceptance criteria's: positive tests

• create a batch (serialized or non-serialized) does not matter.

Follow the flow diagram created to test the different scenarios

• Don't update the Expiry Date

• Extend the Expiry Date

• Reduce the Expiry Date

• The messages to be displayed will need to be agreed with different stakeholders but the important thing is that the different scenarios can be detected and work as outlined in the flow diagram.

negative tests / error path testing N/A

Process scenario: when new products are released they may have say only a 6months expiration date. However as more stability data is gathered then the expiration date may be extended. So the barcode, say Datamatrix (but could be any barcode which has the expiration date) would have the the expiration date encoded. When this is scanned then the system need to check if it matches the original expiration date (if this check is enabled) and then also check if the expiration date has been updated. Most typically the expiration would be extended but the solution needs to consider a reduction in the expiration date in case needed.

Additional information: N/A @steinso2 @nhrishi @rite2bala @UnHynek please review

[nhrishi]

@maherpa2 Thanks for the detailed flow. When we say the original expiry date, it means the original expiry date (set when batch was created) correct? Since the expiry date can be updated multiple times, we should always call the latest updated expiry date as "updated expiry date" and ignore earlier dates except the original expiry date.

Just curious, don't we recall the products in case of expiry date change.

[maherpa2]

@nhrishi the original expiry date is the date that was used when the batch was created and this would be the date that was in the Datamatrix code. The original expiry date does not change and is needed for the Incorrect Expiry Date check. What we need is an additional field ("Updated Expiry Date") where the modified Expiry Date can be entered. This will then be used to determine if the product has expired or not.

[thursbyk]

@maherpa2, this looks good to me.
@nhrishi, in today's world, if a product is expired, it is typically destroyed or returned to the Pharma Company if there is a "sale or return" clause. This wastes product and can create product shortages to patients. Dynamic product expiration is being manually managed for COVID vaccines, where short shelf life is an issue because its a new product with not enough data to support long shelf life. It is more common with new products.

[thursbyk]

@maherpa2, suggest that we manage Dynamic Expiration at Batch Level... so any change happens to any unit within the batch. For COVID, I could see T&T benefits at case level when managing changes between cold storage levels, but propose we don't tackle it at this depth for now because we only need to demonstrate that it can be done.

[maherpa2]

@thursbyk it could only be managed at the batch level.

[rite2bala]

Partially implemented.

[rite2bala]

@nhrishi, @salboaie This story seems to have missed out on the feature pipeline.

Could you please comment if there is any further information required to make this story ready for development ?

From a business context : When a medicine pack is released into the market and later when the expiry date is changed in the Enterprise Wallet -- the expiry date would not match with the one previously printed on the pack. This will lead to an expiry date mismatch error. In order to resolve this - whenever expiry date is changed -- store the new expiry date in the "updated expiry date" field and this would then follow the flowchart above.