V predchádzajúcom článku sme si predstavili oref0 a oref1 — kto, kedy a prečo ich napísal, aké rozhodnutia formovali ich dizajn a prečo sa tieto algoritmy stali jadrom dnešných open-source uzavretých slučiek. Tento článok predstaví technické detaily. Pozrieme sa na to, čo presne sa udeje po prijatí novej hodnoty z CGM, keď AAPS, iAPS alebo Trio vydá rozhodnutie o ďalšom dávkovaní inzulínu.
Cieľom nie je ponúknuť všetky riadky kódu — determine-basal.js má vyše 1100 riadkov a značnú časť tvorí validácia vstupov a obrana pred chybnými dátami: ako sú napr. nadmerný šum, zastarané merania, príliš plochá krivka naznačujúca zamrznutý senzor a ďalšie podmienky. Tieto kontroly rozhodujú, či sa cyklus vôbec vykoná. Ich logika je však priamočiara: ak ktorákoľvek z nich zlyhá, algoritmus zruší prípadné aktívne vysoké TBR, skráti dlhé nulové TBR na 30 minút a vráti sa k profilovému bazálu.
Cieľom tohto článku je ukázať kostru rozhodovania v hlavnej výpočtovej ceste, ktorá nasleduje po tom, ako vstupy prejdú validáciou: aké premenné do nej vstupujú, ako sa z nich vypočíta predikcia glykémie, ako sa z paralelných predikcií vyberie tá, ktorá určí dávkovanie, a aké bezpečnostné limity stoja medzi výpočtom a pumpou.
Vstupy ktoré má algoritmus k dispozícii
Pri každom spustení (typicky každých 5 minút, po príchode novej hodnoty z CGM) dostane funkcia determine_basal() v oref0 desať parametrov:
determine_basal(glucose_status, currenttemp, iob_data, profile,autosens_data, meal_data, tempBasalFunctions, microBolusAllowed, reservoir_data, currentTime)
Z pohľadu pacienta sú zaujímavé štyri dátové vstupy:
glucose_status — aktuálna glykémia a tri rôzne odhady jej rýchlosti zmeny: delta (rozdiel oproti meraniu spred 5 minút), short_avgdelta (priemerná zmena za posledných ~15 minút) a long_avgdelta (priemerná zmena za posledných ~45 minút). Tieto tri čísla majú zámerne rôzne časové okná — krátka delta reaguje rýchlo, ale je citliva na šum; dlhý priemer ignoruje šum, ale reaguje pomaly. Algoritmus si z nich vyberá podľa kontextu, čo je jednoduchá, no účinná forma filtrovania.
iob_data — aktívny inzulín (Insulin On Board), spočítaný z histórie všetkých bolusov, dočasných bazálov a SMB cez celé okno trvania účinku inzulínu (DIA). Ide o jednu z troch základných premenných celého výpočtu.
meal_data — aktívne sacharidy (Carbs On Board) a metadáta o poslednom jedle: kedy bolo zadané, koľko sacharidov bolo nahlásených, koľko sa už stihlo absorbovať a aká je aktuálna pozorovaná rýchlosť absorpcie.
profile — užívateľský profil. Bazálne rýchlosti podľa hodín, ISF (insulin sensitivity factor — o koľko mmol/l alebo mg/dL zníži glykémiu jedna jednotka inzulínu), I:C pomer (insulin-to-carb ratio), DIA (duration of insulin action), max_iob, max_basal a desiatky ďalších preferencií.
K tomu sa pripočítava currenttemp (čo aktuálne pumpa robí), autosens_data (aktuálny násobok citlivosti) a reservoir_data (stav zásobníka pumpy). Tento posledný parameter má bezpečnostnú úlohu, ku ktorej sa dostaneme v časti o SMB. Parametre tempBasalFunctions a microBolusAllowed nie sú dáta — sú to pomocné funkcie a príznak, či je v danom kontexte vôbec povolené mikrobolusovanie.
IOB: ako sa modeluje aktívny inzulín
Insulin On Board nie je triviálny výpočet. Pumpa síce vie, kedy bola podaná každá jedna jednotka inzulínu — otázka však znie, koľko z nej v tele ešte aktívne pôsobí.
Najstaršie pumpy používali lineárny model — jednotka podaná pred tromi hodinami pri DIA 5 h má zostávajúci IOB 40 % (zvyšné 2/5 z 5 h). 40 % je zostávajúce množstvo aktívneho inzulínu, nie jeho aktivita — aktivita (okamžitá rýchlosť účinku) je v lineárnom modeli konštantná, čo je práve to, čo robí tento model empiricky nepresným. Inzulín v skutočnosti nepôsobí konštantne — má prudký nábeh, vrchol účinku približne po 40 – 75 minútach od podania, a potom dlhý chvost rozpadu.
oref0 v prvých verziách používal bilineárny model — dva lineárne segmenty s lomom v očakávanom vrchole účinku. Bol to kompromis medzi výpočtovou jednoduchosťou a empirickou presnosťou. Neskôr prešiel oref0 na exponenciálnu krivku, ktorá je dnes štandardom vo všetkých derivátoch (AAPS, iAPS, Trio). Užívateľ si pri konfigurácii vyberie jeden z troch profilov:
- rapid-acting — vrchol účinku pri 75 minútach (Humalog, NovoRapid, Apidra)
- ultra-rapid — vrchol účinku pri 55 minútach (Fiasp, Lyumjev)
- bilinear — pôvodný model pre kompatibilitu so staršími profilmi
- alebo pacient nastaví vlastný vrchol účinku
Exponenciálny model v oref vyžaduje DIA aspoň 5 hodín — je to dolná hranica, nie fixná hodnota, používateľ môže nastaviť viac. Toto pri prechode z inzulínovych pier alebo iného AID systému často vyvoláva otázky. Odpoveď leží v tom, čo DIA ako číslo v rôznych systémoch znamená.
Klasická bolusová kalkulačka pumpy pod DIA chápe okamih, kedy je inzulín z pohľadu kalkulácie korekcie prakticky vyčerpaný — t.j. má pod 5 % aktivity. Preto v pumpe býva DIA často nastavená na 2 alebo 3 hodiny. Exponenciálny model oref0 modeluje celú krivku — vrátane dlhého chvosta, ktorý reálne pôsobí 5 a viac hodín, len s veľmi nízkou aktivitou. Toto rozšírenie chvosta je dôležité: ak ho ignorujete, algoritmus podcení IOB v období 3 – 5 hodín po boluse a zbytočne dávkuje viac.
A práve tu sa oref zásadne odlišuje od komerčných algoritmov.
Tandem Control-IQ používa pri aktívnej uzavretej slučke fixne 5 hodín a túto hodnotu si používateľ nemôže zmeniť.
Medtronic SmartGuard zvolil opačnú filozofiu. Jeho parameter sa volá AIT (Active Insulin Time) a je konfigurovateľný v rozsahu 2 až 8 hodín, pričom Medtronic v dokumentácii explicitne uvádza, že AIT nie je určená na to, aby reflektovala fyziologický metabolizmus inzulínu. SmartGuard AIT nie je odhadom toho, ako dlho inzulín v tele pôsobí — je to ladiaca páka agresivity algoritmu. Nižšia AIT znamená, že SmartGuard počíta IOB ako rýchlejšie vyprchávajúci, dôsledkom čoho je dávkovanie korekcií agresívnejšie.
oref0 a oref1 stoja medzi týmito dvomi prístupmi, ale bližšie k Tandemu. DIA v oref reprezentuje skutočnú farmakokinetickú dĺžku účinku inzulínu — od podania až po prakticky úplný rozpad. Tieto algoritmy modelujú celú exponenciálnu krivku vrátane jej dlhého chvosta, kde aktivita klesá pod 5 %, ale ešte nie je nulová. Práve preto je DIA pod 5 h v oref pokladaná za pravdepodobne nepresnú reprezentáciu fyziológie. Užívateľ nemá k dispozícii „páku agresivity“ cez DIA, ako je to v SmartGuarde — agresivita oref sa nastavuje cez iné parametre (SMB delivery ratio, max_iob, max basal multipliers, target rozsah).
Z toho vyplýva jedna praktická vec: pri prechode z Medtronic na AAPS, iAPS alebo Trio nemá zmysel kopírovať hodnotu AIT z Medtronicu ako DIA v oref. Sú to dva odlišné parametre. Ak má pacient AIT 2 h v Medtronicu, neznamená to, že jeho inzulín skutočne pôsobí 2 hodiny — znamená to, že Medtronic algoritmus si tak modeloval IOB pre konkrétne nastavenie agresivity. V oref by ekvivalentná agresivita vznikla úplne inak, cez bezpečnostné multiplikátory a SMB ratio, pričom DIA by zostala fyziologicky správnych 5 – 7 hodín.
COB a absorpcia: oref nedôveruje zadanému jedlu
Carbs On Board (COB) sa v odbornej literatúre zvyčajne uvádza ako jednoduchá lineárna funkcia: po zadaní 60 g sacharidov sa predpokladá konštantná rýchlosť absorpcie 30 g/h, takže by COB malo po dvoch hodinách klesnúť na nulu.
oref0 pristupuje k tomuto výpočtu odlišne. Algoritmus si udržiava premennú remainingCATime, ktorá predstavuje očakávaný čas, počas ktorého sa ešte budú vstrebávať sacharidy, ktoré zatiaľ nie je možné pozorovať ako absorbované. Táto hodnota vzniká v dvoch krokoch.
Najprv sa stanoví východisková hodnota podľa množstva sacharidov. Minimum sú 3 hodiny (remainingCATimeMin = 3), no pri väčšom jedle sa táto hodnota zvýši prostredníctvom assumedCarbAbsorptionRate = 20 g/h. V praxi to znamená, že jedlo do ~60 g dostane východiskové 3 h, 80 g dostane 4 h a 120 g dostane 6 h.
Potom sa remainingCATime predlžuje podľa času od posledného zadania sacharidov:
remainingCATime = remainingCATimeMin + 1.5 * lastCarbAge / 60
Teda za každú hodinu, ktorá ubehla od zadania jedla, sa horizont očakávanej absorpcie predĺži o 1,5 hodiny. Princíp je rovnaký, aký sa v oref objavuje opakovane: čím dlhšie sa jedlo nevstrebáva tak, ako algoritmus čakal (vysoký tuk/bielkoviny, gastroparéza, nadhodnotená gramáž), tým viac sa horizont natiahne — ale skutočná pozorovaná rýchlosť absorpcie (carb impact z CGM) má vždy prednosť a remainingCATime slúži len ako odhad pre tú časť sacharidov, ktorú zatiaľ nevidno.
Poznámka: v starších verziách kódu existoval mechanizmus, kde sa predĺženie odvíjalo od podielu už absorbovaných sacharidov (
fractionCOBAbsorbed). V aktuálnom kóde sa táto hodnota počíta už len do logu; reálne predĺženie riadi množstvo sacharidov a čas od jedla, ako je popísané vyššie.
Algoritmus berie zadanie pacienta ako počiatočný odhad, nie ako pravdu. Dôležité sú dáta vypozorovaná z CGM.
Štyri predikčné krivky a eventualBG
Po výpočte IOB, COB a aktuálnej rýchlosti zmeny glykémie sa oref0 dostáva k jadru rozhodnutia: kde bude glykémia o niekoľko hodín? Pretože odpoveď závisí od toho, čo sa medzitým udeje, oref0 nepočíta jednu predikciu, ale štyri paralelné predikčné krivky. V kóde sú to štyri polia hodnôt: IOBpredBGs, ZTpredBGs, COBpredBGs a UAMpredBGs. Každé zodpovedá inej hypotéze o budúcnosti.
- IOB-based (
IOBpredBGs). Hypotéza: nebudú sa absorbovať žiadne sacharidy a aktuálne nastavený bazál pokračuje bez zmeny. Predpoveď je založená čisto na krivke rozpadu aktívneho inzulínu. Toto je „najbezpečnejšia“ predikcia v tom zmysle, že nepredpokladá nič mimo aktuálne pozorovaných faktov. - Zero-temp (
ZTpredBGs). Hypotéza: čo by sa stalo, keby sme od teraz dávali nulový bazál? Toto je predikcia najhoršieho prípadu z opačnej strany — odpoveď na otázku „ak vypneme inzulín, kam najnižšie môžeme spadnúť, kým to nezachytíme?“. - COB-based (
COBpredBGs). Hypotéza: aktívne nahlásené sacharidy budú pokračovať vo vstrebávaní podľa pozorovanej rýchlosti. Túto predikciu používa algoritmus pri jedlách — odpovedá na otázku „kam pôjde glykémia, ak budú prebiehať veci tak, ako práve teraz?“. - UAM-based (
UAMpredBGs). Hypotéza: glykémia stúpa, ale neboli zadané žiadne sacharidy (Unannounced Meal). Buď je jedlo nenahlásené, alebo ide o stres, hormonálny vplyv či iný dôvod. Algoritmus extrapoluje aktuálnu rýchlosť rastu do budúcnosti s postupným útlmom.
Vedľa týchto štyroch kriviek stojí eventualBG — nie piata krivka, ale jediné odvodené číslo, ktoré algoritmus zvyčajne loguje ako svoju „cieľovú“ predikciu. Nepočíta sa ako asymptota plnej metabolizácie, ale priamo:
naive_eventualBG = bg − IOB * ISF
eventualBG = naive_eventualBG + deviation
teda aktuálna glykémia mínus efekt aktívneho inzulínu, plus pozorovaná odchýlka (v kóde a logoch označovaná ako odchýlka, ktorá v sebe nesie aj efekt jedla). Ak existuje COB, eventualBG sa ešte zdvihne na koniec COB predikcie (eventualBG = max(eventualBG, koniec COBpredBGs)). Ide teda o súhrnnú skalárnu hodnotu odvodenú z tých istých vstupov, nie o samostatný scenár.
Zo štyroch predikcií vznikne jedno rozhodnutie
Algoritmus predikcie neusporadúva podľa toho, ktorá je najpravdepodobnejšia — usporadúva ich podľa toho, ktorá je z hľadiska bezpečnosti najrelevantnejšia. Pracuje pritom s dvomi kľúčovými minimami.
minGuardBG je bezpečnostný prah — najnižší bod, kam by glykémia mohla klesnúť. Počíta sa ako priemer najnižších bodov jednotlivých predikcií, vážený podielom doposiaľ nestrávených sacharidov (fractionCarbsLeft):
minGuardBG = fractionCarbsLeft · minCOBGuardBG
+ (1 − fractionCarbsLeft) · minUAMGuardBG
(keď nie sú aktívne sacharidy, redukuje sa na minimum z IOB/UAM/ZT prahov). Práve minGuardBG rozhoduje o tom, či treba inzulín stiahnuť.
minPredBG je minimum predikcie, ktoré vstupuje do dávkovacieho výpočtu (odvodené z IOB predikcie a ďalších kriviek).
Logika nízkej glykémie je nasledovná. oref nemá pevný prah 70 mg/dL, ako sa niekedy uvádza — prah si dopočítava z cieľa:
threshold = min_bg − 0.5 · (min_bg − 40)
Pre cieľ 100 mg/dL vyjde prahová hodnota 70; pre cieľ 110 vyjde 75. Ak minGuardBG klesá pod tento threshold, oref0 vydáva nulový dočasný bazál — bez ohľadu na to, čo hovorí eventualBG. Keď je predikcia v cieľovom rozsahu, algoritmus nedáva nič nad rámec profilového bazálu. A iba keď je predikcia bezpečne nad cieľom, algoritmus uvažuje o tom, že podá viac inzulínu.
oref0 nedáva inzulín na korekciu vysokej eventualBG, ak existuje scenár, v ktorom by glykémia mohla najprv klesnúť pod prah. Toto je preložením jednej zo zásad referenčného dizajnu do matematiky – bezpečnosť pred efektivitou, vždy a v každom cykle.
Keď algoritmus dospeje k dávkovaniu, insulinReq sa počíta z minima oboch horných odhadov, nie len z jedného:
insulinReq = (min(minPredBG, eventualBG) − target_bg) / ISF
Vyhľadal vhodnejší sloveso na nahradenie „pripravuje“
Použitie min(minPredBG, eventualBG) znamená, že algoritmus dávkuje korekciu len vtedy, keď sú obe čísla nad cieľom — čo je ešte konzervatívnejšie, než keby pozeral len na jedno z nich. Ak glykémia smeruje pod cieľ, insulinReq vyjde záporné (počíta sa cez samostatnú vetvu 2 * min(0, (eventualBG − target)/ISF)) a algoritmus nastaví nulový alebo znížený bazál. Výsledný insulinReq je navyše vždy zhora orezaný tak, aby celkové IOB neprekročilo max_iob.
Ako oref0 premení insulinReq na dočasný bazál
V čistom oref0 (bez SMB) sa insulinReq premieňa na dočasnú bazálnu rýchlosť na 30 minút. Ak je potrebné podať 0,5 j navyše počas pol hodiny, vznikne TBR 1 j/h navýšenia oproti profilovému bazálu, na 30 minút.
Tu vstupujú do hry bezpečnostné limity. Funkcia getMaxSafeBasal() vracia:
maxSafeBasal = min(profile.max_basal,
3 × profile.max_daily_basal,
4 × profile.current_basal)
Tri limity, z ktorých sa vyberá najnižšia hodnota. Žiadny TBR nesmie prekročiť ani jeden z nich. max_basal je tvrdý strop, ktorý si pacient nastaví. max_daily_basal je priemerná denná bazálna rýchlosť — algoritmus nikdy nedovolí TBR vyššie ako jej trojnásobok. A current_basal je profilový bazál v aktuálnej hodine — pravidlo dovoľuje TBR maximálne štvornásobok aktuálneho bazálu. Tieto multiplikátory (current_basal_safety_multiplier = 4, max_daily_safety_multiplier = 3) sú konfigurovateľné cez preferencie, ale ich predvolené hodnoty prežili bez zmien od roku 2016.
To je dôvod, prečo oref0 nestíhal pri väčších jedlách. Ak má pacient profilový bazál 1 j/h, maximum TBR je 4 j/h. To znamená, že počas hodiny môže algoritmus podať najviac 3 jednotky inzulínu navyše oproti tomu, čo by tak či tak dal v rámci profilu. Pri 60 g sacharidoch s pomerom I:C 1:10 by chcel podať 6 jednotiek — a polovicu z toho dať okamžite. To oref0 z konštrukcie nedokáže.
Ako oref1 mení rozhodovanie
oref1 nemení žiadnu z prvých vrstiev výpočtu — IOB, COB, predikčné krivky, výber minGuardBG/minPredBG, výpočet insulinReq. Všetko po insulinReq prebieha rovnako ako v oref0. Rozdiel je v tom, ako sa spracuje insulinReq ďalej.
SMB nie je v AAPS zapnuté globálne — jeho aktivácia závisí od kontextu, v ktorom sa slučka práve nachádza. Na screenshote nižšie vidíte štyri podmienky, ktoré je možné nezávisle povoliť:
- Povoliť SMB — SMB je aktívne vždy; ostatné prepínače sa ignorujú (s výnimkou: vysoký dočasný cieľ + vypnuté „SMB s vysokými cieľmi“ SMB aj tak potlačí)
- Povoliť SMB s vysokými dočasnými cieľmi — SMB zostáva aktívne aj pri dočasnom cieli ≥ 5,5 mmol/l
- Povoliť SMB zo sacharidmi (
enableSMB_with_COB) — SMB sa aktivuje, len ak sú v systéme aktívne sacharidy - Povoliť SMB s dočasnými cieľmi (
enableSMB_with_temptarget) — SMB sa aktivuje pri nízkom dočasnom cieli (< 5,5 mmol/l), typicky po zapnutí eating soon pred jedlom
Ak je insulinReq kladné a používateľ má povolený SMB v aktuálnom kontexte (napríklad cez enableSMB_with_COB alebo enableSMB_with_temptarget), oref1 vypočíta veľkosť mikrobolusu. V samotnom oref0 je to polovica požadovanej dávky:
microBolus = floor( min(insulinReq / 2, maxBolus) )
Pomer 1/2 je dôležitý detail. (Pôvodne v roku 2017 to bola 1/3 — limit existoval kvôli scenáru dvoch súbežných mini-počítačov, ktoré by mohli nezávisle vydať bolus. Keď dnes algoritmus beží len v telefóne pripojenom k pumpe cez Bluetooth, tento scenár neexistuje, a pomer sa zadefikoval ako 1/2.) V štandardnom oref0 je toto delenie zafixované v kóde; konfigurovateľný slider „SMB delivery ratio“ doplnili až deriváty ako iAPS, takže ak hodnotu meníte, robíte to cez nadstavbu, nie cez pôvodný oref.
maxBolus je tvrdý strop daný preferenciami — vyjadrený ako maximálne minúty bazálu, ktoré môže jeden SMB obsiahnuť:
maxBolus = current_basal × maxSMBBasalMinutes / 60
maxSMBBasalMinutes má predvolene 30 minút, čiže pri profilovom bazále 1 j/h to znamená max. 0,5 j na jeden SMB. Pre UAM situácie existuje samostatný limit maxUAMSMBBasalMinutes, ktorý sa dá nastaviť odlišne — typicky vyššie, aby slučka dokázala reagovať na nenahlásené jedlo, ale stále v medziach bezpečnosti.
Pred každým SMB algoritmus nastaví nulový dočasný bazál dostatočnej dĺžky, aby platilo: ak by tento SMB bol posledná akcia, ktorú systém vykoná, glykémia by sa mala vrátiť do bezpečného rozsahu sama od seba. Dĺžka nulového TBR sa vypočíta tak, aby súčet inzulínu z SMB plus inzulínu, ktorý by sa nepodal počas nulového TBR, dohromady dali číslo, ktoré algoritmus ešte stále považuje za bezpečné voči predikcii poklesu. Ak oref1 podá 0,5 j ako SMB a profilový bazál je 1 j/h, dostatočne dlhý nulový TBR „vráti“ 0,5 j počas nasledujúcich 30 minút — čistá súvaha je z pohľadu množstva inzulínu nulová, ale rozdelenie v čase je výrazne odlišné.
Tento mechanizmus je dôvod, prečo SMB nie je len skratkou pre rýchlejšie dávkovanie. Je to kontrolovaný posun inzulínu v čase, ktorý zostáva reverzibilný, kým je nulový TBR aktívny.
Bezpečnostné kontroly pred každým SMB
Medzi výpočet a vyslanie príkazu pumpe vstupuje séria bezpečnostných podmienok. Každá z nich má v zdrojovom kóde explicitnú kontrolu, ktorá pri zlyhaní zruší SMB.
Reservoir check. Ešte pred vlastným bolusovým príkazom algoritmus načíta zo zariadenia stav zásobníka pumpy a uloží ho. Po výpočte SMB sa zásobník číta znovu. Ak sa medzitým hodnota zmenila o viac, než zodpovedá vypočítanej dávke, niečo sa stalo asynchrónne — pacient možno podal manuálny bolus z pumpy. SMB sa zruší.
History check. Algoritmus skontroluje históriu liečby z pumpy a overí, že posledný SMB bol podaný dostatočne dávno (typicky pred viac ako 3 minútami). Toto chráni pred situáciou, keď by sa rovnaký výpočet z nejakej príčiny vyhodnotil dvakrát po sebe.
IOB ceiling. Zlúčená hodnota IOB po podaní SMB nesmie prekročiť max_iob z profilu. Toto je tvrdý strop množstva inzulínu, ktoré môže byť v tele naraz nadávkované cez TBR a SMB.
A52 prevention. Pri Medtronic pumpách sa pred SMB posielajú tri ESC stlačenia, ktoré preventívne vyčistia akékoľvek otvorené menu na pumpe. A52 chyba (zlyhanie komunikácie počas pokusu o bolus) sa v takejto sekvencii vyskytuje výrazne menej často.
Autosens
Autosens sa do rozhodovacej cesty zapája pred výpočtom insulinReq a robí modifikáciu ISF a bazálne rýchlosti pred ich použitím v predikčných výpočtoch.
Mechanizmus: každých 5 minút sa pre každú historickú hodnotu glykémie spočíta odchýlku (deviation) — rozdiel medzi tým, čo sa stalo, a tým, čo by sa malo stať podľa predikčného modelu (s nulovými sacharidmi). Ak by predikcia bola dokonalá, medián odchýlky za posledných 24 hodín by bol nulový. V realite je takmer vždy nenulový, pretože reálna citlivosť pacienta sa odlišuje od profilových hodnôt.
Z mediánu odchýliek sa odvodí sensitivityRatio — multiplikátor, ktorým sa modifikuje ISF aj bazál. Ak je medián odchýlky napríklad −5 mg/dL/h (glykémia klesá rýchlejšie, než by mala), sensitivityRatio sa nastaví nad 1,0 — pacient je citlivejší — a ISF sa proporcionálne zvýši (potrebuje menej inzulínu na dosiahnutie rovnakého efektu).
sensitivityRatio je obmedzený parametrami autosens_min a autosens_max (typicky 0,7 a 1,2). Toto je dôležitá bezpečnostná hranica — ak by Autosens mohol bezbreho meniť ISF, jeden zlý deň s nezvyčajnou aktivitou by mohol zlyhanie predikcie zmeniť na zlyhanie dávkovania. Rozsah −30 % až +20 % okolo profilovej hodnoty je rozumný kompromis medzi adaptáciou a bezpečnosťou.
V moderných systémoch je k dispozícii aj high_temptarget_raises_sensitivity a exercise_mode. Tie umožňujú, aby používateľom nastavený dočasný cieľ glykémie nepriamo zmenil aj sensitivityRatio — vyšší cieľ implikuje vyššiu citlivosť, ktorá vedie k znižovaniu bazálu nielen kvôli vyššiemu cieľu, ale aj kvôli zníženému dávkovaniu.
Čítanie oref logov
Každé rozhodnutie oref zaznamenáva v poli reason celé svoje odôvodnenie — jeden textový reťazec, z ktorého sa dá zrekonštruovať celá rozhodovacia cesta. V AAPS ho nájdete na záložke OpenAPS SMB.
Na screenshote nižšie vidíte reálny príklad:
COB: 0, Dev: 2.0, BGI: -0.3, ISF: 2.6, CR: 10, Target: 5.0,
minPredBG -4.7, minGuardBG -6.8, IOBpredBG 2.2, UAMpredBG 2.2;
minGuardBG -6.8 < 3.7Z tohto reťazca sa dá zrekonštruovať celá rozhodovacia cesta:
- COB 0 g, odchýlka (deviation) +2,0 mg/dL, BGI −0,3 mg/dL/5 min
- ISF 2,6, carb ratio 10 g/j, target 5,0 mmol/L
- Aktuálna glykémia 124 mg/dL, IOB 3,09 j — v tele je stále veľa aktívneho inzulínu z predchádzajúceho bolusu
- IOB a UAM predikcia: glykémia klesne na 2,2 mmol/L; minGuardBG −6,8 mmol/L je hlboko pod bezpečnostným prahom 3,7 mmol/L
- eventualBG 39 mg/dL (2,2 mmol/L) → insulinReq 0,0 j
- Výsledok: nulový bazál na 120 minút — loop zastavuje inzulín a čaká, kým IOB odznie
Toto je ukážkový prípad, kde je aktuálna glykémia zdanlivo v poriadku (124 mg/dL), ale algoritmus vidí ďalej: množstvo aktívneho inzulínu ťahá predikciu hlboko do hypoglykémie. Preto nezáleží na tom, kde je glykémia teraz — záleží na tom, kde bude.
Štyri scenáre v praxi
Nasledujúce štyri grafy ukazujú rozhodovaciu logiku v typických situáciách. Zelená čiara = cieľ, červená = bezpečnostný prah, fialová krivka = predikcia glykémie.
Scenár 1
Glykémia v krátkom horizonte rastie, no dlhodobo je predikovaná nielen pod cieľ, ale až pod bezpečnostný prah. Keďže hrozí hypoglykémia, oref nastaví nulový bazál dovtedy, kým sa minimálna predikcia nedostane nad prah.
Scenár 2
Tu hrozí pokles pod prah už v blízkom horizonte, hoci neskôr by glykémia skončila nad cieľom. Pretože ktorýkoľvek bod predikcie pod prahom má prednosť, oref opäť nastaví nulový bazál — a drží ho, kým žiadna časť krivky neostane pod prahom.
Scenár 3
Predikcia krátkodobo klesá pod cieľ, ale zostáva nad prahom, a eventualBG je nad cieľom. oref sa teda vyhne inzulínu, ktorý by prispel ku krátkodobému poklesu, a až keď je to bezpečné, pridá dávku, ktorá stiahne najnižší bod predikcie k cieľu — podľa nastavení cez zvýšený bazál alebo SMB.
Scenár 4
Glykémia je vysoko nad cieľom, ale vďaka načasovaniu inzulínu je v tele už dosť IOB na to, aby ju dlhodobo stiahol — dokonca pod cieľ. oref preto nepridáva ďalší inzulín a namiesto toho pravdepodobne zníži bazál (low temp).
Tieto štyri scenáre sú najrýchlejší spôsob, ako si zapamätať jadro celej logiky: nezáleží na tom, kde je glykémia teraz, ale na tom, kadiaľ povedie celá predikčná krivka — a najnižší bod krivky rozhoduje skôr než ten konečný.
Záver
oref0 a oref1 sú konštrukčne unikátne, pretože každé rozhodnutie je výsledkom uzavretej, deterministickej výpočtovej cesty, ktorú vie pacient spätne prejsť. Žiadny krok nie je „čierna skrinka“. Každý parameter má fyziologickú interpretáciu. Každý multiplikátor má číselnú hodnotu, ktorá sa dá konfigurovať a logovať.
Z toho vyplýva väčšina vlastností, ktoré v prvom článku spomínam iba ideovo. Bezpečnosť pred efektivitou znamená, že minGuardBG má prednosť pred eventualBG v každom cykle. Návrat k profilu pri zlyhaní znamená, že každý TBR má prirodzenú expiráciu. Transparentnosť znamená, že reason field obsahuje celý myšlienkový pochod algoritmu v jednom riadku textu.
Práve v tom spočíva skutočná výhoda open source. Nejde len o to, že vidíme, prečo sa systém v danom okamihu rozhodol tak alebo onak — ide o to, že na základe tohto poznania môžeme algoritmus doladiť presne na mieru vlastnému telu. Každý parameter, ktorý vieme prečítať, vieme aj zmeniť: ak nám DIA, ISF, citlivostné limity alebo správanie SMB nesedia, neostávame odkázaní na rozhodnutie výrobcu. Komerčný systém ponúka hotové riešenie, ktoré buď vyhovuje, alebo nie. Open source ponúka systém, ktorý dokážeme prispôsobiť — a to je rozdiel, ktorý v dlhodobej kompenzácii rozhoduje.