Item variants need to work for both stock management and GAPS

[adamdewey]

What went wrong? 😲

Open mSupply needs to be able to handle item variants holistically so that the system can be used for both stock management and GAPS at the same time.

It currently doesn't do that.

There are currently major issues in terms of data being set at the wrong level or illogical duplication / messiness, depending on how you attempt to define item variants.

Starting point:

This is a sample list of a generic item and its variants from the WHO database.

You can see several things here:

• The item variants can have the same commercial name
• The unit is set at the item variant level, not the item level
• The number of doses is set at the item variant level, not the item level

Trying to wrangle the system to make it work

Attempting to use system with item as the generic item

If we create a single generic item for the sample vaccine (Rotavirus) above then we end up with a hard to use system for stock management.

1. The item variant is not very visible and it's hard to know what you're dealing with during stock processes
2. Additionally the unit, strength and other properties are incorrectly set at the generic item level rather than the item variant level
3. It's not possible to enter variants with the same commerical name
4. There are # of doses set on the generic item and the item variant and they can differ

Attempting to use system with item as the item variant

Another approach was to enter every item variant as an item, but this results in having to add variants to the item variant in order to make GAPS work..

Screenshots to illustrate issues

item as the generic item

Issues with properties being on the generic item, not the item variant:

Issues with properties missing from item variant:

Issues with not being able to see details about item variants during stock management processes:

Issues with incorrect unit being used:

item as the item variant

Tried creating an item for every item variant as an alternative approach

But that means that you would have to create an item variant for each item variant so you could capture packaging details for GAPS...

Expected behaviour 🤔

How to Reproduce 🔨

Your environment 🌱

• Open mSupply Version: 2.4.00-RC1
• Legacy mSupply Central Server Version: 7-18-16

[craigdrown]

Be careful that we don't double up on the meaning of units Currently in mSupply for the above example the units would be "doses" - I think you're referring to "presentation" - which should be a separate field on the variant I think? We usually say the units field answers the question "when I talk about 1 (pack) of this thing, what am I talking about?"

• e.g. tablets or a bottle of 100,
• e.g. grams of a cream or a 20g tube of a cream.

[adamdewey]

@craigdrown - I had a big discussion with @louisaw123 about this for vaccines.

Originally I was also wanting to use "doses" for units, but Louisa talked me around that it should actually be "vials" or "ampoules" etc and that doses should be 'sub-units'

I spoke with @jagoje about how we could use the item variants to work for countries and we looked at a couple of client vaccine lists.

It seems that the common thing for vaccines is to group by 'presentation + # of doses' and the item variants would just be different manufacturers for each of those 'presentation + # of doses' combinations.

So we decided that we should suggest that for vaccines:

• universal codes = generic item (e.g. BGC)
• item name = 'presentation + # of doses' (e.g. BCG vaccine - ampoule - 1 dose)
• item unit = the presentation (e.g. ampoule)
• item # of doses = number of doses (e.g. 1)
• item variant = different manufacturers (e.g. Manufacturer A, Manufacturer B)

(I'm not sure what terminology to use for the combination of 'presentation + # of doses' as it seems to be unique for vaccines - but WHO distinguishes between 'presentation' (vial, ampoule etc) and '# of doses' (1, 5, 10 etc))

[louisaw123]

Aha! Hmm sorry I haven't read the context above but if I can just clarify one of the points about units for vaccine that I made - the units would be in total mLs of the immediate packaging (units would not be the presentation). So here is a real life example of what the same drug would look like with the differences of both highlighted:

ITEM 1: Item name: Raxtozinameran COVID-19 mRNA vaccine Strength: 100mcg/mL Form: Injection (suspension) >>Units: 0.48mL Immediate packaging: Vial >>Dose: 1 Brand: Comirnaty Omicron XBB.1.5 Manufacturer: Pfizer

ITEM 2: Item name: Raxtozinameran COVID-19 mRNA vaccine Strength: 100mcg/mL Form: Injection (suspension) >>Units: 2.25mL Immediate packaging: Vial >>Dose: 6 Brand: Comirnaty Omicron XBB.1.5 Manufacturer: Pfizer

Hope that helps :)

[louisaw123]

Oh wait oops ... i just got what you mean now, I forgot how mSupply describes units lol. Hopefully I didn't just confuse you, otherwise just ignore the terminology I've used to describe it all and just take the context if that is helpful

[adamdewey]

Thanks Louisa - yeah so in those examples I think we can treat the ml and vials as equivalent, you're just losing a little bit of info on exactly how big the vials are.

But otherwise that aligns with the approach we're suggesting with having 1 item per 'presentation + dose'

[mark-prins]

To summarise requested changes, please edit if I have this incorrect:

• Remove dose from the item variant #5512
• Add more detail to the item variant selector used in inbound shipments #5514
• Add item variant selector to the stocktake line edit #5515
• ~Add item variant selector to inventory adjustments~
• Control visibility of item variants #5485

[lache-melvin]

• Add item variant selector to inventory adjustments

Can I understand this one? If I'm increasing/decreasing the quantity of stock on hand for a particular stock line... why would I need to choose the item variant?

[adamdewey]

Can I understand this one? If I'm increasing/decreasing the quantity of stock on hand for a particular stock line... why would I need to choose the item variant?

Good point, I was thinking of the OG inv adjustments where you could introduce new stock lines

[jmbrunskill]

Can I understand this one? If I'm increasing/decreasing the quantity of stock on hand for a particular stock line... why would I need to choose the item variant?

Arguably fixing the chosen item_variant would be an inventory adjustment of sorts? Feels like a nice way to fix it rather than having to do a stock take? That said, I think as long as there is a least method to introduce the variant for an existing stockline we're fine.

[adamdewey]

Arguably fixing the chosen item_variant would be an inventory adjustment of sorts? Feels like a nice way to fix it rather than having to do a stock take? That said, I think as long as there is a least method to introduce the variant for an existing stockline we're fine.

Looks like you can just switch the variant on the stockline at the moment without doing an inventory adjustment:

Whether that's desirable or not is a different question 🤔

[mark-prins]

Can I understand this one? If I'm increasing/decreasing the quantity of stock on hand for a particular stock line... why would I need to choose the item variant?

this is why I left it out of stocktakes in the requirements. The reason for bringing it in, is that we can add batches during stocktakes too. In particular, when deploying it is common practice to begin with a stocktake in order to introduce all of your stock into the system. In which case - helpful to have variant selection on stocktake - you don't want to force people to use inbound shipments to bring in all stock, especially stock that's sitting in the facility already

[adamdewey]

this is why I left it out of stocktakes in the requirements. The reason for bringing it in, is that we can add batches during stocktakes too. In particular, when deploying it is common practice to begin with a stocktake in order to introduce all of your stock into the system. In which case - helpful to have variant selection on stocktake - you don't want to force people to use inbound shipments to bring in all stock, especially stock that's sitting in the facility already

Ah, but stocktakes differ to inventory adjustments right?

I think Laché is meaning this functionality:

Which only allows the user to increase / decrease existing stocklines, not create new stocklines

[mark-prins]

yes, that one and adjusting an existing stock line on a stocktake I'm not bothered about. Even this one:

which is the 'add a new stock line' version of the 'Adjust' button : I'm less concerned about that.

It's the adding of stock lines through a stocktake which would be the biggest issue

[craigdrown]

Just a couple of points - I haven't understood every comment, sorry. i. important that variants aren't foisted on users that don't want to think about them- in OG we'd have a pref to show/hide if we were doing it- or have a default variant of "n/a" that was always selected. ii. has to work smoothly with non-cold chain stock iii. I do think variants need to be able to be stocktaken (sp?) and have their own audit trail (maybe not right now- but certainly before they're widely used). That would mean that you need a transaction for all variant changes (e.g. if changing from one variant to another for a stock line you'd need to decrease one and increase the other with an invoice_line record)

[jmbrunskill]

Moving to backlog as high priority items are now done.

[adamdewey]

Just a couple of points - I haven't understood every comment, sorry. i. important that variants aren't foisted on users that don't want to think about them- in OG we'd have a pref to show/hide if we were doing it- or have a default variant of "n/a" that was always selected. ii. has to work smoothly with non-cold chain stock iii. I do think variants need to be able to be stocktaken (sp?) and have their own audit trail (maybe not right now- but certainly before they're widely used). That would mean that you need a transaction for all variant changes (e.g. if changing from one variant to another for a stock line you'd need to decrease one and increase the other with an invoice_line record)

Think i and ii are ok.

iii isn't in place at the moment - you can switch between variants without any audit trail I think