Readme

 SimTIVA Readme, Version 1, Oct 2021


MAIN.JS


Introduction to algorithm

SimTIVA is a computer program to simulate the delivery of TIVA using a TCI pump. However, a major difference is that the function and purpose of SimTIVA is not to drive a syringe pump. In a TCI pump, the infusion rates are updated frequently, e.g. every 10 seconds. However, in SimTIVA, the concept is to simplify the infusion regimen so that the infusion rates need to be adjusted just several times per hour (definitely not every other second or minute), otherwise it will be too cumbersome for the anaesthetist looking after the patient to frequently alter the infusion rate on the pump. With this in mind, in CPT or CET mode, SimTIVA infusion regimen only requires you to change infusion rates for typically 5-7 times for the first hour or so. The downside of this is accuracy, SimTIVA will not be able to deliver a perfect CP/CE target because the CP/CE will fluctuate if the infusion rates are not adjusted very frequently. This is analagous to using a Bristol 10-8-6 regimen, with just a few changes over time, the CP targeting would be quite crude.


Thanks to Stanpump and its creator Dr. Shafer, the PK programming is made possible. In Stanpump and in Shafer’s article, he described the method to calculate the infusion rate to deliver a certain CPT over a period of time. Let’s say, the period of infusion rate change is every 10 seconds, for a typical pump. The first step is to predict the CP after 10 seconds if the infusion rate is zero (we call this trial_cp). Then to calculate the infusion rate required to maintain a desired concentration, the equation looks like this: trial_rate = (desired – trial_cp)/p_udf[interval], where trial_rate is our answer, p_udf is the unit disposition function, interval is the pre-set interval – as mentioned before, for a typical pump it is 10s. The formulas to predict CP over time, to calculate UDFs, and the method to determine the infusion rate required to achieve and maintain CP are borrowed from Stanpump, for simplicity let’s call this the PK engine of stanpump.


Going back to the concept of SimTIVA, our intention is to NOT have our infusion rates adjusted as frequently. We arbitrarily define the interval as 120s, or 2 mins. We call this cpt_interval. The equation above will become: trial_rate = (desired – trial_cp)/p_udf[cpt_interval]. So in CPT targeting mode, the minimum duration when you next change your infusion rate will be 2 mins. Using the PK engine of Stanpump, the infusion rates are generated multiple times over a 2h period, meaning that there are 60 infusion rates, each lasting for 2 mins.


In CET mode, if desired CE is greater than current CE, then a bolus will be delivered. The CP will overshoot and then fall, and the CE will rise. There is a pause after the initial bolus. The pause is the duration from time zero to the point where CP intersects with CE, and at this point CE will reach CE target, or the peak CE. The method find_peak and hence the method to calculate the pause time are borrowed from Stanpump. From this peak point onwards, we just need to use the PK engine for CPT to generate the infusion rate to maintain CP (as CE will be equal to CP).


From a programming point of view, after the user inputs a CPT, the program will iterate the data over the future 7200s (2h). The data, which are stored in arrays, include CP, CE, volume infused, and the infusion rate (over each S). On the user interface, it looks as if the clock is ticking and the data are generated in “real-time”, but the program simply “reads” the data at the current time instance (a time relative to the starting time point, stored in a variable called time_in_s) and output the CP and CE and other data – which have been already generated when the CPT is first entered – to the user.


Variables and data structure

time_in_s – stores current time relative to start time, in seconds

cpt_interval – arbitrarily, default is 120s.

p_state and e_state.- arrays to store P states and E states, where p_state[1]+p_state[2]+p_state[3] equals CP and e_state[1]+e_state[2]+e_state[3]+e_state[4] equals CE

cpt_bolus – stores the bolus for CPT mode

cet_bolus – stores the bolus for CET mode

cpt_rates_real.- array to store infusion rates over time; note, this does not include the bolus. Unit is units/second

cpt_cp – array to store CP values over time, where cpt_cp[0] is an array of p_states at time 0s, and cpt_cp[1] is an array of p_states at time 1s.

cpt_ce – array to store CE values over time

volinf – array to store volume infused values over time. This is cumulative. Volinf[90] is the volume infused after 90s.

cpt_interval – defined as 120s

cpt_rates – array to store the 60 rates, each rate responsible for a duration of 2 mins


Description of functions

Function: readmodel

Description: reads the model and calculates parameters – compartment and rate constants


Function: calculate_udfs

Description: convert model parameters into lambdas (l1-l4)


Function: deliver_cpt

Description: Estimates a cpt_bolus. Generates cpt_rates, or 60 infusion rates, each rate represent a period over 2 mins. Applies a data-averaging algorithm, so that if the next rate isn’t so different from the last rate, an averaged rate is taken over this whole period of time. Writes the real (averaged) infusion rate (per second), p_states and e_states and volinf over a time period of 7200s into respective arrays.


Functions: getinfusionrate, getcp, getce

Description: reads the infusion rate, CP or CE at a certain time point (second).

Attached object 1, SimTIVA output cpt_rates for Marsh 70kg:


(cpt_bolus was 50mg)


[

    0.5156461265220742,

    0.20554075697278712,

    0.2001655240576306,

    0.19144429186227388,

    0.18462078276021682,

    0.17846739851595345,

    0.1729365386467919,

    0.16795977736067488,

    0.16347975156752134,

    0.15944495010617882,

    0.15580923001979197,

    0.1525312432319179,

    0.1495739386747753,

    0.14690411559415448,

    0.14449202334524647,

    0.14231100278441022,

    0.14033716493584086,

    0.13854910305844959,

    0.13692763464125499,

    0.13545557021643637,

    0.13411750620254773,

    0.1328996392801315,

    0.13178960006160073,

    0.13077630404988555,

    0.12984981808880794,

    0.12900124069492985,

    0.12822259482799858,

    0.12750673180708816,

    0.12684724521392107,

    0.12623839374527912,

    0.1256750320843089,

    0.1251525489572164,

    0.124666811628484,

    0.12421411616537023,

    0.12379114287202014,

    0.12339491635584063,

    0.1230227697446525,

    0.12267231262317628,

    0.12234140230225361,

    0.1220281180743922,

    0.12173073814522567,

    0.12144771896274971,

    0.12117767669510073,

    0.12091937063355396,

    0.12067168832062611,

    0.12043363222397427,

    0.12020430779541409,

    0.11998291277108473,

    0.11976872758375455,

    0.11956110677166724,

    0.11935947128034478,

    0.1191633015645332,

    0.11897213140712087,

    0.11878554238050576,

    0.11860315888363349,

    0.11842464369487103,

    0.11824969398709723,

    0.11807803775696743,

    0.11790943062530056,

    0.11774365297001674

]



Comments

Popular posts from this blog

Origin

Major Update

Progressive Web App: Why?