Management Insulin Concentration (from U10 to U200)

[Philoul]

Current Implementation is with an advanced setting included into all insulin Plugins:

• this parameter is enabled only if engineering_mode is enabled

Because this parameter has safety impact, on each reservoir change, user should confirm explicitly the value of "non U100 concentration" to enable close loop:

• using another concentration is allways managed in 2 steps: First the new concentration is entered manually in settings (request to change Insulin concentration), second step confirm the new concentration after the next reservoir change (a popup windows is shown, user must select exactly the same new concentration to confirm)
• without confirmation either the new concentration or the previous concentration, loop is disabled
• a new concentration can be requested and approved immediatly only if it's done within 15min after the reservoir change (after 15min, the previous approved concentration will be used if approved until the following reservoir change)

All values managed within AAPS and database are with "official units"
All values managed within pump drivers are with "Converted Unit" (for ex if U200 is selected, when the user select a bolus of 10U, PumSync send a bolus of 5U within the pump driver).

• PumpSync include convertion to pump and PumpEnactResult include opposite convertion from pump
• For Patch pumps (which get directly profile from profile, I had to include within each driver the concentration value for pump initialization)

I tested with my Insight pump all these features:

• ProfileSwitch
• % TBR
• Absolute TBR
• Extended TBR
• Bolus
• Extended Bolus

Remaining topics:

• fix Unit Test (a bit tricky)
• Decide User Interface within Pump driver: some inconsistencies can occurs within Pump History which shows converted units, when AAPS history shows "Real Units", same within Bolus Progress with header "Real amount" and progress "converted amount" (my proposal would be to propose an helper to modify all values within Pump history with for ex: 10U (5U) or 0.8U/h (0.4U/h) to show both values into all popup or fragment from or within pump drivers) See screenshot below with current implementation

• Test with all pump drivers (here I will need help, I only have Insight on my side currently)
• Test all different use cases (and probably some minor UI bugs can still be here...)

My big question concern the overall Target Architecture (this PR is not consistent with my other PR #3952)

• With a Unique Insulin Plugin which manage several insulins, it make more sense to have insulin Concentration as a parameter of the selected Insulin like Peak, DIA and Concentration, and not as a global parameter of the plugins (then constraints could be the same, but managed within ProfileSwitch filtered only with approved insulins/concentrations)

[Philoul]

Also remaining in my Todo list a dedicated wiki page with all explains, warnings risks using other insulin concentration (Current link included within my PR should be replaced and this dedicated wiki page writen...)

[jotomo]

Priming has an edge case to consider, as priming needs a certain amount, rather than concentration.
So when usually priming 1U to fill a catheter, with a U200 concentration, a prime bolus of 2U is needed.
Not sure how to address this well other than maybe adding a note in the prime dialog with current concentration (if enabled).
Technically it would be most correct to differentiate between amount and concentration, e.g. having the progress dialog show 5 μL when delivering that amount, which would equate to 1U of U200 concentration. But that's not really helping with a simpler user experience. It would make it harder to misread a 1U pump bolus as 1U when it's actually 2U though ;-)

[Philoul]

@jotomo good comment!

If priming is managed within pump driver (for ex in patch pumps) nothing to do.

My proposal to manage prime/fill dialog in action tab is:
In this dialog we have 2 checkboxes:

• one for site change
• one for reservoir change

We can use these checkboxes to keep the right volume of insulin delivered to prime or fill without convertion on user side:

• If at least one of the two checkbox is checked, then we can multiply amount by concentration (later it will be divided by concentration in pumpSync so the volume of insulin sent to the pump will be consistant with U100)
• If none of the two checkboxes are checked, then we keep selected value unchanged. It will be converted when sent to the pump (sometimes this button can be used to inject correction bolus not recorded in database).

BTW this will have to be explained in the dedicated wiki page required for this feature...

[Philoul]

@jotomo I updated the FillDialog in my latest commit and included a warning message (did it quickly so message/colors can probably be improved):

Correction is applied (with additional warning) only if one of the 2 checkboxes has been checked.

[Philoul]

Message modified to include Volume in µl (still have the little inconsistancy in UI because of value from pump driver), and result in pump driver with unconverted values)

[jotomo]

Nice updates!
About the inconsistency in the pump tab: the user needs to be aware (and be willing to deal with the added complexity) of having the actual pump show different values than the history tab etc.
It just needs to be clear which is which.
IMO, generally AAPS should show the effective units, the progress dialog should show both units and volume and the pump tab should mirror the pump (no change).
To make that clear, it could be an option to prepend a small fragment before the respective pump fragment in the UI (to keep it separate from pump UI/driver code). If a non-standard concentration is selected, this new fragment would state that all numbers in the pump tab reflect the pump, not the actual units.
One other detail is the display of remaining units on the main tab. This should show the available units (converted).
Like you said, a lot of details to get right :-)

[Philoul]

I'm currently refactoring the code to include a ConcentrationHelper to centralize and manage concentration like String convertion for UI with single or double values (Boluses/Rates/Reservoir level in Pump fragment), and convertion toPump and fromPump.

Within Pump fragment, my idea was to show both values (like within Bolus Progress) each time another concentration is used:

• Generally Patch pumps has no UI, so the only information concerning "Delivered Units" comes from AAPS within Pump Fragment
• Concerning Tube Pumps, here we should be able to compare on one side "Delivered Values within AAPS and delivered values within Pump History", and on the other side "Delivered Values in Pump Fragment with AAPS Treatment History".

My idea behind ConcentrationHelper is to see exactly the same information when insulin U100 is put within Pump (no visual change for end User), and show both values within Bolus Progress and Pump fragment when other concentration is put within pump...

[Philoul]

@jotomo what do you think of this UI for Bolus Progress?
(done within Insight Pump Driver with U200 on the left and U100 on the right, with my new Helper)

[Philoul]

In my 2 latest commits, I started to update Pump Fragment to have a visual information of both values (Real Units and value sent to the pump)

• Insight fragment and Virtual Pump fragment hve been updated.

These drivers are quite simple because no history is available. My proposal, is to keep untouched all history included within the other driver and only show "Pump Values" in history tab, and only update fragment for current status.

[MilosKozak]

Well I understand there is a push to have this feature implemented but ...
Modify code on so much places makes it hard to verify and even harder to maintain.
Here is main proposal (just skeleton without executive code) #4248
Let's discuss the rest there

[Philoul]

Well I understand there is a push to have this feature implemented but ...

Not a push, but I saw so many users (even very skilled) make mistakes with U200 and profile 50%, especially managing external boluses with wrong or missing convertion, so I'm convinced we cannot ignore these risks and mistakes...
BTW I prepared in parallel a dedicated wiki page to focus on the risks using other concentrations with "fake profile". Again will propose this dedicated page as a draft and starting point to open the discussion...

Modify code on so much places makes it hard to verify and even harder to maintain.

Fully agree! I tried to keep it centralized within CommandQueueImplementation, PumpSync and the different Command classes, but going further and further it became more and more complicated with more and more files modified. So I was not convinced by current architecture for the same reason.

[Philoul]

Linked to #4248 Reopened to keep initial proposal visible

[sonarqubecloud]

Quality Gate passed

Issues
12 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.4% Duplication on New Code

See analysis details on SonarQube Cloud