FDA CGM Data Submission: Tracing Sensor Epochs to the Final Analysis Dataset

Suppose your team is finalizing the statistical analysis plan (SAP) for a phase 3 diabetes trial whose time-in-range and hypoglycemia endpoints come from blinded continuous glucose monitoring (CGM), and the database build has not started. FDA's May 2026 technical specifications document, Submitting Continuous Glucose Monitoring Data in Clinical Trials, gives the submission chain those endpoints should travel: epoch readings tabulated in SDTM LB, a standalone ADaM epoch dataset (ADCGM) that also represents epochs the device never recorded, optional intermediate summaries, a final analysis dataset (ADCGMEN) that carries completeness alongside every endpoint value, and, when fingerstick or venous glucose is collected, a paired dataset (ADGLUCPR).

Several decisions cannot be reconstructed after the data arrive, so they belong in the SAP now: the algorithm that assigns each epoch to an analysis visit, how missing epochs are represented and which source supplies their reason, the rule that classifies a gap as participant-caused or DHT-caused, the completeness threshold and its sensitivity analyses, the pairing window for non-CGM glucose, and whether you intend to impute missing epochs at all. The specification recommends consulting FDA before any imputation. This guide walks the chain dataset by dataset, then condenses it into a lineage checklist and applies that checklist to FDA's own worked example.

The document is a final technical specifications guidance, version 1.0, dated May 2026 and prepared by the Office of Biostatistics in FDA's Center for Drug Evaluation and Research (CDER) together with the Center for Biologics Evaluation and Research (CBER). FDA's guidance page lists it as a final Level 2 guidance. Like other guidance, it contains nonbinding recommendations: the PDF states that 'should' means suggested or recommended, not required, and that an alternative approach can be used if it satisfies the applicable statutes and regulations; sponsors can contact the responsible FDA office to discuss one.

Its purpose is narrow: technical specifications for submitting CGM data from clinical trials that support a marketing application for a drug or biological product. It should be referenced whenever a CGM digital health technology (DHT) is used to evaluate CGM-derived endpoints. The SDTM and ADaM specifications are explicitly described as not prescriptive and not an exhaustive list of datasets, variables, or controlled terminology, and the recommended tables and figures may not cover everything a review needs. Section 1.3 also sets four boundaries that keep teams from over-reading it:

• Not interpretation guidance: it does not address how outputs from a CGM DHT should be interpreted and used within a specific clinical trial.

• Not verification or validation guidance: evidence that the CGM DHT is fit for purpose is left to FDA's December 2023 guidance, Digital Health Technologies for Remote Data Acquisition in Clinical Investigations. Our article on DHT fit-for-purpose evidence covers that separate question.

• No closed-loop systems: configurations in which the CGM is coupled with an insulin pump and insulin is dosed by an algorithm based on CGM readings are outside its scope.

• No standardized endpoint definitions: sponsors should define every CGM-derived endpoint in the protocol with a rationale, including, for example, how a hypoglycemic event is defined and classified and any duration used to identify it. FDA points sponsors to its draft diabetes efficacy endpoints guidance (May 2023), which remains a draft.

FDA describes CGM data as up to four kinds of data. Most of the later recommendations serve one purpose: keeping the links between them traceable, so that a reviewer can start from an endpoint value in the clinical study report (CSR) and walk back to individual sensor epochs.

1. Epoch-level data: the CGM readings at the device's sampling rate (for example every 1, 5, or 15 minutes, depending on make and model), plus other epoch-level output such as error codes.

2. Intermediate summary data (optional): datasets derived from the epoch data, such as daily or weekly totals, that bridge epochs and final analysis data. When epoch data flow directly into the final analysis dataset, none are needed.

3. Final analysis data: the dataset or datasets used to evaluate the CGM-derived endpoints and other analyses prespecified in the SAP, for example a two-week average time in range.

4. Other CGM data: information collected separately from the epochs, such as device make and model, software versions, and participant interactions with the device.

flowchart TD
  DEV["CGM DHT output: readings and error codes"] --> LB["SDTM LB: epoch rows, NOT DONE rows with LBREASND"]
  DEV --> DEVDS["Device-level datasets: SPDEVID from UDI, properties, settings, events"]
  DS["SDTM DS: permanent CGM discontinuation date"] --> ADCGM
  QS["Diary in QS and device events in DE"] --> ADCGM
  LB --> ADCGM["ADaM ADCGM, BDS: copied LB variables, PHANTOM rows, AREASND, AREASCA1, AVISIT or ATPT"]
  DEVDS --> ADCGM
  ADCGM --> INT["Optional intermediate summaries, for example daily"]
  INT --> EN["ADaM ADCGMEN, BDS: endpoint values, VALIDEPC, VALIDPTE"]
  ADCGM --> EN
  ADCGM --> PR["ADaM ADGLUCPR, OTHER: paired CGM and non-CGM readings"]
  ADLB["ADLB: fingerstick or venous glucose"] --> PR
  EN --> CSR["CSR: completeness and missing-data tables"]
  ADCGM --> CSR
  PR --> FIG["Paired CGM and non-CGM displays"]

Epoch readings are tabulated in the standard Laboratory Test Results (LB) domain rather than a custom domain. Table 1 of the specification sets LBMETHOD = 'CGM' for CGM epoch records and asks for LBDTC in ISO 8601 datetime format for every epoch. LBSTAT is 'NOT DONE' when the reading is empty and blank when a reading exists in LBORRES, and LBREASND explains why a reading the device collected is empty. Record counts are a built-in check: at a 5-minute epoch, 288 records per participant per day are expected (1,440 at a 1-minute epoch), and any excess or shortfall caused by system errors should be explained. The LB dataset may need to be split to meet the size constraints in FDA's Study Data Technical Conformance Guide, and additional epoch-level outputs go either into extra LB rows with their own test codes or into SUPPLB.

The most consequential SDTM rule is in Table 2, which separates gaps the device recorded from gaps it never saw:

• Gaps the device collected and transmitted: warmup after sensor insertion, early sensor termination (for example partial detachment or internal electrode damage), data transmission failures, and file corruption that prevents upload. When the device collected these epochs, they appear in LB with LBSTAT = 'NOT DONE' and a human-readable description of the device's error code in LBREASND, such as 'Warmup period', 'Sensor termination', 'Data transmission failure', or 'Data upload failure'. Additional error-code detail belongs in the SDTM Define-XML or the cSDRG. If the device did not collect them, the rows are excluded from LB.

• Nonwear: when the sensor is accidentally or purposely removed, or not replaced promptly between sessions, the device collects nothing and the rows are excluded from LB. FDA acknowledges that LB ideally would hold one record per planned epoch until discontinuation but may contain only what the device transmitted. These gaps are therefore represented later, in ADaM.

FDA also explains why warmup rows matter. Participants with more early sensor terminations need more replacement sensors, so they accumulate more warmup periods and appear to have more missing readings. Keeping warmup records in LB lets reviewers assess whether warmup time is imbalanced between participants or treatment arms.

Three companion SDTM structures anchor the rest of the lineage:

• Trial Summary (TS): sponsors may record that the specification was used with TSPARAMCD = 'FDATCHSP', TSPARAM = 'FDA Tech Spec', and TSVAL = 'CGM Technical Specifications Guidance v1.0'. FDA says it is interested in how often the specification is used. The parameter is optional, but if you populate it, the value string has to match exactly.

• Disposition (DS): FDA recommends collecting the date of permanent discontinuation from the CGM in a structured way and presenting it in DS. That date is then carried into ADCGM as DCCGMDTM, which sets the boundary for missing-data rows.

• Device-level datasets: CGMs are class II devices subject to FDA's unique device identification rules, and the specification quotes the 21 CFR 830.3 definitions. The device identifier (DI) identifies the labeler and the device version or model. The production identifier (PI) can carry the lot or batch, which for software-containing devices includes the software version, plus the serial number, expiration date, and manufacturing date. The specification encourages a dataset holding the UDI and populating SPDEVID with both portions, with a separate value for each sensor session. It recommends a dataset of all distinct SPDEVID and USUBJID pairs, findings datasets for device properties and settings when they differ across devices, participants, or time, and event data such as sensor insertion times, upload dates, upgrades or downgrades, and errors that kept data out of the epoch dataset.

Mid-trial device changes deserve a decision before first patient in. The specification encourages every participant to use the same CGM model and version throughout unless performance and features are identical. It notes that a model change produces a new DI, and asks that any change, its UDI, its justification, and the plan for handling differences be documented in the protocol and SAP. The draft diabetes endpoints guidance similarly recommends a single CGM device model throughout clinical development, one that is authorized for use in the United States and performs acceptably in the hypoglycemic range.

ADCGM is the ADaM epoch-level dataset. It follows the BDS at the same frequency as LB and is derived from LB together with other SDTM and ADaM data. FDA asks for it to be standalone rather than folded into ADLB for two reasons: ADLB is already large compared with other ADaM datasets, and a separate dataset lets CGM-specific analysis variables be used fully for epoch data while laboratory variables stay with laboratory results. Table 3 of the specification defines the variables that carry the lineage:

• Timing: ADTM holds each epoch's datetime. AVISIT, ATPT, or another primary timing variable maps each epoch to its analysis window.

• Sensor sessions: SPDEVID carries the UDI-based sensor identifier. SENSFL flags the first epoch of each new sensor session, which may be the first warmup record, where AVAL is still null, rather than the first glucose value. In FDA's example, the flag sits on warmup rows.

• Point-in-time criteria: CRITy, CRITyFL, and CRITyFN categorize individual readings, such as FDA's example flag for readings above 180 mg/dL. Category definitions belong in the protocol and SAP with supporting literature. When an event needs a duration spanning several readings, for example at least 15 consecutive minutes below 70 mg/dL in FDA's level 1 hypoglycemia illustration, FDA recommends defining separate analysis variables, because criterion flags are not appropriate when several rows determine one result.

• Day and night: ADTMCA1 categorizes each epoch as daytime or nighttime using sponsor-defined terminology (FDA's example uses 'DIURNAL' and 'NOCTURNAL'). The window rules go in the SAP, ADRG, and ADaM Define-XML.

• Missingness: DCCGMDTM (datetime of CGM discontinuation, null if the participant never stopped), AREASND, AREASCAy, and DTYPE, discussed in the next section.

• Copied SDTM variables: any LB variables needed for traceability, specifically LBDTC in ISO 8601 format plus LBSTAT and LBREASND where the device reported a reason. FDA's table also lists LBSEQ.

FDA also recommends additional epoch-level timing variables. Its worked example uses elapsed duration from midnight, elapsed day, day of week, an adjusted datetime, hour, and minute. Sponsors should explain how time changes are handled, including daylight saving shifts and time-zone changes when participants travel. Other data, such as insulin exposure from EX or CM, may be joined to ADCGM to support safety analyses.

FDA's review considers both the reasons for missing CGM readings and how common they are. The specification therefore asks ADaM to show every missing epoch, not only the ones the device reported. ADCGM keeps the LB rows marked 'NOT DONE' and adds rows with DTYPE = 'PHANTOM' for intermittent gaps that never reached LB, nonwear being the typical case. Rows for missing epochs should cover the participant's entire planned period of CGM wear. If the participant permanently stopped using the CGM, they stop at DCCGMDTM, and no rows are provided after discontinuation. The table below combines FDA's Table 2 scenarios with the ADaM representation and the reason categories used in FDA's appendix example.

The reason fields have different jobs. The primary reason should appear in LBREASND, and in AREASND when that variable is derived. AREASND is derived only when needed, for example to standardize device wording into sponsor-defined terminology, to convert an error code into readable text, or to bring in a reason from another source such as a participant diary in QS or an event recorded in DE. When no reason was collected, both are null. FDA recommends using AREASCA1 for a binary categorization, participant-caused or DHT-caused, with the assignment rules written into the SAP, ADRG, and ADaM Define-XML.

FDA's own example shows why those rules need to be written down. Its participant's day 11 gap is categorized as DHT-caused because the device reported the sensor as inactive, even though the participant's diary says the sensor was partly pulled off by accident. Neither choice is wrong, but the SAP should say which source wins when the device and the participant disagree, or the missing-data-by-reason table will not be reproducible. FDA suggests that sponsors consider a participant diary to capture wear compliance during the planned wear period, because device error codes cannot explain why a participant took a sensor off. The measurement side of that problem, telling non-wear from true inactivity, is covered in our guide to wearable non-wear time.

Intermediate summary datasets are optional. FDA's examples include CGM-derived values by day, by week, by weekday versus weekend, or for particular days of the week, and a study may produce several. When they are used to build the final analysis dataset, they should be submitted with the other ADaM CGM datasets. Otherwise ADCGM can feed the final analysis dataset directly.

ADCGMEN is the BDS dataset behind the CSR's CGM tables, listings, and figures. Its parameters depend on the protocol. The specification gives mean glucose, glucose management indicator, glucose variability, and the percentage of time above, below, or within predefined glucose ranges as examples, and the range definitions come from the protocol and SAP rather than from FDA. In the appendix example, time in range is defined in the study documentation as the percentage of epochs between 70 and 180 mg/dL. FDA recommends a row for every participant, parameter, and analysis timing value that the planned wear period implies, up to DCCGMDTM for participants who stopped CGM. That row is still provided when missing readings leave AVAL empty. Traceability is part of the specification: the metadata and submitted programs should let FDA recreate every ADCGMEN measure prespecified in the SAP.

Table 4 adds data-quality variables that make completeness reviewable for every endpoint value:

• VALIDEPC is the number of epochs with a non-null ADCGM.AVAL that contributed to the value.

• VALIDPTE is VALIDEPC divided by the expected number of epochs. The denominator may be calculated from the participant's planned CGM start and end dates, for example 7 days times 288 epochs = 2,016 for one week of 5-minute data. Its derivation should be documented in the study metadata.

• CRITy and CRITyFL are recommended for flagging when VALIDPTE falls below the prespecified threshold.

A naming inconsistency is worth knowing before you write Define-XML. Table 4 defines VALIDPTE, but the appendix narrative for the ADCGMEN example spells it 'VALIDPCE', and the example's criterion text reads 'VALIDPCT < 70%'. The example table's column header uses VALIDPTE. This guide follows Table 4.

FDA does not set a completeness threshold. It wants the threshold for a 'complete' assessment, and the rationale for it, defined in the SAP, and gives an example: records used in analysis might need a valid percentage above 70% over a 14-day period. A footnote attributes that example to the international consensus statement on CGM metrics for clinical trials (Battelino et al., Lancet Diabetes & Endocrinology, 2023). At a 5-minute epoch, 14 days means 4,032 expected epochs, so 'above 70%' requires at least 2,823 valid readings. Sensitivity analyses showing how filtering on completeness changes the results should also be prespecified. Both belong with the endpoint definitions that our SAP endpoint-definition guide recommends locking before unblinding.

When the protocol calls for non-CGM glucose collected alongside CGM, whether from a glucometer or fingerstick at home or a venous draw at a site visit, a standalone ADGLUCPR dataset may be submitted. FDA suggests confirming with the Agency whether it is recommended for a given study. Typical reasons for non-CGM glucose are calibration, confirming a hyper- or hypoglycemia alert, or other protocol needs. Non-CGM values themselves stay in LB and ADLB. ADGLUCPR is classified as ADaM OTHER because it may not fit the BDS, and it holds only the epochs that pair with a non-CGM reading.

• Pairing window: define it in the SAP. The specification mentions a 5 to 30 minute timeframe as an example, and its worked example uses at least 15 minutes on either side of each non-CGM reading. A wider window raises the chance that at least one CGM reading falls within it and shows how the CGM signal trends around the reference value.

• Identity variables: NCGMPARM, NCGMVAL, NCGMDTM, and NCGMID for the non-CGM reading, and CGMPARM, CGMVAL, CGMDTM, and CGMID for each CGM epoch, plus optional category variables (NCGMCAy, CGMCAy) that can reuse the ADCGM categories.

• Differences: ABSDIFF is the absolute difference between the two values. PCTDIFF divides ABSDIFF by the non-CGM value, so it is unsigned. DTMDIFF is the time difference in minutes, expressed as an ISO 8601 duration such as 'PT18M'.

• Closest-record flags: CDTMFL = 'Y' marks the epoch closest in time, and CVALFL = 'Y' marks the epoch closest in value (smallest ABSDIFF). Ties are flagged on every tied record.

• Supporting content: ADSL variables for demographic subgroups, stratification variables, and other analysis covariates, together with the program and pairing algorithm that created the dataset.

FDA's example shows the arithmetic. A non-CGM reading of 186 mg/dL at 12:08 PM pairs with eight CGM epochs from 11:50 AM to 12:25 PM. The 12:10 PM epoch, two minutes away, carries CDTMFL. Two epochs of 183 mg/dL, at 12:05 and 12:20 PM, both carry CVALFL: each has an ABSDIFF of 3 and a PCTDIFF of 1.61 (3 divided by 186).

The table below is our editorial restructuring of the May 2026 specification. FDA has not published a checklist in this form. Each row is one lineage hop, the section of the specification it comes from, what to verify, and the artifact that demonstrates it. Read it as a planning aid to check against the source document, not as a statement of FDA requirements.

To test the checklist, we applied it to FDA's illustrative Study A, in which participants wear CGM for three months, replace the sensor every seven days, and record 5-minute epochs, and the protocol calls for at least 70% valid epochs to compute the endpoint for each analysis visit. The rows below restate FDA's appendix example for a single participant. They are not independent study data.

The Week 2 row is the one to discuss with your statisticians. Although the protocol sets a 70% minimum for computing the endpoint, FDA's example still computes the value and records the shortfall in a flag rather than deleting the row or setting it to missing. Whether that flagged value then enters the primary analysis, a sensitivity analysis, or neither is a SAP decision. Write it down explicitly, because the dataset itself will not make it for you.

Beyond the sponsor's own endpoint displays, section 4.0 recommends three outputs for the CSR. The sponsor should ask FDA which of them apply to the program:

• Data completeness summary (example Table A5): the proportion of complete data by treatment arm and unit of time, with at least one table by the primary analysis timing variable, for participants who did not discontinue CGM. In the example, n is the count of CGM readings and the percentage uses expected epochs as the denominator. It can be built from ADCGM rows or from summed VALIDEPC values in ADCGMEN, and the programs should label which dataset was used.

• Missing data summary (example Table A6): the proportion of missing data by treatment arm and reason, using AREASND or LBREASND from ADCGM. FDA's example reasons include delay in sensor replacement, accidental sensor removal, data transmission issue, data upload failure, other file corruption issue, and reason unknown. Every reason collected during the study should appear.

• Paired CGM and non-CGM displays: when ADGLUCPR is relevant, visualizations such as a comparison of CGMCAy and NCGMCAy glucose categories.

The specification also says that the programs used to create the ADaM CGM datasets and to analyze the CGM data should be submitted with the marketing application, including the windowing and pairing algorithms. Commentary from clinical trial technology vendor Signant Health reads this as a higher transparency bar than ADaM submissions in which programs are described in the ADRG but not always provided in full. Plan code review and documentation as deliverables, not afterthoughts. Our database lock reconciliation checklist is a natural place to add the CGM-specific checks above.

FDA asks that the CGM DHT and the planned analyses be discussed as early as possible in development, for example at the End of Phase 2 meeting, and it invites sponsors to seek Agency input where the specification is unclear. A useful agenda covers:

• The CGM model and version, its epoch length and warmup behavior, and the plan for any mid-trial device change.

• Planned wear periods, the windowing algorithm, and how time-zone and daylight saving changes are handled.

• Endpoint definitions, including duration-based hypoglycemia events, with the literature behind them.

• The completeness threshold, its rationale, and the sensitivity analyses for filtering.

• Whether missing epochs will be imputed and, if so, the validation or simulation evidence you can offer.

• Whether ADGLUCPR is expected, and which section 4.0 displays apply.

• Recommendations, not law: the document is nonbinding, its dataset specifications are not exhaustive, and alternatives remain open after discussion with FDA. Vendor summaries sometimes call these recommendations requirements; Signant's summary, for example, describes UDI-based device traceability as a submission requirement, while the specification says such a dataset is encouraged. Read the primary text before writing it into a data management plan.

• Deliberate gaps: FDA names no imputation methods, no standard CGM-derived endpoint definitions, and no completeness threshold. The 70% figure is an example tied to the consensus statement, not a floor.

• Endpoints still in draft: the diabetes efficacy endpoints guidance that the specification points to is still a May 2023 draft. The specification's own footnote cites it as May 2021, while section 1.4 gives May 2023. Endpoint definitions that feed CRITy flags and episode variables may need revisiting when that guidance is finalized.

• FDA only: the specification addresses submissions to FDA. It says nothing about other regulators' expectations, so do not assume a single data package satisfies every agency without checking.

• Standards will move: FDA says the specification may be updated as SDTM, SDTMIG, SDTMIG-MD, ADaM, and ADaMIG versions change. FDA's Study Data Standards Resources page also reports preliminary testing of CDISC's Dataset-JSON as a possible replacement for the XPT v5 transport format. Check the specification's revision history before each submission.

• Early days: version 1.0 was issued in May 2026, so there is little public record of how reviewers are applying it. The guidance is to discuss uncertain points with FDA rather than infer them.

Teams that already treat timestamps and record counts as part of the endpoint, as our offline eCOA data guide does for patient-reported entries, will find the CGM specification familiar. Its added burden is scale: thousands of epochs per participant, each of which has to be accounted for, explained when missing, and traceable from the sensor to the summary number.