A Multimodal Type 2 Diabetes Registry on DHIS2: A Design and Feasibility Study with the AI-READI Dataset

T2D REGISTRY ON DHIS2

1

A Multimodal Type 2 Diabetes Registry on DHIS2: A Design and Feasibility Study with the AI-READI Dataset

arXiv:2610.41918v1 [cs.CY] 30 Oct 2026

Saptarshi Purkayastha, Aiswarya Nandan Perumbilly, Zhenan Yin, and Sherri L. Bucher

Abstract—Care for type 2 diabetes increasingly draws on continuous glucose monitors, wearable devices, home sensors, clinical records and retinal images, yet few open platforms have been shown to hold all of these for the same person. We asked three questions of DHIS2, the open-source health information system that ministries of health in about 80 countries run nationally: whether an unmodified Tracker program can represent these modalities together (RQ1), which design choices its row-perevent data model forces for dense sensor streams (RQ2), and what a bulk loader must do to load such data correctly (RQ3). We designed a registry of 27 program stages and 445 data elements, loaded the AI-READI dataset of 2,280 participants into it, and verified the result field by field against the source files. The program held every loaded modality in 8.09 million events. Dense streams were stored as hourly summaries aligned across modalities; electrocardiograms, diagnoses and 118,480 retinal images were stored as one event per record. The event model ruled out storing raw readings, and hourly summaries reduced the wearable and glucose volume about 26-fold. An audit of the loader found defects that shared one pattern: a failure that looked like success. We state five lessons for DHIS2 Tracker clients that address this pattern. Verification of all 64.9 million stored values found four defects, all missing, duplicated or artifactual records rather than wrong values, and none after their repair; an independent recomputation of the glucose summaries agreed on all 464,210 values compared. The paper offers implementation guidance for DHIS2 implementers and for users of AI-READI; it does not evaluate clinical use. Analytics at this scale, use by clinicians and live device feeds remain to be shown.

as the share of time spent between 70 and 180 mg/dL [6]. Wrist-worn devices record heart rate, sleep and activity. Retinal photographs can be graded for diabetic eye disease by software [7] and carry signals about systemic disease [8], and small sensors log the air in a room. Few reports describe a system that holds these streams for the same person over time in a form that clinicians and community health workers can use. DHIS2 (District Health Information Software 2) is an opensource platform that grew out of the Health Information Systems Program, a network that began in South Africa in the 1990s [9]. It was built for aggregate public health reporting and later gained a Tracker module for longitudinal, individual-level records [10]. Ministries of health in about 80 countries run it as their national health information system [11], [12], and Tracker has served as a national pregnancy registry [13], an electronic immunization registry [12] and the record of hypertension and diabetes programs [14], [15]. A platform with this reach is an attractive foundation for a registry that must outlive a single grant [16]. Whether its data model can hold dense sensor data, images and clinical records for thousands of participants, and what it takes to load such data correctly, has not been reported in the peer-reviewed literature (Section II-B). We address three questions.

Index Terms—DHIS2, diabetes registry, continuous glucose monitoring, wearable devices, multimodal data integration, OMOP common data model, retinal imaging, health information systems, data quality.

RQ1 Representation. Can an unmodified DHIS2 Tracker program represent continuous glucose, wearable, indoor environmental, electrocardiogram, diagnostic and retinal imaging data for the same participants alongside the clinical record? RQ2 Granularity and scale. Which design choices does the platform’s row-per-event data model force when the sources are dense sensor streams, and what does the result cost in events and in information? RQ3 Correctness. What must a bulk loader do to put millions of records into such a system correctly through its web interface, and does the loaded registry agree with its source?

I. I NTRODUCTION YPE 2 diabetes affects an estimated 589 million adults worldwide, most of them in low- and middle-income countries [1]. Behavior and environment shape its course alongside care in the clinic [2], and exposure to fine particulate air pollution, indoors as well as outdoors, is one such influence [3]. Many of these influences can now be measured. Continuous glucose monitors improve glucose control in type 2 diabetes [4], are recommended for a growing share of patients [5], and are read through consensus measures such

T

S. Purkayastha, A. Nandan Perumbilly and Z. Yin are with the Department of Biomedical Engineering and Informatics, Luddy School of Informatics, Computing, and Engineering, Indiana University Indianapolis, Indianapolis, IN, USA (corresponding author: S. Purkayastha, e-mail: saptpurk@iu.edu). S. L. Bucher is with the Department of Community and Global Health, Richard M. Fairbanks School of Public Health, Indiana University Indianapolis, Indianapolis, IN, USA.

We answer them in three steps, each applied to the AIREADI dataset [17], [18], a public, access-controlled collection of 2,280 participants across the spectrum of type 2 diabetes. First, we designed a registry data model that maps the modalities onto one Tracker program (RQ1, RQ2). Second, we loaded the dataset through the platform’s web interface and audited the loader, deriving lessons from the defects found (RQ3). Third, we verified the loaded registry against the source

T2D REGISTRY ON DHIS2

2

files, field by field (RQ3). The contributions are a tested Tracker data model for dense consumer-device streams; five lessons for loading data into DHIS2 Tracker correctly; and a verification method with an account of the loaded registry, including a catalog of the data quality of AI-READI as an ingestion pipeline meets it. A preliminary account of the mapping model, covering 23 stages and 152 data elements, was presented as a conference abstract [19]. The pipeline code, program metadata and verification scripts are public1 . II. BACKGROUND A. The DHIS2 Tracker data model A Tracker program enrolls tracked entities, here participants, at an organisation unit such as a clinic or study site. Each tracked entity carries attributes, which are person-level values such as year of birth. An enrollment holds events, each belonging to a program stage; a repeatable stage can hold any number of events per participant, each with its own occurredAt timestamp. Events carry data values, one per data element. Data elements are global objects with a value type and, optionally, an option set, which is a controlled list of permitted values; one element can be attached to several stages. Images are stored as file resources that an image-typed data value points to. Everything is exposed through a web interface, and bulk loading posts records to /api/tracker [10]. Two properties of the model shape the design that follows. First, Tracker is row-oriented: each event is a database row, so the cost of a modality grows with its number of events rather than with the number of readings summarized in each event. Second, an event is identified by its 11-character UID [10]. If the client does not supply one, the server generates it, and the server then has no way to recognize the same event when it is sent again. B. Related work The first body of related work is the use of Tracker for individual-level records. The largest published deployments are in maternal and child health and immunization: South Africa’s MomConnect program registered 1.77 million pregnancies in Tracker by 2017 [13], and 43 countries used Tracker to manage vaccination during the coronavirus pandemic [12]. For non-communicable disease, a Tracker application screened 3,485 older adults for hypertension and diabetes in Vietnam [14], and a standard Tracker package for hypertension and diabetes care is maintained with Resolve to Save Lives [15]. All of these hold records that a health worker enters at an encounter. Device data have reached DHIS2 in one domain, the vaccine cold chain: an OpenFn template imports Fridge-tag temperature loggers into Tracker with readings summarized into daily events [20], which is the same choice of event unit made here at hourly resolution. These integrations monitor equipment; none records data about a person. Images have been placed in Tracker by script, for example from obstetric ultrasound in Guatemala [21]. All of these integrations are 1 https://github.com/iupui-soic/dhis2-diabetes-registry

described in community reports and have not been published in peer-reviewed form. The second is DHIS2 as a research data platform. DHIS2 data are used mostly for planning and performance monitoring [22]. The closest precedent to this work is a wound care research registry that joined 277 patients from six studies to area-level socioeconomic data [16]; it held no sensor or imaging data. The third is the set of platforms that research cohorts use for multimodal data. REDCap is the conventional tool for research data capture [23]; RADAR-base collects data from wearables and phones through streaming storage [24]; and the MIMIC critical care database keeps high-frequency waveforms in a store linked to the relational record [25]. None of these is deployed as a national health information system. For glucose monitors, the iCoDE consensus sets standards for bringing monitoring data into the electronic health record [26], [27]. Integration can range from static reports, through discrete summary statistics such as time in range, to continuous structured data; the hourly summaries of this registry sit between the last two. AI-READI’s own consortium has mapped its survey data into the OMOP common data model [28]. We searched the peer-reviewed literature and the DHIS2 community archives through October 2026 for sensor, imaging or OMOP data held in DHIS2 and for AI-READI loaded into a health information system; the community reports above are the closest precedents. C. The AI-READI dataset AI-READI is a flagship dataset of the Bridge2AI program of the National Institutes of Health [17], enrolling adults aged forty and over at three sites [18]. Release 3.0.0 [29], [30] contains, for 2,280 participants, a Garmin Vivosmart 5 wearable export in the Open mHealth format [31] (heart rate, respiratory rate, blood oxygen saturation, stress, sleep, activity, calories); a Dexcom G6 continuous glucose monitor export; an indoor environmental sensor file at five-second resolution (particulate matter in four size fractions, humidity, temperature, volatile organic compounds, nitrogen oxides); 12-lead electrocardiograms in WFDB format [32]; retinal photography and optical coherence tomography angiography (OCTA) in DICOM [33]; clinical data in the OMOP common data model [34]; and a participant table. The release also holds structural optical coherence tomography and fluorescence lifetime imaging, which were not in the copy available to this project. The public release withholds participant sex, race and ethnicity [29]: no OMOP gender, race or ethnicity concept is set, and the DICOM Patient Sex attribute is a placeholder. Where this paper notes that the registry holds no sex attribute, the attribute is missing because the public release withholds it. The dataset may not be redistributed [35]. III. M ETHODS A. Step 1: Registry design Each participant is one tracked entity, enrolled once in a program named Diabetes Registry at the organisation unit of their recruitment site (Fig. 1). The AI-READI person

T2D REGISTRY ON DHIS2

3

TABLE I P ROGRAM S TAGES OF THE R EGISTRY ON 30 O CTOBER 2026 Stage

Unit of event

Fields

Events

Core (one per participant) Vitals & Measurements Health & Lifestyle Survey Clinical Laboratory & Assessment Medications - Current Device & Sensor Metadata CGM Summary

visit visit visit visit visit visit

9 201 96 10 6 3

2,280 2,280 2,277 2,203 2,154 2,245

Wearable (Garmin Vivosmart 5) Wearable - Heart Rate Wearable - Respiratory Rate Wearable - SpO2 Wearable - Stress Wearable - Activity Wearable - Calories Wearable - Sleep

hour hour hour hour hour hour segment

13 13 13 6 4 4 4

485,951 487,770 73,001 479,077 870,911 325,201 395,999

CGM - Glucose (Dexcom G6)

hour

16

519,617

Environment (indoor sensor) Environment - PM1 Environment - PM2.5 Environment - PM4 Environment - PM10 Environment - Humidity Environment - Temperature Environment - VOC Environment - NOx

hour hour hour hour hour hour hour hour

7 7 7 7 11 7 7 7

538,179 538,179 538,179 538,179 538,179 538,179 538,179 538,169

Cardiac - 12-Lead ECG Diagnosis History (OMOP) Retinal Photography Retinal OCTA

recording condition image acquisition

29 3 11 16

2,257 12,375 93,920 24,560

Archived raw reading stage

reading

3

(unused)

520 slots

8,089,500

Total

Stage names are reproduced as they appear on the server. Fields counts the data elements on each stage; the 520 slots hold 445 distinct data elements because some are shared between stages (Section III-A). CGM is the continuous glucose monitor; SpO2 is blood oxygen saturation; PM1 to PM10 are particulate matter size fractions; VOC is volatile organic compounds; NOx is nitrogen oxides; ECG is electrocardiogram; OCTA is optical coherence tomography angiography.

identifier is the only attribute shared with the source; nine others carry year of birth, diabetes severity group and similar person-level values. Six non-repeatable core stages hold one event per participant: vitals, a lifestyle survey, laboratory results, medications, device metadata and a glucose monitoring summary. The other stages are repeatable (Table I). Event unit. The central design decision is the unit of a sensor event. A Garmin export carries a reading every minute or two per stream, and an environmental file carries about 720 readings per hour per channel. Storing each raw reading as an event was tried first and abandoned; the stage remains in the program, archived and empty. Every dense stream is instead summarized into one event per participant, stage and hour of Coordinated Universal Time (UTC), with the hour start as occurredAt. This bounds the event count while keeping the resolution at which the consensus glucose measures are defined [6], and it places glucose, heart rate and

indoor air for one person in one hour in events with the same timestamp. Heart rate, respiratory rate, blood oxygen and stress hours hold mean, minimum, maximum and reading count. Glucose hours add the standard deviation, the three consensus range percentages [6], [5], counts of the sensor’s out-of-range markers (the strings High and Low that the export writes above 400 or below 40 mg/dL, which are kept in the range denominator), and counts and times of readings above 180 or below 70 mg/dL. Standard deviations are population standard deviations and are left empty for an hour with fewer than two readings, as are the glucose mean, minimum and maximum of an hour that holds only markers; the stored reading count distinguishes these hours from hours without data, which have no event. Activity segments of up to 167 minutes are prorated across hours by time overlap, which preserves totals but smooths bursts of walking. Sleep is kept as segments. Environmental channels keep the sensor’s units, with volatile organic compounds and nitrogen oxides as index points [36]. Shared elements. Generic elements serve several stages: four summary elements on four wearable stages, seven environmental elements on eight stages, and hour start and end on eight stages, so 445 elements fill 520 stage slots. A shared element has one value type and one aggregation type everywhere, so sharing is confined to statistics of the same kind. A shared value is interpretable only together with its stage, and DHIS2 always carries the stage in the reference: a program indicator names a value as #{stage.element} [10]. Time base. The three sites lie in two time zones that observe daylight saving time. Storing UTC aligns modalities exactly and avoids the repeated and skipped hours of local time. The cost is that the Capture application shows UTC clock times and that a DHIS2 calendar day is a UTC day. Local hours remain recoverable without loss, because every event is recorded at its site’s organisation unit and every site is a whole number of hours from UTC. Flags and sufficiency. Where a reference range exists, hourly stages count readings outside it and record their times and a status: heart rate outside 60 to 100 beats per minute, respiratory rate outside 12 to 20, blood oxygen below 95 and 90 percent, humidity outside 30 to 50 percent. These flags mark exceedance of a reference range and should not be read as clinical findings, because resting ranges are exceeded in the ordinary course of a day. Particulate matter carries no hourly flag because its guideline values are 24hour means [37], and the index channels carry none because no concentration guideline applies to them; temperature flag fields were specified but never attached. The electrocardiogram stage classifies heart rate, PR interval and QRS duration. It does not classify the corrected QT interval, whose reference ranges are sex-specific [38]. A Data Sufficiency status marks each heart rate, respiratory rate and oxygen hour as having no valid readings, one or two, or three or more, after removal of device placeholder values (sentinels) and non-finite values. The threshold is a deliberately low project convention, and the stored count is the measure of density. Per-record stages. Electrocardiograms, diagnoses and images map to one event per source record: 29 fields parsed from each electrocardiogram header, including the first three

T2D REGISTRY ON DHIS2

4

Tracked entity (Person) 10 attributes: AI-READI person identifier, year of birth, site, severity group, . . .

Enrollment in the Diabetes Registry program at the organisation unit of the recruitment site (one of three)

Core, non-repeatable one event per participant, dated with the study visit Vitals; survey (201 fields); laboratory (96); medications; device metadata; CGM summary

Per record, repeatable

Hourly, repeatable one event per participant per UTC hour

Per segment, repeatable

Wearable: heart rate, respiration, SpO2, stress, activity, calories; CGM glucose (16 fields); environment: 8 channels

Wearable sleep: stage and duration

one event per sleep segment, at its start

one event per source record

Archived

ECG per recording (29 fields); diagnosis per condition; retinal photograph per image; OCTA per acquisition, each image with a JPEG preview as a file resource

raw sensor reading, one event per reading abandoned at 218 events per second; kept empty

Shared data elements (one element, many stages; read as #{stage.element}): mean, minimum, maximum and reading count on four wearable stages; seven environmental elements on eight stages; hour start and hour end on eight wearable and glucose stages. 445 distinct elements fill 520 stage slots.

Fig. 1. Data model of the registry: one tracked entity per participant, one enrollment at the recruitment site, and 27 program stages grouped by the unit of their events. Counts in parentheses are fields per stage.

machine findings; code, label and date for each OMOP condition; and, for each retinal photograph or OCTA acquisition, the manifest metadata, the DICOM SOP Instance identifier and an 800-pixel JPEG preview held as a file resource. For OCTA the preview is the device’s en-face image of the superficial vascular plexus [39]; full volumes are referenced by path. B. Step 2: Loading Each modality is loaded in two steps (Fig. 2). A first script creates the metadata idempotently. A second script builds events from the source, reconciles them with events already on the server, posts them in sequential verified batches and records the outcome in a checkpoint. The program, with its six interactively configured core stages, is exported from the server as one metadata package so that it can be recreated in a single import. The first version of the loader was audited by an independent information technology reviewer at Indiana University, who graded findings as critical if they could lose data, high if they could leave a stored value or attribute differing from its source, and medium if they could duplicate data. The defects shared one pattern: in each case, a failure could not be told apart from success. The controls that close them are established practice in data engineering and distributed systems [40]. The specific contribution here is to show how each defect arises in a DHIS2 Tracker client, through interface behaviors that are not documented prominently. We therefore state the controls as five lessons for Tracker clients (Table II; the audit findings are listed in Appendix B of the Supplementary Material). Client-assigned identifiers. Every record carries a UID derived by hashing its source identity, and every write uses the create-and-update strategy, so a retry or re-run updates the record instead of duplicating it. Events loaded before identifiers were derived are matched to their source by identity before each write. Writes verified from the response. A tracker import can report success with an error in its body, and its top-level counts sum every object type; the loader reads the

TABLE II L ESSONS FOR DHIS2 T RACKER C LIENTS , THE D EFECT C LASS E ACH C LOSES , AND THE E VIDENCE Lesson

Defect class closed

Client-assigned iden- Retries, resumed runs and retifiers runs duplicate every record; records loaded before client identity existed are duplicated on re-run Writes verified from Success status with failure the response in the body; aggregate statistics that hide a wrong object count; a stage built on a metadata reference that does not exist Checkpoints that A rejected participant record outcomes marked done and skipped forever; an interrupted run truncating its own checkpoint Metadata by name, Hand-pasted identifiers; a options by code stage duplicated on every re-run because its name on the server differed by one character; option values written as display names Type and time Not-a-number stored as the checks at input text nan; hours compared as formatted strings; values cleared or kept by an undocumented update semantics

Evidence Re-run over a participant with 3,798 existing events updated every one and created none

Loader stops with an error on any batch whose per-type created plus updated count differs from the batch size; verification found no source hour without an event (Table III) Checkpoints distinguish done, failed and skipped; failed and skipped work is retried on every run Step 1 scripts re-run without creating objects; pointing the pipeline at another instance fails rather than writing into the wrong stage Finiteness guard on every numeric value; UTC confirmed by diurnal check; merge-on-update verified on a sample of 300 updated events

per-type counts and stops with an error unless they equal the batch size. Checkpoints that record outcomes. A participant is marked done only after a confirmed write, and failed or skipped work is retried. Metadata by name, options by code. Identifiers are resolved from the live program by name, tolerant of dash characters, and option values are written as the server’s codes. Type and time checks at input. Non-finite values are dropped before aggregation, hours are compared as instants, and an update always carries the event’s existing values, because the server’s merge behavior is version-specific.

T2D REGISTRY ON DHIS2

5

existing events of the participant, fetched once per stage

Extract and summarize

AI-READI source manifests, Open mHealth JSON, CSV, WFDB, DICOM, OMOP

UTC hour buckets, missing-value and sentinel filters, DICOM to JPEG

Build events derived identifiers, option codes, finite-value guard

Reconcile match existing events by identity, reuse their identifiers

Write and verify create-and-update strategy, per-type import counts

DHIS2 2.44SNAPSHOT Tracker program, 27 stages, 445 data elements

Metadata registry

Checkpoint

Verification

identifiers resolved by name, cached locally

done / failed / skipped, atomic writes

read-only, every stored field against the source

Fig. 2. Pipeline for one modality. Step 1 scripts populate the metadata registry. Step 2 scripts run the horizontal flow once per participant. Verification reads the registry back against the source files.

C. Step 3: Verification Verification issues only read requests and compares each stored value with the value recomputed from the source. This is the strongest of the methods cataloged for assessing clinical data quality [41] and corresponds to the source data verification used in clinical trials [42]; here it is applied to every participant, every event and every stored field of the 26 stages in use. Hourly values are recomputed with the importer’s own aggregation code, which establishes that the registry holds what that code computed but cannot detect an error in the code itself. The glucose aggregation was therefore also recomputed independently for a random sample of 200 participants: a separately written parser read the raw export, readings were bucketed by hour with pandas, and the metrics were computed with the iglu package [43]. Per-record values are recomputed by code written apart from the importers. Every comparison reports two further counts, registry events with no source counterpart and source records with no event, so that a misalignment cannot be hidden by a perfect match over an empty set of values. A pair that is empty on both sides counts as agreement only where a rule on the source requires it, such as the standard deviation of a single reading or a field the source record does not carry, and such pairs are reported separately. The matching rules are detailed in Appendix C of the Supplementary Material.

D. Evaluation setting The registry runs on one virtual machine with six processor cores and 15 GiB of memory, under a pre-release development build of DHIS2 (2.44-SNAPSHOT) and PostgreSQL 16.9 at its default settings (Appendix A of the Supplementary Material). Every timing reported here was taken on that untuned installation from a single client. Scale was assessed by the event counts of the loaded registry, by a pilot that loaded raw readings as events in an earlier phase [19], by a cohort query issued through the transactional tracker interface, and by one attempt to generate the analytics tables that DHIS2 dashboards and program indicators read [44], [45]. Coverage and sufficiency were computed from read-only queries and from the source files.

IV. R ESULTS A. RQ1: Representation The unmodified Tracker program held every loaded modality for the same participants: 2,280 tracked entities with 10 attributes, 27 stages (26 in use) and 445 data elements, with 8,089,500 events in all (Table I). Repeatable stages carried up to 870,911 events each; option sets enforced controlled vocabularies; and file resources held 118,440 previews for 118,480 images, the 40 without one being OCTA acquisitions whose source has no superficial-plexus image. The Capture application displayed every stage and value without custom code (Fig. 3). For a dense stream, however, display falls short of use: the default enrollment dashboard lists a stage’s events by date alone, without the hour or any value, five at a time, so a participant’s several hundred hourly events offer no practical view of the stream. B. RQ2: Granularity and scale Loading raw readings as events ran at about 218 events per second in the pilot, which extrapolates to five to six days for the roughly 100 million raw readings of the cohort. Hourly summaries reduced the wearable and glucose volume about 26-fold, to 3.8 million events that imported in under 45 minutes. The completed registry holds about 3,500 events per participant; the eight environmental stages are the largest component, at 4.31 million events. Through the transactional interface, assembling a cohort of 2,205 participants with a retinal preview and at least seven days of glucose took 184 seconds, as two requests per participant at about 40 ms each. Analytics table generation built the tracked-entity analytics tables, including one of every event in the registry, in about 15 minutes. It then failed while preparing the event analytics table, reporting one failed item but no cause through the interface, so the analytics interface could not be measured. Coverage and sufficiency. Over 99 percent of heart rate and respiratory rate hours and 89.5 percent of oxygen hours met the sufficiency threshold (Table IV). The median hour held 45 to 53 readings, however, so the reading count is the more informative measure. Three quarters of the cohort (1,709 of 2,280) yielded at least seven days of glucose, wearable and environmental data together without contact from a health worker. Most participants (85 percent) wore the glucose sensor

T2D REGISTRY ON DHIS2

6

(a)

(b)

Fig. 3. One participant’s record in the unmodified Capture application. (a) The enrollment dashboard lists each stage’s events by date alone, five at a time, without the hour or any value; the archived raw-reading stage is empty. (b) A retinal photography event with its manifest fields and its JPEG preview, held as a file resource. Dates, per-participant event counts, the DICOM identifier and the file path are masked, and the preview is pixelated. TABLE III V ERIFICATION OF E VERY S TORED F IELD AGAINST THE S OURCE F ILES A FTER R EPAIR , BY S TAGE , 30 O CTOBER 2026

Stage

Fields

Events

Values compared

Hourly and segment stages, recomputed with the importer’s aggregation code CGM - Glucose 16/16 519,617 8,313,872 Wearable - Heart Rate 13/13 485,951 6,317,363 Wearable - Respiratory Rate 13/13 487,770 6,341,010 Wearable - SpO2 13/13 73,001 949,013 Wearable - Stress 6/6 479,077 2,874,462 Wearable - Activity 4/4 870,911 3,483,644 Wearable - Calories 4/4 325,201 1,300,804 Wearable - Sleep (segments) 4/4 395,999 1,583,996 Environment - Humidity 11/11 538,179 5,919,969 Environment - 7 other channels 7/7 3,767,243 26,370,701 Per-record stages, recomputed by separately written code Diagnosis History 3/3 12,375 24,750 Retinal Photography 11/11 93,920 939,200 Retinal OCTA 16/16 24,560 368,400 Cardiac - 12-Lead ECG 29/29 2,257 63,196 All 20 stages CGM - Glucose, recomputed with iglu (200 participants) Six core stages (earlier phase, separate script)

Matched

Empty, MisNo No expected matched source event

7,365,732 5,633,805 5,538,665 912,155 2,874,462 3,483,644 1,300,804 1,583,996 5,023,521 26,370,629

948,140 683,558 802,345 36,858 0 0 0 0 896,448 72

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

24,750 939,200 368,360 58,767

0 0 40 4,429

0 0 0 0

0 0 0 0

0 0 0 0

8,076,061

64,850,380

61,478,490

3,371,890

0

0

0

46,421 13,439

464,210 82,302

463,487 82,302

723

0 0

0

0

10/16 all

Every participant and every event of each stage was compared. Fields gives the fields compared out of those the stage stores; a field used to match an event to its source record (header path, SOP Instance identifier, condition code, sleep start) is counted as compared, because a wrong value leaves the event unmatched. Empty, expected counts pairs empty on both sides where a rule on the source requires it (Section III-C); most are lists of flagged times for hours in which no reading was flagged. No source counts registry events with no counterpart in the source; no event counts source hours or records with no registry event. Values are compared with a tolerance of 0.01. The run followed the four repairs described in the text. The iglu and core-stage rows use other methods and are not part of the totals.

for 11 days, and only 2 wore it for 14 days or more, which is short of the 14 days the consensus recommends [6], [46]. The exceedance flags fired in most hours: a heart rate reading outside the resting range occurred in 58.5 percent of hours and an oxygen reading below 95 percent in 95.2 percent. Counting days in site-local rather than UTC dates changed the number of days with glucose data for 191 of 2,245 participants and changed the seven-day classification for 5. As an example of a

program-level count, glucose hours with less than 70 percent of readings in range made up 18.9, 13.5 and 13.2 percent of hours at the three sites; the count was obtained with six filtered tracker requests in 27 seconds. C. RQ3: Correctness Verification compared every stored field of every event in the 20 non-core stages with the source, 64,850,380 values in all

T2D REGISTRY ON DHIS2

7

TABLE IV D EVICE C OVERAGE AND DATA S UFFICIENCY IN THE L OADED R EGISTRY, 12 O CTOBER 2026 Measure

Value

Hourly summaries with Data Sufficiency = sufficient Heart rate (485,951 hours) Respiratory rate (487,770 hours) Blood oxygen saturation (73,001 hours)

99.4% 99.1% 89.5%

Valid readings per hourly summary, median (IQR) Heart rate Respiratory rate Blood oxygen saturation

45 (36 to 52) 53 (41 to 59) 51 (28 to 59)

Hours with a reading outside the reference range Heart rate, outside 60 to 100 Respiratory rate, outside 12 to 20 Blood oxygen saturation, below 95 Blood oxygen saturation, below 90

58.5% 35.1% 95.2% 68.9%

Glucose monitoring (2,245 participants) Sensor wear of 11 days Sensor wear of 10 days Sensor wear of 9 days or fewer Sensor wear of 12 days or more (14 or more: 2) Participants with ≥7 days Participants above 70% hourly completeness

85.3% 8.4% 5.8% 0.5% 98.3% 98.9%

Wearable heart rate (1,999 participants) Hours with a summary, median (IQR) Days with a summary, median (IQR)

251 (235 to 265) 12 (12 to 13)

Indoor environmental sensor (2,154 participants) Duration, median (IQR) days Participants with ≥7 days

10.5 (9.7 to 11.0) 91.6%

Participants with ≥7 days on all three streams

1,709 of 2,280 (75.0%)

Sufficiency is the project definition of Section III-A: three or more valid readings in the hour. Readings per hour are counted from the source files after the import’s filters, over the same hours as the stored summaries. Completeness is hours with a glucose summary divided by hours in the span from first to last glucose day. Hours and days with a heart rate summary are counted per participant over the whole wear period, and days are UTC calendar days (Section III-A). IQR is the interquartile range.

(Table III). Every value agreed within the tolerance of 0.01, no registry event lacked a source counterpart, and no source hour or record lacked an event. Of the agreements, 3,371,890 were pairs empty on both sides where a rule on the source requires it. Most were lists of flagged times for hours in which no reading was flagged. The rest were statistics that the source leaves undefined, such as the standard deviation of an hour with a single reading or the mean of a glucose hour holding only markers; the 40 OCTA acquisitions whose source has no superficial-plexus image; and 4,429 electrocardiogram header fields that the recording does not carry. This result followed four repairs, each of a defect that only exhaustive, field-level verification revealed (Appendix C of the Supplementary Material): a duplicated electrocardiogram event, 2,229 photographs without previews, 169,969 sleep events produced by segments that the export repeats verbatim or that end before they start, and 129,916 humidity hours whose list of flagged times had not been stored. None was a stored value that differed from its source. Each was a record missing, doubled or carried over from an artifact of the source,

the kind of failure that the earlier sampled and count-only checks had not seen. A further 44,616 humidity lists of more than 20 flagged times had been stored in full by a load that predates the 20-entry cap; they agree with the source and were left as they are. The independent recomputation of glucose covered 46,421 hours, with every hour matched on both sides. All 464,210 values agreed, and the stored pstandard deviation differed from iglu’s only by the divisor, (n − 1)/n. Loading also surfaced properties of the source that any consumer of AI-READI should expect (Table V), classified by the harmonized data quality framework [47]. The catalog complements the release’s own run of the OHDSI Data Quality Dashboard [48] on its OMOP tables, which failed 49 of 1,241 checks. The phenomena that matter most for an ingestion layer are device placeholder values and non-finite numbers in the wearable exports, glucose markers that carry information and should not be discarded as noise, vendor-specific DICOM encodings, and sleep segments repeated verbatim in the export, which overstate summed sleep time by 43 percent for any consumer that does not remove them. V. D ISCUSSION A. Principal findings RQ1. An unmodified Tracker program can hold continuous glucose, wearable, environmental, electrocardiogram, diagnostic and imaging data for the same participants. By default, however, it provides no way to read a dense stream: the Capture application displays the events without summarizing them, so a usable view needs configured list columns, event reports or analytics. RQ2. The row-per-event model forces a choice of event unit, and at consumer-device density that unit cannot be the raw reading. The hourly summary makes the registry loadable, keeps the consensus glucose measures natural and aligns modalities on one clock. Its costs are the loss of the raw signal and, at this scale, dependence on analytics generation, which failed for the event table on this build. RQ3. The audited defects concerned the handling of failure; none was an error of arithmetic. Five controls specific to Tracker clients closed them. Exhaustive verification then found the remaining defects, which were defects of completeness that sampling and count-only checks had missed. Where a stage is small enough to check in full, it should be checked in full, and a check that shares the loader’s code needs an independent counterpart. B. Relation to prior work As far as we can establish, this is the first report in the peerreviewed literature of person-level physiological and environmental sensor streams held in DHIS2 Tracker. Device data have reached DHIS2 for cold-chain equipment, and images have been loaded into Tracker by script, both in community reports. The AI-READI consortium has mapped parts of the dataset into OMOP [28], so the claim for AI-READI is only that this is its first loading into a health information system. At 8.09 million events the registry is large for research use of the platform and modest beside national production instances. Its

T2D REGISTRY ON DHIS2

8

TABLE V DATA Q UALITY P HENOMENA OF THE S OURCE , C LASSIFIED BY THE H ARMONIZED F RAMEWORK [47] Phenomenon

Dimension

Handling

Not-a-number values in the blood oxygen export (77 of 93 files sampled) Negative marker values in respiratory rate and stress (about half of readings); zero fill in heart rate Glucose readings outside the sensor range exported as High and Low (13 of 60 files sampled) Nitrogen oxide coverage varies by participant; one has no usable value condition_source_value truncated at 49 characters (3,388 of 12,375 rows) Directory tree nests each modality one level deeper than the manifest paths imply No visit date in the registry master file

Completeness

Dropped before aggregation; finiteness guard on every value

Plausibility

Dropped before aggregation

Conformance (value type)

Counted as markers; excluded from numeric statistics, included in the time-in-range denominator Hour omitted when the channel has no value; the stage is ten events short Imported as is and documented

Completeness

Conformance (value) Conformance (structure)

Path resolver accepts both layouts

Completeness

Dates taken from the participant table; a record with no date is skipped, and no date is imputed Join refused on ambiguous rows; new imports set the identifier directly Confirmed UTC by diurnal check; all timestamps UTC Decoders declared; color space converted; 42,054 previews regenerated Rejected by the first decoder, leaving no preview; found by verification, decoded with OpenJPEG, 2,229 previews regenerated Exact repeats dropped by the loader; repeats already loaded deleted

Six demographic attributes iden- Plausibility tify only 1,418 of 2,280 partici- (uniqueness) pants uniquely Time zone not stated in any export Conformance (temporal) Vendor-specific DICOM transfer Conformance syntax and YBR color space (encoding) JPEG 2000 pixel data wrapped in a JP2 file header, which DICOM does not permit (2,229 of 4,506 infrared images from one camera model) Sleep segments repeated verbatim in the wearable export (169,960 of 565,959, in 1,567 of 2,184 participants), overstating summed sleep time by 43% Sleep segments that end before they start (9) VOC index of 0 at sensor start-up, outside the documented 1 to 500 (0.009% of readings) Humidity documented as 0 to 1 but recorded in percent Superficial plexus en-face image reported as absent (40 of 24,560 angiography acquisitions) Sex, race and ethnicity withheld from the public release; DICOM Patient Sex set to M in every file examined

Conformance (encoding)

Plausibility (uniqueness)

Plausibility (temporal) Plausibility

Dropped; events from an early load deleted Kept; the effect is negligible

Conformance (value) Completeness

Stored in percent, thresholds in percent Loaded without a preview

Completeness; plausibility

Not loaded; corrected QT interval not classified

reusable parts are implementation guidance: the data model, the loading lessons and the data quality catalog. C. Implications for diabetes care The registry places the consensus glucose measures [6], [5] in the same record as diagnoses, medications, laboratory results, indoor air, retinal images and electrocardiograms. Continuous glucose monitoring helps only if someone reviews the data [4]. In a DHIS2 deployment that reviewer can be a community health worker, whose interventions lower glycated hemoglobin in pooled trials [49], provided the data are presented in a form they can read. Indoor exposure aligned hourly with glucose makes within-person exposure-response

analysis possible [3]; retinal previews support screening in the same program [7], [8]; and the electrocardiogram stage could classify the corrected QT interval, a predictor of mortality in type 2 diabetes [50], once sex is recorded. The argument that a registry on the platform a ministry already runs is affordable [11] holds for the server tier. It does not hold for the devices, which are costly and little available in most low- and middle-income countries, and a separate research or program instance is a more realistic home for millions of sensor events than a production one. None of this has been shown to change a clinical outcome. D. From a loaded registry to a live platform Hourly summaries are too coarse for decision support that forecasts glucose from five-minute readings [51], so a live deployment would be tiered: raw readings in a store built for them [24], summaries in Tracker, and alerts as events where health workers see them. This is the arrangement MIMIC uses for waveforms [25]. The tiers this work does not demonstrate are a patient-facing application, live device integration, interoperability through FHIR [52] or OMOP, validation rules and decision support. DHIS2 can now generate FHIR implementation guides from Tracker metadata [53], and standard diabetes and hypertension Tracker modules are being built for national programs [54]; aligning the core stages with them is the most direct route to adoption. The loading lessons are prerequisites for any continuous ingestion, because a streaming integration retries by nature. E. Limitations Several limitations concern the source data, the hourly model, the test environment and clinical readiness. Structural OCT and fluorescence lifetime imaging were not loaded, and the public release withholds sex, race and ethnicity. Within the hourly model, aggregation was checked independently only for glucose, activity proration smooths bursts within long segments, and storing timestamps in UTC displays UTC clock times in the Capture application. On the systems side, the server ran a pre-release build at default database settings, so its behaviors, including the analytics failure, should be confirmed on a released and tuned installation; per-modality load times were not recorded, loader throughput comes from a pilot, and the exported metadata package has been checked for completeness but not yet imported into a clean instance. Finally, the coverage figures describe research volunteers over about ten days, with glucose wear falling short of the 14 days the consensus recommends [6]; the reference-range flags fire in most hours and are not yet useful for review, and no clinician or health worker has used the registry. VI. C ONCLUSION An unmodified DHIS2 Tracker program held a multimodal type 2 diabetes registry of 2,280 participants and 8.09 million events loaded from AI-READI (RQ1). Its row-per-event model forced hourly summaries as the unit of sensor data. This made the registry loadable and aligned its modalities, but it leaves

T2D REGISTRY ON DHIS2

9

the raw signal to a separate tier and makes analytics generation the step that remains to be proven at scale (RQ2). Five lessons for Tracker clients made failed writes visible, and fieldby-field verification against the source, with an independent recomputation of glucose, showed what the registry holds and found what earlier checks had missed (RQ3). Mobile capture, live device feeds, interoperability and decision support remain to be built before the registry could support care. D ECLARATIONS Ethics. The study used only the de-identified public tier of the AI-READI dataset, under the data use agreement and license of the AI-READI Consortium [35]; no further institutional review was sought. Every person with an account on the registry server holds AI-READI data access permission. Funding. This work received no specific funding and was carried out independently of the AI-READI Consortium. Competing interests. The authors declare no competing interests. Data availability. The AI-READI dataset is available from FAIRhub under its data use license [29]; the license does not permit redistribution, so the loaded registry cannot be shared. Aggregate results reported here are in the code repository. Code availability. The pipeline, the exported program metadata and the verification scripts are available at https://github. com/iupui-soic/dhis2-diabetes-registry. Supplementary material. Appendices A to D (evaluation environment, interface behaviors and audit findings, verification details, and implementation notes) are provided as a separate document. ACKNOWLEDGMENT The data used here are version 3.0.0 of the Flagship Dataset of Type 2 Diabetes from the AI-READI Project, which was produced by the AI-READI Consortium with support from the National Institutes of Health Bridge2AI Common Fund program under award OT2OD032644. The dataset was accessed under the AI-READI data use license, version 2.0, which limits use to research on type 2 diabetes and prohibits redistribution of the data. In keeping with that license, no participant-level values appear in this paper, and the accompanying code repository contains no data and no notebook output. The pipeline code, the metadata it creates and the verification scripts are available at https://github.com/iupuisoic/dhis2-diabetes-registry. The authors thank the AI-READI Consortium for making the dataset available, and the DHIS2 core team and community at the University of Oslo for the platform on which the registry is built. R EFERENCES [1] I. Genitsaridi, P. Salpea, A. Salim, S. F. Sajjadi, D. Tomic, S. James et al., “11th edition of the IDF Diabetes Atlas: Global, regional, and national diabetes prevalence estimates for 2024 and projections for 2050,” Lancet Diabetes Endocrinol., vol. 14, no. 2, pp. 149–156, 2026. [2] F. Hill-Briggs, N. E. Adler, S. A. Berkowitz, M. H. Chin, T. L. Gary-Webb, A. Navas-Acien et al., “Social determinants of health and diabetes: A scientific review,” Diabetes Care, vol. 44, no. 1, pp. 258– 279, 2021.

[3] B.-Y. Yang, S. Fan, E. Thiering, J. Seissler, D. Nowak, G.-H. Dong et al., “Ambient air pollution and diabetes: A systematic review and meta-analysis,” Environ. Res., vol. 180, p. 108817, 2020. [4] M. Jancev, T. A. C. M. Vissers, F. L. J. Visseren, A. C. van Bon, E. H. Serné, J. H. DeVries et al., “Continuous glucose monitoring in adults with type 2 diabetes: A systematic review and meta-analysis,” Diabetologia, vol. 67, no. 5, pp. 798–810, 2024. [5] American Diabetes Association Professional Practice Committee, “7. Diabetes technology: Standards of Care in Diabetes 2026,” Diabetes Care, vol. 49, no. Suppl. 1, pp. S150–S165, 2026. [6] T. Battelino, T. Danne, R. M. Bergenstal, S. A. Amiel, R. Beck, T. Biester et al., “Clinical targets for continuous glucose monitoring data interpretation: Recommendations from the International Consensus on Time in Range,” Diabetes Care, vol. 42, no. 8, pp. 1593–1603, 2019. [7] V. Gulshan, L. Peng, M. Coram, M. C. Stumpe, D. Wu, A. Narayanaswamy et al., “Development and validation of a deep learning algorithm for detection of diabetic retinopathy in retinal fundus photographs,” JAMA, vol. 316, no. 22, pp. 2402–2410, 2016. [8] S. K. Wagner, D. J. Fu, L. Faes, X. Liu, J. Huemer, H. Khalid et al., “Insights into systemic disease through retinal imaging-based oculomics,” Transl. Vis. Sci. Technol., vol. 9, no. 2, p. 6, 2020. [9] J. Braa, E. Monteiro, and S. Sahay, “Networks of action: Sustainable health information systems across developing countries,” MIS Quart., vol. 28, no. 3, pp. 337–362, 2004. [10] DHIS2 Core Team, “DHIS2 developer documentation: Tracker web API,” University of Oslo, accessed: Oct. 12, 2026. [Online]. Available: https://docs.dhis2.org [11] DHIS2, “DHIS2 in action,” HISP Centre, University of Oslo, accessed: Oct. 12, 2026. [Online]. Available: https://dhis2.org/in-action/ [12] E. Carnahan, L. Nguyen, S. Dao, M. Bwakya, H. Mtenga, H. T. Duong et al., “Design, development, and deployment of an electronic immunization registry: Experiences from Vietnam, Tanzania, and Zambia,” Glob. Health Sci. Pract., vol. 11, no. 1, p. e2100804, 2023. [13] C. Seebregts, P. Dane, A. N. Parsons, T. Fogwill, D. Rogers, M. Bekker et al., “Designing for scale: Optimising the health information system architecture for mobile maternal health messaging in South Africa (MomConnect),” BMJ Glob. Health, vol. 3, no. Suppl. 2, p. e000563, 2018. [14] T. T. T. Nong, G. H. Nguyen, A. Lepe, T. B. Tran, L. T. P. Nguyen, and J. A. R. Koot, “Challenges and opportunities in digital screening for hypertension and diabetes among community groups of older adults in Vietnam: Mixed methods study,” J. Med. Internet Res., vol. 26, p. e54127, 2024. [15] Resolve to Save Lives and DHIS2, “DHIS2 for hypertension and diabetes programs,” 2024, accessed: Oct. 12, 2026. [Online]. Available: https://resolvetosavelives.org/resources/factsheet-for-dhis2for-hypertension-diabetes-programs/ [16] A. R. Paddo, S. Kodela, L. Timsina, S. S. Mathew-Steiner, S. Purkayastha, and C. K. Sen, “Development and validation of the DHIS2 platform for integrating sociomedical data to study wound care outcomes,” PLOS ONE, vol. 19, no. 12, p. e0308553, 2024. [17] AI-READI Consortium, “AI-READI: Rethinking AI data collection, preparation and sharing in diabetes research and beyond,” Nat. Metab., vol. 6, no. 12, pp. 2210–2212, 2024. [18] C. Owsley, D. S. Matthies, G. McGwin, J. C. Edberg, S. L. Baxter, L. M. Zangwill et al., “Cross-sectional design and protocol for Artificial Intelligence Ready and Equitable Atlas for Diabetes Insights (AIREADI),” BMJ Open, vol. 15, no. 2, p. e097449, 2025. [19] A. N. Perumbilly, Z. Yin, S. Bucher, and S. Purkayastha, “A metadatadriven ETL and mapping model for a multimodal diabetes registry in DHIS2,” in Proc. IEEE-EMBS Int. Conf. Biomedical and Health Informatics (BHI), 2026, accepted abstract. [20] A. Krolls, “Sync Fridge-tag reports to DHIS2 tracker for cold chain equipment: New OpenFn template,” DHIS2 Community of Practice, Aug. 2025, posted 7 August 2025, https://community.dhis2.org/t/sync-fridge-tag-reports-to-dhis2-trackerfor-cold-chain-equipment-new-openfn-template/67144, accessed 30 October 2026. [21] “Information system based on DHIS2 for monitoring pregnant women in Guatemala,” DHIS2 Annual Conference 2022 abstract, DHIS2 Community of Practice, Jun. 2022, posted 2 June 2022, https://community.dhis2.org/t/information-system-based-on-dhis2-formonitoring-pregnant-women-in-guatemala/47564, accessed 30 October 2026. [22] R. Dehnavieh, A. Haghdoost, A. Khosravi, F. Hoseinabadi, H. Rahimi, A. Poursheikhali et al., “The District Health Information System (DHIS2): A literature review and meta-synthesis of its strengths and

T2D REGISTRY ON DHIS2

operational challenges based on the experiences of 11 countries,” Health Inf. Manag. J., vol. 48, no. 2, pp. 62–75, 2019. [23] P. A. Harris, R. Taylor, R. Thielke, J. Payne, N. Gonzalez, and J. G. Conde, “Research electronic data capture (REDCap): A metadata-driven methodology and workflow process for providing translational research informatics support,” J. Biomed. Inform., vol. 42, no. 2, pp. 377–381, 2009. [24] Y. Ranjan, Z. Rashid, C. Stewart, P. Conde, M. Begale, D. Verbeeck et al., “RADAR-Base: Open source mobile health platform for collecting, monitoring, and analyzing data using sensors, wearables, and mobile devices,” JMIR mHealth uHealth, vol. 7, no. 8, p. e11734, 2019. [25] A. E. W. Johnson, T. J. Pollard, L. Shen, L. H. Lehman, M. Feng, M. Ghassemi et al., “MIMIC-III, a freely accessible critical care database,” Sci. Data, vol. 3, p. 160035, 2016. [26] J. C. Espinoza, D. C. Klonoff, A. P. Vidmar, M. Tut, S. Corathers, R. Seigel, A. M. Yeung, N. Y. Xu, P. Shah, M. Babaei, J. Huang, K. T. Nguyen, J. Goldman, and S. Shah, “2022 iCoDE report: CGM-EHR integration standards and recommendations,” Diabetes Technology Society, Version 1.0, Nov. 2022, https://www.diabetestechnology.org/icode/, accessed 30 October 2026. [27] N. Y. Xu, K. T. Nguyen, A. Y. DuBord, D. C. Klonoff, J. M. Goldman, S. N. Shah et al., “The launch of the iCoDE standard project,” Journal of Diabetes Science and Technology, vol. 16, no. 4, pp. 887–895, 2022. [28] S. S. Hong, J. Cavallon, Y.-J. Chen, M. Bangudi, J. Mitchell, D. Matthies, S. Chamberlin, A. Cohen, J. Owens, A. Lucero, S. Baxter, C. G. Chute, C. S. Lee, A. Lee, and AI-READI Consortium, “Streamlining research data standardization: AI-READI survey instrument data elements and MoCA measurement data elements are curated and mapped utilizing a standardized value set mapping table for transformation into the OMOP common data model,” OHDSI Global Symposium 2024, Collaborator Showcase, poster 12, Oct. 2024, https://ohdsi.org/wp-content/uploads/2024/10/12-hongstephanie_briefReport_StreamliningResearchDataStandardization_ 2024symposiumFinal-Stephanie-S-Hong.pdf, accessed 30 October 2026. [29] AI-READI Consortium, “Flagship dataset of type 2 diabetes from the AI-READI project (3.0.0) [data set],” FAIRhub, Nov. 2025, https://doi. org/10.60775/fairhub.3. [30] ——, “Documentation for the AI-READI dataset, version 3.0.0,” docs.aireadi.org, Nov. 2025, https://docs.aireadi.org/docs/3/, accessed 30 October 2026. [31] D. Estrin and I. Sim, “Open mHealth architecture: An engine for health care innovation,” Science, vol. 330, no. 6005, pp. 759–760, 2010. [32] A. L. Goldberger, L. A. N. Amaral, L. Glass, J. M. Hausdorff, P. C. Ivanov, R. G. Mark et al., “PhysioBank, PhysioToolkit, and PhysioNet: Components of a new research resource for complex physiologic signals,” Circulation, vol. 101, no. 23, pp. e215–e220, 2000. [33] National Electrical Manufacturers Association, Digital Imaging and Communications in Medicine (DICOM) Standard, PS3, NEMA Std., accessed: Oct. 12, 2026. [Online]. Available: https://www. dicomstandard.org [34] G. Hripcsak, J. D. Duke, N. H. Shah, C. G. Reich, V. Huser, M. J. Schuemie et al., “Observational Health Data Sciences and Informatics (OHDSI): Opportunities for observational researchers,” Stud. Health Technol. Inform., vol. 216, pp. 574–578, 2015. [35] AI-READI Consortium, “AI-READI data license, version 2.0,” Zenodo, Nov. 2025, https://doi.org/10.5281/zenodo.17555036. [36] Sensirion AG, “Datasheet SEN5x: Environmental sensor node for HVAC and air quality applications, version 2,” Sensirion AG, Stäfa, Switzerland, Mar. 2022, https://sensirion.com/media/documents/6791EFA0/ 62A1F68F/Sensirion_Datasheet_Environmental_Node_SEN5x.pdf, accessed 30 October 2026. [37] World Health Organization, WHO Global Air Quality Guidelines: Particulate Matter (PM2.5 and PM10), Ozone, Nitrogen Dioxide, Sulfur Dioxide and Carbon Monoxide. Geneva, Switzerland: World Health Organization, 2021. [38] P. M. Rautaharju, B. Surawicz, and L. S. Gettes, “AHA/ACCF/HRS recommendations for the standardization and interpretation of the electrocardiogram: Part IV: The ST segment, T and U waves, and the QT interval,” Circulation, vol. 119, no. 10, pp. e241–e250, 2009. [39] Z. Sun, D. Yang, Z. Tang, D. S. Ng, and C. Y. Cheung, “Optical coherence tomography angiography in diabetic retinopathy: An updated review,” Eye, vol. 35, no. 1, pp. 149–161, 2021. [40] D. Yuan, Y. Luo, X. Zhuang, G. R. Rodrigues, X. Zhao, Y. Zhang et al., “Simple testing can prevent most critical failures: An analysis of production failures in distributed data-intensive systems,” in Proc. 11th

10

USENIX Symp. Operating Systems Design and Implementation (OSDI), Broomfield, CO, USA, 2014, pp. 249–265. [41] N. G. Weiskopf and C. Weng, “Methods and dimensions of electronic health record data quality assessment: Enabling reuse for clinical research,” J. Am. Med. Inform. Assoc., vol. 20, no. 1, pp. 144–151, 2013. [42] C. Tudur Smith, D. D. Stocken, J. Dunn, T. Cox, P. Ghaneh, D. Cunningham et al., “The value of source data verification in a cancer clinical trial,” PLOS ONE, vol. 7, no. 12, p. e51623, 2012. [43] S. Broll, J. Urbanek, D. Buchanan, E. Chun, J. Muschelli, N. M. Punjabi, and I. Gaynanova, “Interpreting blood glucose data with R package iglu,” PLoS One, vol. 16, no. 4, p. e0248560, 2021. [44] DHIS2, “Data administration: Analytics tables management,” DHIS2 Documentation, User Guide, DHIS core version 2.43, Aug. 2025, https://docs.dhis2.org/en/use/user-guides/dhis-core-version243/maintaining-the-system/data-administration.html, accessed 30 October 2026. [45] ——, “Tracker performance at scale,” DHIS2 Documentation, Implementation Guide, Tracker implementation, Jul. 2025, last updated 10 July 2025, https://docs.dhis2.org/en/implement/tracker-implementation/ tracker-performance-at-scale.html, accessed 30 October 2026. [46] N. Kok, W. T. Williamson, J. M. Lee, and I. Gaynanova, “Impact of missing data and monitoring duration on downstream analyses in continuous glucose monitoring,” Diabetes Care, vol. 49, no. 6, pp. 1031– 1039, 2026. [47] M. G. Kahn, T. J. Callahan, J. Barnard, A. E. Bauck, J. Brown, B. N. Davidson et al., “A harmonized data quality assessment terminology and framework for the secondary use of electronic health record data,” eGEMs, vol. 4, no. 1, p. 1244, 2016. [48] C. Blacketer, F. J. Defalco, P. B. Ryan, and P. R. Rijnbeek, “Increasing trust in real-world evidence through evaluation of observational data quality,” Journal of the American Medical Informatics Association, vol. 28, no. 10, pp. 2251–2257, 2021. [49] J. Evans, H. Ha, and P. T. White, “Evaluating the effectiveness of community health worker interventions on glycaemic control in type 2 diabetes mellitus: A systematic review and meta-analysis,” BMJ Open, vol. 15, no. 7, p. e096651, 2025. [50] A. J. Cox, A. Azeem, J. Yeboah, E. Z. Soliman, S. R. Aggarwal, A. G. Bertoni et al., “Heart rate-corrected QT interval is an independent predictor of all-cause and cardiovascular mortality in individuals with type 2 diabetes: The Diabetes Heart Study,” Diabetes Care, vol. 37, no. 5, pp. 1454–1461, 2014. [51] K. Liu, L. Li, Y. Ma, J. Jiang, Z. Liu, Z. Ye et al., “Machine learning models for blood glucose level prediction in patients with diabetes mellitus: Systematic review and network meta-analysis,” JMIR Med. Inform., vol. 11, p. e47833, 2023. [52] S. Abedian, E. Yesakov, S. Ostrovskiy, and R. Hussein, “Streamlining wearable data integration for EHDS: A case study on advancing healthcare interoperability using Garmin devices and FHIR,” Front. Digit. Health, vol. 7, p. 1636775, 2025. [53] DHIS2, “FHIR IG generator: DHIS2 implementation guide generator app,” DHIS2 App Hub and GitHub repository dhis2/fhir-ig-generatorapp, Oct. 2026, version 1.4.3, https://github.com/dhis2/fhir-ig-generatorapp, accessed 30 October 2026. [54] HISP Centre, University of Oslo, “HISP centre and World Diabetes Foundation partner to strengthen digital tools for NCDs,” dhis2.org news, Aug. 2025, 14 August 2025, https://dhis2.org/hisp-centre-worlddiabetes-foundation-partnership/, accessed 30 October 2026.

T2D REGISTRY ON DHIS2

Saptarshi Purkayastha is an Associate Professor and Program Director of Health Informatics in the Department of Biomedical Engineering and Informatics at the Luddy School of Informatics, Computing, and Engineering, Indiana University Indianapolis, where he leads the Purkayastha Lab for Health Innovation. His research concerns electronic health record systems, including DHIS2 and OpenMRS, clinical decision support systems, and the integration of digital health data for population health. Aiswarya Nandan Perumbilly is a graduate student in the Master of Science in Health Informatics program at the Luddy School of Informatics, Computing, and Engineering, Indiana University Indianapolis, and a graduate research assistant in the Purkayastha Lab for Health Innovation. Her work concerns the configuration of DHIS2 Tracker programs and the loading and verification of multimodal health data. Zhenan Yin is a Ph.D. student in Biomedical and Health Informatics at the Luddy School of Informatics, Computing, and Engineering, Indiana University Indianapolis, and a graduate research assistant in the Purkayastha Lab for Health Innovation. He received the B.S. degree in electrical engineering from the University of California, San Diego, and worked for five years as a healthcare information technology project manager before beginning doctoral study. His research interests include multimodal learning, medical image analysis, clinical data mining and clinical artificial intelligence. Sherri L. Bucher is an Associate Professor and Chair of the Department of Community and Global Health at the Richard M. Fairbanks School of Public Health, Indiana University Indianapolis, with an adjunct appointment in Pediatrics at the Indiana University School of Medicine. She received the Ph.D. degree in child and developmental psychology from the University of Connecticut. Her research concerns maternal, newborn and child health, implementation science and digital health in resource-limited settings, including the mobile Helping Babies Survive platform built on DHIS2, and she received the 2024 Bantz-Petronio Translating Research into Practice Award.

11

Related documents

• A Multimodal Type 2 Diabetes Registry on DHIS2: A Design and Feasibility Study with the AI-READI Dataset#1535236
• A Study for Participants With Type 2 Diabetes Mellitus#249551
• Glucose Response in Persons with Type 2 Diabetes#906725
• Continuous Glucose Monitoring & Management In Type 2 Diabetes (T2D)#1376356
• A Study for Patients With Type 2 Diabetes Mellitus#148710