To start a new analysis in GlyCulator 3.0 click on the "Create new" button in the menu on the left-hand side.
Every analysis comprises 5 subsequent steps, i.e:
In order to be able to choose files from "Choose from My files" option while creating a new analysis, first you have to upload the desired files to GlyCulator in one of two ways:
It does not matter whether you do it with the first method or the second, however, the latter option enables you to do some things in advance.
Here, you can upload files from multiple manufacturers separately, and then e.g. convert all of them to GlyQ format once they appear in "My files".
Basically, the "Upload" panel resembles "Create new", but is much simplified. Here you only have to choose the manufacturer from the available list and then browse files from your computer.
The list of chosen files will be displayed as a table, where you will be able to modify your choice if needed (remove files if added by mistake). You can browse files multiple times from different directories and they will be accumulating in the table.
If all desired files are visible in the table click "Upload" button.
You will be informed when the uploading is finished and then you will be able to download the files in GlyQ format if needed (either separately or all at once by clicking "Download all" button). Remember, that we do not store your original files on the server and hence the only way you can retrieve data from a particular file is the GlyQ file.
If you deal with a patient that provides you with multiple files, usually containing overlapping dates and records, then "Merge" module comes as a solution.
It looks exactly like "Upload" module, however here you have to upload patient's files in a compressed format e.g. .zip, .tar. So, if you have e.g. 2 files for one patient then you have to manually compress them on your device and choose compressed file as "Input files". In the example visible in the image below on the right-hand side, you can see that there are two .csv files for one patient ("part_1.csv" and "part_2.csv") compressed to one .zip file ("Patient_to_merge.zip").
You can upload multiple compressed files in one merge, provided that they all come from the same manufacturer which you chose at the beginning.The recommended approach for benchmarking studies is to use the graphical interface of the GlyCulator 3.0 web platform. However, due to limitations of multi-file processing, we suggest that users with slow internet access or benchmarks exceeding 500 patients inquire about access to the application programming interface (API). To be granted programmatic access to the GlyCulator 3.0, you must be registered as a user and contact us for the Special services clause, described in detail in the About section (https://glyculator.btm.umed.pl/about). After the initial verification, you will be granted programmatic access to GlyCulator 3.0. Detailed documentation on GlyCulator 3.0 API is provided at https://glyculator.btm.umed.pl/api/docs. Due to GlyCulator 3.0 being a continuously updated and developed tool, some API functions may not be functional at all times. All the API functions required for benchmarks will be conserved to guarantee the reproducibility of GlyCulator 3.0 benchmarking studies.
The first step is the file upload. It can be performed by directly uploading files on the GlyCulator 3.0 web platform. For more information, see the “UPLOAD FILES” section of the user manual (https://glyculator.btm.umed.pl/user_manual). An alternative approach is using /upload function via API – remember that you need to pass a binary file stream into the POST request. To use predefined file standards, define device_type arguments – 1 for Dexcom, 3/5 for Abbott (.csv/.txt), 4 for Eversense, 8 for Medtronic, 9 for GlyQ96, 10 for GlyQ288 and 99 for user-defined. For date_format, available options are - 0 for MM/DD/YYYY (+hh:mm:ss), 1 for DD/MM/YYYY (+hh:mm:ss), 2 for YYYY/MM/DD (+hh:mm:ss).
After all the files are successfully uploaded, we recommend using the internal GlyQ standard. The GlyQ allows for the integration of files from different sensor systems, as long as they provide the same sampling frequency (currently supported only 288 and 96/day). For more details on the GlyQ standard, see the “WHAT IS GLYQ?” section of the user manual. The conversion can be done by using the conversion option in the “My files” tab, as described in the “MY FILES” section of the user manual. The conversion can also be performed using the /convert_file_by_hash API function, with hash available with the /files query.
After the files are uploaded and converted to GlyQ, a list of files for further analysis should be created. File selection can be performed either manually (by selecting appropriate file names via GUI interface) or using the /files query via API. Moreover, basic statistics for each uploaded file can be assessed either manually with the file’s detailed view within the “My files” tab (described in detail in the “MY FILES” section of the user manual) or by using API /files/{file_hash} query. We suggest using basic statistics to reduce the number of files included in the benchmark that could not be processed due to the lack of data in the predefined analysis period. For example, in the single-center benchmark example, the maximum number of files processed in a single period was 343 for the isCGM in 2021, which is ~7.5% of all available CGM files (4560). If all files were included at the filtration step, this would result in a 9-minute processing lag instead of the required 40 seconds.
The next step, creating a new analysis, is described in detail in the “CREATE NEW ANALYSIS” section of the user manual. For most benchmarking studies, we recommend using the predefined start and end dates to eliminate any potential sources of bias resulting from seasonal and holiday effects. As to CGM data selection based on dates and not active time criteria, it is crucial to assess % active-time for each processed file. Analysis creation can also be performed using API, with the /analyses/new function, which avoids automated quality assessment. The /analyses/new function requires date_from and date_to to be parsed for each file_hash included in the benchmark. The programmatic quality assessment is based on evaluating the “basic statistics” for each file, as described above. For the configuration of the imputation method in the /analyses/new, the imputation_method may be set as linear (for linear imputation), mean (for mean value imputation) or left empty to turn it off. After the analysis is created, the GlyCulator 3.0 will run the computation of glycemic variability indices in the background. Most standard benchmarks should execute in under 1 minute, and for the larger ones (500 files/run), the computation should take around 100-115 seconds.
The computed analysis can be accessed via the GlyCulator “My analyses” tab, as described in the “MY ANALYSES” section of the user manual. It can also be accessed programmatically using /analyses/{session_id} request. The execution time for the analysis is only accessible via the API. Downstream analysis of benchmark results should be performed using the “Indices” .csv files or the “indices” dictionary available using the above-mentioned API query. We recommend not removing once completed benchmark runs from the GlyCulator 3.0 to avoid re-running the computation multiple times. Multiple executions of the same list of files on a predefined period will result in the same glycemic variability indices, as all the glycemic variability calculation algorithms are defined as mathematical functions and do not use pseudorandom states. The results from the benchmark runs will be available under the user profile in GlyCulator 3.0 unless explicitly removed by the user. Sharing the analyses will not result in any modification of the original analysis.
For more details or questions regarding implementation with API, you can request access to the code used for the sample benchmarking study via e-mail to biostat@umed.lodz.pl. All files required for the reproducing of the analysis are available at https://glyculator.btm.umed.pl/user_manual in the User manual section.
GlyCulator 3.0 is intended to provide an easy way to quickly integrate, parse and analyze large amounts of CGM data. As a demonstration of the tool’s capabilities we performed a single-center real-life data CGM benchmark. Data was collected from our regional pediatric diabetes care reference center, which treats more than 1400 patients with type 1 diabetes annually (children and adults up to 26 years of age), with data available from 1244 CGMs users. Our goal was to determine what percentage of CGM users satisfied Time in Range (TIR) consensus criteria from 2017 to 2021. Similar to our previous study, we predefined source data for two-week periods from March. We decided to investigate data from March to avoid confounding by any international or national holidays and to avoid any possible influence from seasonal effects. We manually downloaded data from all registered patients in the manufacturer’s software - 4560 CGM files which covered over 900 thousand patient-days. The initial quality assessment was performed with GlyCulator 3.0, once for all 4560 CGM files, and only the files covering the predefined periods were included for the further glycemic variability analysis. This minimized number of redundant data processed at each quality assessment step, improving speed for all subsequent analyses. Next, each set of files (with available data, separate for 288/day and 96/day sampling) was provided for GlyCulator 3.0 to create the new analysis, in ten respective runs. Altogether, 2408 periods from 674 patients were passed for calculation of glycemic variability metrics (Figure 1).
The calculation for the whole group took 380 seconds with average times per analysis step listed in Figure 2.
After the CGM files were trimmed to the chosen dates, inspected for record quality (≥70% CGM active-time) and processed with GlyCulator 3.0, we performed manual analysis of glycemic variability using Excel. First, we removed any duplicate records, defined as originating from the same patient CGM, and covering the same period. Resulting in 2146 periods of CGM data from 674 patients eligible for analysis. We used those to visualize time-in-range from 2017 to 2021 using Python and matplotlib (Figure 3).
Overall, we observed that ~60% of rt-CGM consistently met TIR>70% target, while is-CGM patients’ success rate dropped from ~60 to 40% in 2019 but slowly improved to ~45% in 2020 and 2021 (Figure 4).
We did not directly compare the patients’ outcomes between the two technologies due to the expected presence of multiple confounding factors and differences between rtCGM and isCGM-derived glycemic variability metrics (Michalak et al. Pediatric Diabetes 2019; 10.1111/pedi.12854).
Such results should be interpreted in light of local practice (CGM reimbursement, patient education) and changes in technology. Still, this analysis provided an important insight into the quality of care in the benchmarked center and may help identify areas that need improvement.
Importantly, performing a similar assessment could be done manually by inspecting each patient in the manufacturer’s software or running the raw files through other available software – but such an approach would be much more time-consuming and prone to human error.
All the files used in the analysis were anonymized and were made available on the website, along with a detailed manual to recreate our example analysis. As an additional benefit, we provided a considerable amount of available, real-life CGM data from children and young adults with T1D for reference of independent research.