Insulin concentration v2

[MilosKozak]

No description provided.

[MilosKozak]

My proposal is to put layers between
CORE <-> Pump .... PumpWithConcetration interface
CORE <-> ProfileStore .... ProfileStoreWithConcentration interface (maybe it could not be neccessary, see bellow)
and probably
CORE <-> PumpSync too (depend on other decisions) because it's a way how Pump talk back

this way we can change the behavior and only hardly touch the original code
Bolus progress can be adpated after refactoring (in progress)

We must clearly specify what data is stored and used where like:
UI ... U100 or both
DB ... U100
pump DBs ... UXXX?
profileStore ... U100?
TDD ... ????

this must be documented on interfaces

[MilosKozak]

@Philoul read the code if you understand my ideas pls

[Philoul]

Proposed Vocabulary:

• IU for International Units (the real number of Insulin units delivered)
• CU for Concentrated Units (Converted values sent to the pump to deliver the right volume of insulin according to user request)
• concentration: Double value used to manage convertion between IU and CU (i.e. for U200, concentration equals 2.0):
  IU = concentration * CU

Proposal of answer on my point of view:

• User Interface: IU for all information from or to DB (including status light in main screen, even if reservoir level comes from pump), both = IU (CU) for all values managed by the pump or information coming from Pump Driver (i.e. BolusProgress Dialog, Alerts from Pump like Low Reservoir level, Current Status within Pump Driver...). TBC for history values within Pump Driver (could be only CU or both values IU (CU)...
• DB : IU (Real amount should be recorded within database for everything, Loop algo, APS algo, User Interface, Autotune, NS Synchronisation, ...)
• Pump DBs : CU + TBC concentration (CU to store raw value in Pump DB, consistant with Pump history, and concentration value can be added to each absolute record (bolus or rate), to be able to calculate and show both values IU (CU) in pump user interface. % rates are based on Profile so remains identical. Profile managed within Pump Driver and sent to the Pump should be a "Concentrated Profile" (mainly basal rates converted). Pump Current Status should be shown with Both values: IU (CU)
• profileStore : IU
• TDD : IU (calculated from DB), TBC IU or IU (CU), for TDD got from Pump History

Additional opened topic to be decided:

• should we show Pump history with both values: IU (CU)? Better but probably not mandatory (CU remains consistant with Pump history so user can verify consistancy between AAPS (Pump Driver) and Pump (both with CU), but better because User can also check consistancy within AAPS between Pump Driver using IU.
• should we record in AAPS DB the concentration information with timestamp ? (if Yes, no need to record or modify Pump DB, IU can be calculated using AAPS DB concentration and timestamp of each record in CU, if No, then Pump DB should be updated to show both values IU and CU within Pump History, or none of them are recorded, and Pump history is only available with CU

[MilosKozak]

I changed VU to CU ...... hard to think about it like about "virtual" when they are "real"

[MilosKozak]

Thinking about to create something like:

class Insulin(val concentration: Double) {
   var u100Units: Double
   val concentratedUnits: Double get() = u100Units * concentration

   fun setIU(): Insulin
   fun setCU(): Insulin
}

and use it where we have insulin: Double now to be clear what value is inside
But only on places where we do the conversion (not to touch original code, at least for now) and in PumpSync where Pump reports back

ProfileStoreWithConcentration will not be needed then. We can revert the code

[MilosKozak]

I hope you didn't remove previous code. We will re-use most of it :)

[MilosKozak]

regarding pump history I'd keep only CU. Pump driver should not be aware of concentration at all. It will simplify pump drivers development

[MilosKozak]

regarding storing to DB I'd utilize InsulinConfiguration (extended by concentration) for Bolus, ProfileSwitch and EffectiveProfileSwitch
It would mean

• update DB schema
• create new ProfileSwitch if concentration change
• update core code to make using InsulinConfiguration mandatory

Do you agree? Do you see some sideeffects or something I missed?
This preparation should be the first step, I think

[sonarqubecloud]

Quality Gate passed

Issues
31 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[Philoul]

I hope you didn't remove previous code. We will re-use most of it :)

I always keep everything ;-) (at least for a long time)... and I'm currrently use it for my loop so no risk to remove it before final architecture...).
We can reopen the PR if you prefer...

[Philoul]

Thinking about to create something like:

class Insulin(val concentration: Double) {
var u100Units: Double
val concentratedUnits: Double get() = u100Units * concentration

fun setIU(): Insulin
fun setCU(): Insulin
}
and use it where we have insulin: Double now to be clear what value is inside
But only on places where we do the conversion (not to touch original code, at least for now) and in PumpSync where Pump reports back

On my PR, (after code refactoring), I created a ConcentrationHelper Interface to group maximum of calculation within a unique class...
We need both convertion: (fromPump in PumpSync, and toPump)
fun toPump(val u100Units: Double) = u100Units * concentration
fun fromPump(val concentratedUnits: Double) = concentratedUnits / concentration

[Philoul]

regarding storing to DB I'd utilize InsulinConfiguration (extended by concentration) for Bolus, ProfileSwitch and EffectiveProfileSwitch
It would mean
update DB schema
create new ProfileSwitch if concentration change
update core code to make using InsulinConfiguration mandatory
Do you agree? Do you see some sideeffects or something I missed?
This preparation should be the first step, I think

Yes, following this idea, I had in mind to also update ICfg with a new concentration property. (ICfg is already included within EPS class and is miroring InsulinConfiguration).

[Philoul]

create new ProfileSwitch if concentration change

Modifying concentration should be synchronized with a Reservoir Change event.

• Switching from U100 in reservoir to U200 in reservoir should not require a Profile Switch but only a synchronization with Reservoir Change Event...

But, Yes, create new ProfileSwitch if concentration change make sense if we include within ProfileSwitch dialog the selection of Profile AND the selection of Insulin (ICfg with Peak, DIA and concentration...)

• It make the bridge with my second huge PR Insulin Management outside ProfilePlugin #3952 (same story, first idea was quite simple, but at the end this second PR also modify a huge number of different files...)

Do you think we should rework both topics together?

[MilosKozak]

May it would be not necessary to popup ProfileSwitch. We can do it on background.
If there is PS with duration running we'd have to create 2 of them.
But it's necessary because EPS will be holding the information about concentration

[MilosKozak]

Regarding insulin management: yes, we should cover both in this preparation and make code ready for that some clean way