FDA DHT guidance: what it asks sponsors to record

Your protocol takes an endpoint from a wearable at home. The final FDA guidance on digital health technologies (DHTs) for remote data acquisition, from December 2023, sets out what sponsors should show about that data. This guide goes through it section by section and maps each data ask to a field on the reading.

Request a demo
Fig. 1. A wearable reading with its provenance tag, beside the guidance passage it relates to.

Updated

The guidance in brief

A participant wears a sensor at home, and its readings reach the sponsor without a clinic visit. FDA's guidance Digital Health Technologies for Remote Data Acquisition in Clinical Investigations covers that path. People call it the FDA DHT guidance, or the FDA digital health technology guidance. It is final guidance for industry, investigators and other stakeholders, dated December 2023, and it finalizes the draft of the same title issued on 23 December 2021.

FDA's Center for Drug Evaluation and Research prepared it with the biologics and device centers and the Oncology Center of Excellence, under docket FDA-2021-D-1128. It covers clinical investigations of drugs, biological products, devices and combination products. The guidance defines a DHT as a system that uses computing platforms, connectivity, software or sensors for health care and related uses. A footnote adds that its recommendations may also apply when participants use a DHT at the trial site.

Its recommendations cover seven topics:

  • choosing a DHT that suits the trial;
  • describing the DHT in a submission;
  • verifying and validating it;
  • using its data for trial endpoints;
  • finding and managing the risks of its use;
  • keeping and protecting the data it collects;
  • the roles of sponsors and investigators.

Two topics are outside its scope: whether a DHT meets the legal definition of a device, and how to develop clinical outcome assessments. Like all FDA guidance, its recommendations are nonbinding.

Fit for purpose, from selection to submission

The guidance's central test is that a DHT be fit for purpose. Its level of validation must be enough to support its use in the trial, including the interpretation of its data. Section IV.A lists what to weigh when choosing one. That covers the trial population, the minimum technical and performance specifications, and the design and operation of the DHT, from battery life and data storage to how often it transmits.

The same section recommends alerts for a low battery, a poor signal or data that is not being recorded or sent. It asks sponsors to weigh participants using their own DHTs against sponsor-provided ones, and to keep a sponsor-provided option so that no one is excluded.

Section IV.B asks the submission to describe the DHT, the data it outputs and the flow of data from the DHT to the first durable electronic data repository. It also asks how access to the DHT and its data is controlled, and how the data is collected, stored, transmitted and archived.

Verification and validation

Section IV.C separates two checks. Verification confirms that the parameter the DHT measures, such as acceleration, temperature or pressure, is measured accurately and precisely. Validation confirms that the DHT appropriately assesses the clinical event or characteristic, such as step count or heart rate, in the trial's participant population.

Depending on the DHT and the trial, the guidance says verification and validation may include:

  • comparing the DHT's measurements with reference measurements of the same event;
  • evaluating what could affect a measurement, such as where a wearable sits or an activity mistaken for the event of interest;
  • validating any calibration the user performs;
  • confirming that measurements agree when the protocol allows more than one brand or model;
  • evaluating and justifying differences between measurements taken remotely and in the clinic with the same DHT.

Section IV.C.2 encourages public data exchange standards, including standards for identifying the data source. Section IV.C.3 asks for usability evaluations that show participants can use the DHT as the protocol directs, without errors.

Bring the endpoint from your protocol and the device behind it. The demo traces one reading from that device into a dataset row and shows each field the guidance asks about.

Request a demo

Endpoints, analysis and risk

Section IV.D asks for a precise endpoint definition: the type of assessment, its timing, the tool and how repeated assessments for one participant are combined. When a DHT repeats an existing measurement, such as weight taken at home instead of in the clinic, a new justification for the endpoint may not be needed. The DHT still needs verification and validation. A novel endpoint needs more, such as evidence that it reflects how a participant feels, functions or survives.

Section IV.E asks for the same data collection method in every study arm, and for the endpoint definition and its source data to be prespecified in the statistical analysis plan. It also asks for a plan to limit missing data and handle what is missing. Section IV.F covers clinical and privacy risks, and what informed consent should explain: the data a DHT collects, how it is used and who may see it.

Records, source data and device updates

Section IV.G is where the guidance is most specific about device data. The DHT data that supports an endpoint, with its associated metadata such as the times the measurements were made, should generally be transmitted to a durable electronic data repository. FDA treats the data in the first such repository it reaches as the source data. It does not intend to inspect individual DHTs when the data and all its metadata are securely transferred and kept there.

Section IV.H.1 lists the sponsor's own tasks. They include training for trial personnel and participants, technical help, a risk management plan and a safety monitoring plan for abnormal measurements. The sponsor should also confirm that data has reached the durable repository.

Section IV.H.4 asks sponsors to record the timing and nature of every update to each DHT, because an update can change measurements partway through a trial. Section IV.H.5 asks for procedures to identify and address DHT errors, such as battery, sensor or software faults, and to replace a DHT that is lost or damaged.

Each ask, mapped to a field on the reading

A Kymolog™ reading is a FHIR R4 Observation; FHIR, which stands for Fast Healthcare Interoperability Resources, names each part of the reading as a field. The edge agent writes the Observation at the moment of capture, with the measurement coded in LOINC and its unit in UCUM. Fig. 2 sets six of the guidance's asks beside the field that supports each one.

  • The time of measurement is effectiveDateTime, to the millisecond, so DHT values line up with reference measurements.
  • The device reference points to a Device record that holds the model and the unique device identifier (UDI), which shows which model took each reading when a protocol allows several.
  • Each reading records how it was matched to the participant: by location and visit at the site, or by device assignment at home.
  • Value, code, unit, device and time stay together in one versioned Observation, the shape section IV.G describes.
  • Each device's battery, signal and last contact are kept as data, and a failed delivery waits in an error queue to be retried.
The guidance asks, mapped to provenance fieldsA table of six asks from the FDA guidance, paraphrased, each beside the provenance field a Kymolog reading carries for it. Section IV.C.1: compare the DHT measurements with reference measurements of the same event; the field is effectiveDateTime, the time the device took the reading. IV.C.1: show measurements agree when the protocol allows more than one brand or model; the field is the device reference, with the Device and its DeviceDefinition giving type, model and UDI. IV.C.1: evaluate differences between remote and in-clinic measurements; the fields record how the reading was matched, by location and visit encounter at the site or by device assignment at home. IV.C.2: use public data exchange standards, including ones that identify the data source; the reading is a FHIR R4 Observation coded in LOINC and UCUM with its device reference. IV.G, highlighted in red: keep the DHT data with its metadata, such as the time each measurement was made, in a durable repository; value, code, unit, device and time stay in one versioned Observation. IV.H.5: have procedures to find and address DHT errors such as battery or sensor faults; device telemetry records battery, signal and last seen, and failed sends wait in the error queue.SECTIONTHE GUIDANCE ASKSTHE PROVENANCE FIELDIV.C.1Compare the DHT’s measurements withreference measurements of the same event.effectiveDateTimeThe time the device took the reading, on every reading,so each one pairs with its reference by time.IV.C.1Show measurements agree when the protocolallows more than one brand or model.deviceThe Device and its DeviceDefinition: device type, modeland UDI, on every reading.IV.C.1Evaluate differences between remote readingsand readings taken in the clinic.encounter, device assignmentHow the reading was matched: location and visit at thesite, device assignment at home.IV.C.2Use public data exchange standards, includingones that identify the data source.FHIR R4, LOINC, UCUMAn Observation coded in LOINC with a UCUM unit,carrying its device reference.IV.GKeep the DHT data with its metadata, such asthe time each measurement was made, in adurable repository.meta.versionIdValue, code, unit, device and time stay in one record; anedit makes a new version and keeps the old.IV.H.5Have procedures to find and address DHTerrors, such as battery or sensor faults.DeviceMetricBattery, signal and last seen for each device; a failedsend waits in the error queue.
The guidance asks, mapped to provenance fieldsA table of six asks from the FDA guidance, paraphrased, each beside the provenance field a Kymolog reading carries for it. Section IV.C.1: compare the DHT measurements with reference measurements of the same event; the field is effectiveDateTime, the time the device took the reading. IV.C.1: show measurements agree when the protocol allows more than one brand or model; the field is the device reference, with the Device and its DeviceDefinition giving type, model and UDI. IV.C.1: evaluate differences between remote and in-clinic measurements; the fields record how the reading was matched, by location and visit encounter at the site or by device assignment at home. IV.C.2: use public data exchange standards, including ones that identify the data source; the reading is a FHIR R4 Observation coded in LOINC and UCUM with its device reference. IV.G, highlighted in red: keep the DHT data with its metadata, such as the time each measurement was made, in a durable repository; value, code, unit, device and time stay in one versioned Observation. IV.H.5: have procedures to find and address DHT errors such as battery or sensor faults; device telemetry records battery, signal and last seen, and failed sends wait in the error queue.IV.C.1Compare the DHT’s measurements with referencemeasurements of the same event.effectiveDateTimeThe time the device took the reading, on every reading, soeach one pairs with its reference by time.IV.C.1Show measurements agree when the protocol allows morethan one brand or model.deviceThe Device and its DeviceDefinition: device type, modeland UDI, on every reading.IV.C.1Evaluate differences between remote readings andreadings taken in the clinic.encounter, device assignmentHow the reading was matched: location and visit at thesite, device assignment at home.IV.C.2Use public data exchange standards, including ones thatidentify the data source.FHIR R4, LOINC, UCUMAn Observation coded in LOINC with a UCUM unit, carryingits device reference.IV.GKeep the DHT data with its metadata, such as the timeeach measurement was made, in a durable repository.meta.versionIdValue, code, unit, device and time stay in one record; anedit makes a new version and keeps the old.IV.H.5Have procedures to find and address DHT errors, such asbattery or sensor faults.DeviceMetricBattery, signal and last seen for each device; a failed sendwaits in the error queue.
Figure 2 as a table
SectionThe guidance asksProvenance field
IV.C.1Compare DHT measurements with reference measurements of the same eventeffectiveDateTime: when the device took the reading
IV.C.1Show measurements agree when more than one brand or model is alloweddevice: Device and DeviceDefinition (type, model, UDI)
IV.C.1Evaluate differences between remote and in-clinic measurementshow it was matched: location and visit at the site, device assignment at home
IV.C.2Use public data exchange standards, including for the data sourceFHIR R4 Observation, LOINC code, UCUM unit, device reference
IV.GKeep DHT data with its metadata, such as measurement times, in a durable repositoryone versioned Observation holding value, code, unit, device and time
IV.H.5Find and address DHT errors such as battery or sensor faultsdevice telemetry (battery, signal, last seen); the error queue
Fig. 2. What the FDA’s final guidance “Digital Health Technologies for Remote Data Acquisition in Clinical Investigations” (December 2023) asks of DHT data, paraphrased by section, beside the field each Kymolog reading carries for it. The fields support a sponsor’s verification and validation; they do not stand in for it.

None of these fields validates a DHT by itself. They give the sponsor's verification and validation work, and FDA's reviewers, a record to trace. Whether a repository counts as the first durable one is still set in the sponsor's data management plan. See how Kymolog handles wearables for trial sponsors.

Questions sponsors ask about the guidance

Is the FDA DHT guidance final?
The guidance is final, dated December 2023, and it replaced the December 2021 draft of the same title. Its recommendations are nonbinding, like all FDA guidance.
Does every DHT in a trial need an investigational device exemption (IDE) application?
An IDE application is often not required. Section III names three cases under 21 CFR part 812. They are a nonsignificant-risk DHT used in a drug trial under an investigational new drug application (IND), an investigation exempt under 812.2(c), and a cleared or approved device used within its indications. A significant-risk DHT can still need one.
Does Kymolog make a DHT fit for purpose?
Fitness for purpose is the sponsor's determination, made from the DHT's verification, validation and usability evidence. Kymolog keeps the time, device, code, unit and match method on each reading, so that evidence has a record to point to.

Walk through your DHT endpoint with us

Tell us the endpoint and the DHT that measures it. The demo shows the fields each reading carries and where they land in your dataset. We reply within one business day with times to talk.

Request a demo