Temperature Range Storage Sync and GAPS Calculations

[jmbrunskill]

#4367

GAPS script will configure 3 location_type records in OG, for +5, -20 and -70
Create new translation for location_type in OMS (OG central data pull)
Add location_type_id to the location sync translations
Add location_type dropdown to the location edit modal in OMS
Display the location_type description (/name?) in parentheses in the location select dropdowns
Somewhere we will create a mapping to be used for the dashboards, deriving the known temperature ranges from the location_types to line up with the rest of the GAPS data

• Goals *
  For gaps we need to define a temperature range category for each locations, assets, and item_variants.

These will be used to estimate future storage requirements for planned vaccination campaigns as well as also estimating current capacity for stores based on current stock levels.

However, we also want to design the system for other future possibilities, such as automatically suggesting stock locations based on matching temperature requirements, and design the system we think it useful for future supply chain goals not just forcasting.

Suggested approach

Translate the location_type record from legacy into a temperature_range table in OMS.

Add temperature_range_id into item_variant and location tables

• Alternatives considered *

1. Same plan but keep the name location_type
   This is the same as the above, but keeps existing names.
   item_variant would be linked to a location_type

Pros:

• Easier to follow logic/naming from mSupply

Cons:

• mSupply design dictating what we have in OMS
• for future we think temperature_range explains the purpose and use case in OMS better than location_type which is quite generic...

2. Use a pre-defined ENUM temperature ranges (from location_type)
   This enum would be defined in the database with predefined options +25, +5, -20, -70
   Location Type would still be in OMS, but when translating it from sync, we'd automatically assign a temperature range enum to any associated locations when translating location records based on the min, max defined on the temperature location.

item_variant and location would both have this same enum

Pros:

• Less lookups for dashboard
• Simpler design

Cons:

• Not flexible for user, need a database/code change to add new temperature ranges
• Not sure if all use cases can map to standard ranges (what if one client wants different ranges?

2. Use a pre-defined ENUM temperature ranges (new field in mSupply)
   Similar to no.2 but we add an oms_temperature_category to location in mSupply.
   Translate this on the location record

Pros:

• Simpler design

Cons:

• Requires mSupply changes
• Still inflexible vs temperature_range table allowing custom ranges

[jmbrunskill]

Spoke with Louisa, she said that temperature ranges for drugs and vaccines are standardised worldwide, and if new temperature ranges were needed it would affect everyone (e.g. we think requiring an Open-mSupply upgrade to support a new drug that required 10-15 degree temperature range would be ok)

However the naming might be different if different countries e.g +5 is normally referred to as 2-8 degrees.

Drugs/Item themselves might have different sensitivities to different temperatures, like Heat Sensitive, or Cold Sensitive

[adamdewey]

I don't like Heat Sensitive / Cold sensitive because you can't tell which of the 3 ranges that relates to.

[adamdewey]

Yes, I think ok to hardcode the 3 standard ranges: +5, -20, -70 for starters and add new ranges if required.

It would be good to have the room temperature option too, although potentially that could be indicated by the absence of any temperature storage requirements?

[adamdewey]

Thought I guess you can't tell if absence means 'room temperature' or 'I forgot to specify a temperature range'

[adamdewey]

I think it would be prudent to add labels though - so the user could re-name the ranges centrally if they prefer?

E.g. +5 °C or 2-8 °C or Ultralow

[andreievg]

Hmm, i think if we keep existing table, rename it to something like cold_storage_type and use it on location, asset and item_variant

[jmbrunskill]

FYI - Each asset can have multiple cold_storage_types

[adamdewey]

Maybe it should be storage_temperature_type as there is the potential for CTC (Controlled Temperature Chain) to be introduced which covers stock that is not necessarily 'cold', but could be at room temperatures from 20 °C up to 40 °C (and even beyond)