Integrating DHTs with EHRs and Clinical Systems
Why the boundary between the device and the clinical system is the regulated unit — and why provenance must survive the handoff
REGULATORY OPERATIONSThe handoff from a trial DHT into an EHR, EDC or RTSM is itself in regulatory scope: a validated interface with its own mapping, test evidence and audit trail — not plumbing.
Attribution, original capture time and audit trail must survive the transfer, not be regenerated on arrival. Map every element from capture to each handoff, name one system of record per element, bring the interface and its semantic mapping into computerized-system validation, and keep the interface inside change control.
Five boundaries recur — each with a named risk and the deliverable that retires it
| Boundary | Common risk | Validation deliverable |
|---|---|---|
| Device → EDC | Receipt time overwrites capture time | Validated mapping + transfer audit record |
| Device / site → EHR | Mismatched patient identity | Verified identity mapping + reconciliation log |
| EHR → EDC (eSource) | Transferred data diverge from the care record | Validated transfer spec + traceability matrix |
| Device → RTSM / IRT [decisional] | Late or wrong trigger fires | End-to-end validation with timing and failure-mode tests |
| System → eTMF / CTMS | Incomplete record transfer | Completeness check + index reconciliation |
Four positions that turn a data feed into a regulated boundary
Validation cannot stop at the two systems it connects; the boundary and the mapping across it are in scope (EMA/INS/GCP/112288/2023 s.6.1.2; ICH E6(R3) s.4.2.5).
FHIR packages and requests data; it does not guarantee a field means the same thing, in the same units and coding, on each side. A correctly transported, wrongly mapped value arrives looking valid.
Every other copy is traceable to it through a validated transfer, with a certified-copy procedure where a copy replaces an original. In qointa’s experience, ambiguity here is the most common root of reconciliation failure.
FDA locates DHT source data in the durable repository and does not intend to inspect individual DHTs; the EMA guideline expects device-side controls and records both capture and save time.
Six steps, in the order the evidence is built
- 1Map the data flow — trace each element from capture on the device through every handoff into EHR, EDC, RTSM and beyond.
- 2Classify the source — name the system of record per element and where the record becomes source in each region.
- 3Validate the interface — bring the boundary and its semantic mapping into computerized-system validation, not just the endpoints.
- 4Preserve provenance — carry attribution, original capture time and the audit trail across the transfer, ALCOA++ intact.
- 5Use fit interoperability standards — apply FHIR where the receiving system exposes it, then validate the mapping, not just the transport.
- 6Keep the interface inside change control — with revalidation triggers covering the mapping as well as the connection.
EMA/INS/GCP/112288/2023 · ICH E6(R3) and Annex 2 · 21 CFR Part 11 · FDA Part 11 Q&A (Oct 2024) · FDA DHT guidance · HL7 FHIR · ONC/ASTP HTI-1 · 21st Century Cures Act · European Health Data Space Regulation · GDPR
© qointa 2026 – Public – Uncontrolled when printed · Not legal advice; this summary does not classify any device.
sales@qointa.com · qointa.com
More from the library
Digital Health Technologies in Clinical Trials — A Regulatory Position-Paper Series
One device, several perimeters: a framework for assessing the regulatory impact of the technologies a trial relies on.
Read more →Who Is the Manufacturer? Economic-Operator Roles in DHT Supply Chains
How provisioning, importing, kitting and modifying a device assign manufacturer, importer and distributor duties — often by operation of law.
Read more →You Can Delegate the Work, Not the Accountability: Vendor Qualification and Oversight under ICH E6(R3)
The sponsor’s duty to qualify and oversee its DHT vendors — distinct from who holds the economic-operator role.
Read more →Talk to a specialist
Bring one device and one protocol — a wearable, a sensor, an app, anything. We will tell you which regulatory perimeters it opens and what it takes to close them.
Book a 15-minute call