EClinCloud EDC for Device Studies: Linking Versions, Deficiencies and Endpoints

In medical device clinical investigations, data integrity is not measured solely by whether an electronic data capture (EDC) system meets 21 CFR Part 11 technical controls. For sponsors running pivotal trials under an Investigational Device Exemption (IDE) or clinical investigations under the European Union Medical Device Regulation (EU MDR 2017/745), the primary regulatory hazard often emerges months after database lock: reconstructability.

When a clinical reviewer at the U.S. Food and Drug Administration (FDA) or an EU competent authority reviewing a clinical investigation inspects a dataset, they do not review an EDC system in the abstract. They ask an operational question: Can this locked export prove exactly which physical device unit, hardware model, and firmware release was exposed to a specific subject, whether that unit experienced a deficiency, what corrective intervention was performed, and how that exact exposure sequence produced the primary clinical endpoint? Notified Bodies later reviewing clinical evidence for conformity assessment ask a similar reconstructability question, but they are not the primary inspectors of an ongoing MDR investigation.

In pharmaceutical trials, drug identity is comparatively static: an active substance is tracked by batch, lot, kit number, and dosage schedule. In medical device trials—especially those involving software-driven capital equipment, active implants, or connected digital health diagnostics—the investigational article changes. Hardware components undergo minor field modifications, firmware receives protocol-authorized patches, sensors experience calibration drift, and physical units exhibit mechanical or software deficiencies. If an EDC configuration records software versions as unstructured monitoring comments or leaves device accountability isolated in site-level paper logs, the study build fails the reconstructability test.

This guide provides clinical data managers, regulatory affairs professionals, and device clinical operations teams with an operational framework to evaluate configurable EDC systems. Using public product capabilities from configurable EClinCloud EDC as an evaluated implementation example alongside its professional study build services, we dissect statutory recording duties under 21 CFR 812.140 and MDR Article 80, establish a reusable field-to-evidence matrix, analyze a mid-study firmware change scenario, and provide an acceptance checklist for user acceptance testing (UAT) before first subject in (FSI).

---

What Must a Device-Investigation EDC Reconstruct That a Drug-Trial EDC Can Omit?

Sponsors transitioning from pharmaceutical clinical trials to medical device investigations frequently make a critical architectural error: they configure their electronic Case Report Forms (eCRFs) around a pharmaceutical visit model. In a standard drug trial, clinical endpoints are linked to subject visits and dosing schedules. If Subject 101 attended Visit 3 on Day 28, received Kit B-402, and recorded a trough blood concentration, the causal chain is straightforward.

Medical device investigations break this simplified assumption across five distinct dimensions:

[Device Receipt & Inventory] 
        │
        ▼ (Sponsor Device Identifier: SDI-1042 / Firmware v2.0.4)
[Subject Exposure Event] ───────────────► [Primary Endpoint Evaluation]
        │                                         ▲
        ▼ (Deficiency Observed)                   │ (Clinical / Engineering Fix)
[Device Deficiency eCRF] ───────────────► [Corrective Intervention eCRF]

1. Unit-Level Physical Identity vs. Consumable Batches: Unlike a tablet dissolved or an injectable metabolized, an investigational medical device is often a durable, reusable unit or a multi-part system comprising a console, an applicator, and a single-use disposable component. The EDC must track the individual device unit identifier across multiple exposures or subjects.
2. Dynamic Software and Firmware States: A software-enabled device may begin a pivotal clinical trial running Firmware Release 2.0.4 and, following an authorized Investigational Device Exemption (IDE) supplement or substantial modification approval, transition to Firmware Release 2.1.0. If the EDC cannot join the specific firmware build to the exact subject exposure date and time, the sponsor cannot stratify safety and performance endpoints during statistical analysis.
3. Device Deficiencies and Use Errors: Under medical device Good Clinical Practice (GCP), any malfunction, use error, or inadequacy in device labeling or user interface must be documented, whether or not an adverse event occurred. The EDC must capture the mechanical or digital failure state as a structured event linked directly to the device unit.
4. Engineering and Clinical Interventions: When a device experiences an error code, battery depletion, or connectivity failure during a procedure, the clinical team may replace the unit, adjust parameters, or abort the session. The EDC must capture what intervention occurred and determine whether the primary efficacy endpoint remains evaluable.
5. Dual Safety Categorization: Device trials require separate tracking of patient clinical events (Adverse Events, Serious Adverse Events) and device physical events (Device Deficiencies, Adverse Device Effects, Unanticipated Adverse Device Effects). A device deficiency can occur without an adverse event, and an adverse event can occur without a device deficiency.

If an EDC export cannot join these five operational records into a coherent relational dataset, the sponsor may be unable to produce the reconstructable copy that FDA's October 2024 electronic-systems Q&A (Question 5) says inspectors may request: all records and data needed to reconstruct a clinical investigation, including associated metadata and audit trails, in human-readable form. That guidance does not itself prescribe a software-version eCRF field. It is an inspection-copy duty. Whether the copy can answer a device-version question depends on how the study was built.

---

Which Fields Are 21 CFR 812.140 or MDR Article 80 Duties, and Which Are Our Design Proposal for Software Version?

When designing eCRFs, teams must clearly separate statutory regulatory mandates from operational design proposals. Conflating regulatory requirements with voluntary technical proposals leads to confusion during protocol design, site training, and regulatory audits.

U.S. FDA Statutory Duties: 21 CFR Part 812

In the United States, investigational device recordkeeping is governed by 21 CFR 812.140. Under 21 CFR 812.140(a)(2), the investigator is legally required to maintain records of receipt, use, or disposition of a device that include:

• The type and quantity of the device;
• The dates of its receipt;
• The batch number or code mark;
• The names of all persons who received, used, or disposed of each device;
• Why and how many units were returned to the sponsor, repaired, or otherwise disposed of.

Under 21 CFR 812.140(a)(3), the investigator case history must include, among other things:

• (ii) relevant observations, including records concerning adverse device effects (whether anticipated or unanticipated), information on the condition of each subject upon entering and during the investigation, relevant previous medical history, and diagnostic-test results;
• (iii) a record of the exposure of each subject to the investigational device, including the date and time of each use, and any other therapy.

Notice what 21 CFR 812.140 does not say: the statute does not use the words "software version," "firmware commit," or "digital application build." The statutory identifiers are batch number or code mark and date and time of each use.

For a software-driven investigational device, a firmware build is the functional identity of the article that was actually used. Recording it as a controlled field is our analytical design proposal. It is not a named 812.140 data element, and it is not a named requirement in FDA's October 2024 Q5. Q5 (content current as of 2 October 2024) is a retention and inspection-copy question: FDA may request all records and data needed to reconstruct the investigation, including metadata and audit trails, in human-readable form. A dedicated version field is how a software-enabled study makes that copy answer a version-stratification question.

European Union Statutory Duties: MDR 2017/745

Under EU MDR 2017/745, device investigations (Chapter VI and Annex XV) split definition, recording, and reporting:

• Article 2(59) Definition: A device deficiency is "any inadequacy in the identity, quality, durability, reliability, safety or performance of an investigational device, including malfunction, use errors or inadequacy in information supplied by the manufacturer."
• Article 80(1) Recording: The sponsor shall fully record (a) any adverse event of a type identified in the clinical investigation plan as critical to evaluation of the results, (b) any serious adverse event, (c) any device deficiency that might have led to a serious adverse event if appropriate action had not been taken, intervention had not occurred, or circumstances had been less fortunate, and (d) any new findings in relation to (a)–(c). Article 80(1) is not a duty to record every non-serious adverse event or every device deficiency. Broader recording of all deficiencies, including those that could not have led to an SAE, is an ISO 14155:2026 Clause 7.4 / CIP design choice, not 80(1) text.
• Article 80(2) Reporting: The sponsor shall report without delay to all Member States in which the investigation is being conducted (a) any SAE with a causal relationship to the investigational device, comparator, or investigation procedure, or where such a relationship is reasonably possible, (b) any near-miss device deficiency of the kind in 80(1)(c), and (c) related new findings. The statute says "without delay" and that the period shall take account of severity. Numerical 2- and 7-calendar-day clocks sit in MDCG 2020-10/1 Rev.1 (guidance, not a statute).
• Article 27 Carve-Out: Article 27(1) establishes the UDI system described in Annex VI Part C for identification and traceability of devices other than custom-made and investigational devices. Sponsors cannot treat a commercial UDI carrier as the investigational tracking mechanism; the EDC (or a designated IRT/RTSM) must supply a study-specific identifier.

ISO 14155:2026 clause numbers below come from the public table of contents on the ISO 14155:2026 catalogue page (Online Browsing Platform preview, retrieved 2026-09-07). In this edition, clause 5.8 is informed consent, 7.2 is investigation-site initiation, and 9.2 covers local representative (9.2.1) and implant card (9.2.2)—not device-accountability fields. We cite clause 7.4 for adverse events and device deficiencies and clauses 6.6 / 7.5 for case report forms and investigation documentation. We do not invent subclause prescriptions from the paywalled full text.

Data Element / Field Group	U.S. 21 CFR 812.140 Statutory Basis	EU MDR 2017/745 Statutory Basis	ISO 14155:2026 (standard, not statute)	MedDeviceGuide Classification
Device Batch / Code Mark	Mandatory (812.140(a)(2))	Application and IB must identify the investigational device (Annex XV Chapter II §§1.9, 2.1). That is not an eCRF field list.	CRF and documentation clauses 6.6 / 7.5. The public TOC does not name a batch-number field.	Statutory mandate (US records)
Exposure Date & Time	Mandatory (812.140(a)(3)(iii))	Not a named field in Annex XV Chapter III (that chapter is other sponsor obligations, including the clinical investigation report).	CRF and documentation clauses 6.6 / 7.5	Statutory mandate (US records)
Device Deficiency Tracking	Adverse device effect records (812.140(a)(3)(ii)); UADE reports (812.150). "Device deficiency" is not 812 vocabulary.	Art. 80(1)(c) records near-miss deficiencies; Art. 80(2)(b) reports them. Not every deficiency.	Clause 7.4 (Adverse events and device deficiencies); definition in clause 3.19	Mixed: US ADE/UADE + EU 80(1)(c) + ISO 7.4
Near-Miss Deficiency Flag	Not named in 812 text	Mandatory record (Art. 80(1)(c)) and report (Art. 80(2)(b))	Within clause 7.4	Statutory mandate (EU) / best practice (US)
Controlled Software / Firmware Version	Not named in 812 text	Not a named EDC field. Art. 2(59) is a deficiency definition, not a version-field mandate.	Not named in the public TOC	Design proposal (reconstructability)
Sponsor Device Identifier (SDI)	Operationalizes "code mark"	Operationalizes Annex XV identification in the live dataset	Design proposal	Design proposal (relational join key)
Corrective Engineering Intervention	Implied in disposition records (812.140(a)(2)(iii))	Art. 80(1)(c) refers to action / intervention	Action taken belongs with clause 7.4 records, not clause 9.2	Design proposal (relational join key)
CDISC SDTMIG-MD Mapping Target	Voluntary industry standard	Voluntary industry standard	Not specified	Design proposal (downstream tabulation)

---

Field-to-Evidence and Owner Matrix (MedDeviceGuide Design Proposal)

To ensure that an EDC study build captures every regulatory element and remains fully reconstructable after database lock, data management teams must assign clear field-level ownership. An eCRF field without an unambiguous owner results in missing data, protocol deviations, and unresolvable queries during database closeout.

The following field-to-evidence matrix provides a recommended operational architecture for device trials.

eCRF Domain / Table	Core Field Name	Field Format / Control Type	Regulatory & Guidance Anchor	Primary Field Owner	Edit Check & UAT Acceptance Criteria
Device Inventory & Receipt	SDI_NUM (Sponsor Device ID)	Text (Enforced Pattern: DEV-[A-Z0-9]{6})	21 CFR 812.140(a)(2); MDR Annex XV Ch. II identification (not an eCRF list)	Sponsor Logistics / Site CRA	Must be unique across entire study; verified against shipment manifest.
Device Inventory & Receipt	DEV_MODEL	Controlled Dropdown	21 CFR 812.140(a)(2) type; Annex XV Ch. II §1.9	Site Coordinator	Restricted to approved protocol device configurations.
Device Inventory & Receipt	DEV_SERIAL	Text (OEM Serial or Batch)	21 CFR 812.140(a)(2) code mark	Site Coordinator	Mandatory before unit can be selected on exposure forms.
Subject Exposure	EXP_DATETIME	ISO 8601 Date/Time (YYYY-MM-DDThh:mm)	21 CFR 812.140(a)(3)(iii)	Treating Investigator	Cannot be future date; must fall within consented visit window.
Subject Exposure	EXP_SDI_LINK	Dynamic Lookup (from Inventory table)	FDA Oct 2024 Q5 (inspection copy); MDR Annex XV identification	Treating Investigator	Restricts selection to active, non-quarantined units at that site.
Subject Exposure	SW_VERSION	Controlled Dropdown (Active Builds)	MDG design proposal (not 812 text)	Treating Investigator / CRA	Restricts selection to protocol-authorized software builds; triggers query if retired.
Subject Exposure	EXP_STATUS	Radio: Completed / Partial / Aborted	CIP / SAP evaluability; ISO 14155:2026 cl. 6.6 CRFs	Treating Investigator	If "Partial" or "Aborted", dynamically displays mandatory Reason field.
Device Deficiency	DD_NUM	Sequence Key (DD-XXXX)	MDR Art. 2(59); ISO 14155:2026 cl. 3.19 / 7.4	Treating Investigator	Auto-generated upon initiation of deficiency record.
Device Deficiency	DD_SDI_LINK	Dynamic Lookup (from Exposure record)	MDR Art. 80(1)(c); ISO 14155:2026 cl. 7.4; FDA Oct 2024 Q5	Treating Investigator	Automatically populates device model, serial, and active software version.
Device Deficiency	DD_TYPE	Multi-select: Malfunction / Use Error / Labeling Inadequacy / Usability	MDR Art. 2(59); ISO 14155:2026 cl. 3.19	Treating Investigator	"Usability" categorized per ISO 14155:2026 3.19; cannot be blank.
Device Deficiency	NEAR_MISS_FLG	Boolean: Yes / No	MDR Art. 80(1)(c) and 80(2)(b); MDCG 2020-10/1 (guidance clocks)	Treating Investigator	If "Yes", triggers an internal sponsor safety-officer alert (our design proposal). This is not the MDCG 2-/7-calendar-day reporting clock.
Device Deficiency	AE_LINK_ID	Lookup (from Adverse Event Log)	ISO 14155:2026 cl. 7.4 (AE and device deficiencies)	Site Clinical Coordinator	"None" permitted; if linked, cross-populates AE severity and onset time.
Intervention	INT_ACTION	Controlled Dropdown: Replaced / Repaired / Continued / Terminated	21 CFR 812.140(a)(2)(iii) disposition; MDR Art. 80(1)(c); ISO 14155:2026 cl. 7.4	Treating Investigator	If "Replaced", requires entry of new replacement SDI_NUM.
Clinical Endpoint	EP_EVAL_FLG	Boolean: Evaluated / Unevaluable	Statistical Analysis Plan (SAP)	Independent Core Lab / Investigator	Cross-checks whether deficiency or aborted exposure invalidated measurement.
Clinical Endpoint	EXP_SEQ_LINK	Foreign Key (to Exposure record)	FDA Oct 2024 Q5; CDISC SDTMIG-MD (industry recommendation)	Biostatistician / Data Manager	Must link endpoint directly to the exact exposure event sequence.

---

Recommended Reading

Medical Device Trial Master File (TMF) and ISF Guide: ISO 14155, FDA, and EU MDR

Clinical Evidence Regulatory2026-08-23 · 41 min read

How Should Device Identifier, Deficiency, Intervention and Endpoint Join Before Database Lock?

A frequent failure mode in medical device clinical trials is the "siloed table syndrome." In this scenario, an EDC study build contains a robust Adverse Event form, a functional Clinical Endpoint form, and an isolated Device Accountability log. However, each form operates as an independent flat table.

When a clinical data manager exports the locked database at the end of the trial, they discover that while Subject 042 experienced an elevated biomarker (primary endpoint) and an intermittent sensor communication error (device deficiency), the database has no relational key proving that the sensor which failed was the sensor that generated the biomarker.

┌────────────────────────────────────────────────────────┐
│               Device Inventory Table                   │
│  SDI_NUM: DEV-001042                                   │
│  DEV_MODEL: Diagnostic Catheter Sensor                 │
│  DEV_SERIAL: SN-88392                                  │
└──────────────────────────┬─────────────────────────────┘
                           │ 1:Many
                           ▼
┌────────────────────────────────────────────────────────┐
│                Subject Exposure Event                  │
│  EXP_ID: EXP-00892                                     │
│  SUBJ_ID: 104-042                                      │
│  EXP_DATETIME: 2026-09-07T10:15                        │
│  SDI_LINK: DEV-001042 ◄──────────────────────┐         │
│  SW_VERSION: v2.0.4                          │         │
└──────────────────────────┬───────────────────┼─────────┘
                           │ 1:1 or 1:Many     │
              ┌────────────┴───────────┐       │
              ▼                        ▼       │
┌──────────────────────────┐ ┌─────────────────┴─────────┐
│ Device Deficiency Form   │ │ Primary Endpoint Form     │
│ DD_ID: DD-0044           │ │ EP_ID: EP-00892           │
│ SDI_LINK: DEV-001042     │ │ EXP_SEQ_LINK: EXP-00892   │
│ DD_TYPE: Usability Error │ │ PRIMARY_OUTCOME: 94.2%    │
│ NEAR_MISS: No            │ │ EVALUABLE: Yes            │
│ AE_LINK: AE-0012         │ └───────────────────────────┘
└─────────────┬────────────┘
              │ 1:1
              ▼
┌──────────────────────────┐
│ Corrective Intervention  │
│ INT_ACTION: Unit Reboot  │
│ SUCCESS: Yes             │
│ UNIT_REPLACED: No        │
└──────────────────────────┘

To prevent this breakdown, the EDC data model must enforce relational integrity prior to database lock:

1. Foreign Key Anchoring: The SDI_NUM (Sponsor Device Identifier) must serve as the primary key in the inventory domain and as a mandatory foreign key in the exposure domain (EXP_SDI_LINK) and the deficiency domain (DD_SDI_LINK).
2. Session-Level Exposure Keys: Every subject contact with the device must generate a unique exposure identifier (EXP_ID). The clinical endpoint form must store this EXP_ID as its foreign key (EXP_SEQ_LINK), rather than relying solely on the general visit date or subject number.
3. Automated Cross-Form Edit Checks:
   • Check 1 (Active Inventory): An investigator cannot enter an SDI_NUM on an exposure form unless that unit is logged as "Received and Qualified" in the site inventory table.
   • Check 2 (Deficiency Linking): If a user selects "Yes" to the question "Did a device malfunction, error, or use difficulty occur during this procedure?" on the exposure form, the EDC must dynamically spawn a linked Device Deficiency Form pre-populated with the subject ID, exposure timestamp, unit identifier, and software version.
   • Check 3 (Intervention Closeout): A device deficiency record cannot be marked complete without a corresponding entry in the intervention domain documenting the physical disposition of the unit (e.g., unit quarantined, returned to sponsor, re-calibrated, or continued in service).

When evaluating a configurable platform such as EClinCloud EDC, data managers should treat linked tables and edit checks as company-described capabilities to be demonstrated, not as proof that a given study already joins device version to endpoint. EClinCloud's public EDC page describes AI-generated visits, forms, linked tables, and edit checks, with data-manager review before go-live, remote review, lock and export, and validated mid-study database changes. Dynamic cross-form inheritance of unit ID and firmware build is the UAT question in the checklist below; it is not a documented device-investigation module. If UAT shows those joins work, the locked export can later be mapped to CDISC SDTMIG for Medical Devices (SDTMIG-MD v1.1) domains such as Device Identifiers (DI), Device-In-Use (DU), Device Properties (DO), Device Tracking (DT), and Device Events (DE). CDISC is an industry tabulation standard, not a claim that EClinCloud natively emits those domains.

---

What Fails in a Mid-Study Firmware Change If Version Is a Free-Text Comment Instead of a Controlled Identifier?

To understand why free-text entry is catastrophic in regulated device trials, consider a real-world operational scenario.

The Scenario: 120-Subject Pivotal Diagnostic Trial

A medical device manufacturer is running a multi-center pivotal trial evaluating an intelligent, AI-assisted ultrasound imaging probe designed to detect structural vascular abnormalities. The trial protocol plans for 120 evaluable subjects across 8 clinical investigation sites in the United States and Germany.

At Subject 42, interim site feedback identifies an edge-case software bug: when scanning patients with elevated body mass index (BMI), the probe embedded processing unit experiences thermal throttling, causing frame rate latency. The sponsor engineering team develops a firmware patch: Firmware Release 2.1.0, which optimizes power distribution and alters image smoothing algorithms. Firmware 2.0.4 is phased out.

The sponsor submits an IDE supplement to FDA and a substantial-modification notification to the German Federal Institute for Drugs and Medical Devices (BfArM). Assume for this hypothetical that both authorities authorize the change before rollout. The clinical operations team initiates site upgrades. However, deployment is asynchronous:

• Sites 01 and 02 upgrade their hardware immediately (Subjects 43–65 receive Firmware 2.1.0).
• Sites 03 and 04 delay upgrade due to institutional IT change freezes; they scan Subjects 43–58 using Firmware 2.0.4 before upgrading.
• Site 05 experiences a site-level failure where one probe is upgraded to 2.1.0 while a secondary backup probe remains on 2.0.4.

Failure Mode A: The "Free-Text Comment" Study Build

In Study Build A, the EDC designer treated software version as an operational afterthought. On the Subject Procedure Form, there is a general text box labeled: "CRA / Site Notes on Equipment."

When the study finishes, the biostatistician prepares the locked dataset for final statistical analysis and Statistical Analysis Plan (SAP) execution. The FDA review division issues a formal Information Request:

"Please provide a sensitivity analysis of the primary diagnostic accuracy endpoint stratified by embedded firmware release (v2.0.4 vs. v2.1.0), including a cross-tabulation of all sensor drop-out deficiencies and adverse events observed under each build."

The biostatistician queries the database:

• In 34 exposure records, the comment field is completely blank.
• In 22 records, the site coordinator wrote: "Updated probe used."
• In 14 records, the coordinator wrote: "Firmware 2.1".
• In 8 records, the entry reads: "V2.1.0 patched by John on Tuesday."
• In Site 05, because both probes were circulating simultaneously, nobody recorded which probe was used for Subject 74, who experienced an image freeze deficiency.

The Result: The dataset cannot be reconstructed programmatically. The sponsor cannot stratify the primary endpoint by firmware without a side spreadsheet. The team is forced into retrospective data clarification, paper engineering-log audits, and protocol-deviation reports. The review clock can pause for months. This delay figure is illustrative, not a measured industry statistic.

Success Mode B: The Controlled Relational Build

In Study Build B, configured according to our design proposal:

1. The EDC maintains an active Software Configuration Table controlled by the sponsor data manager.
2. The SW_VERSION field on the Subject Exposure Form is a mandatory dropdown restricted to protocol-authorized values (v2.0.4 or v2.1.0).
3. If an investigator selects probe unit DEV-001042, the EDC automatically cross-references the probe serial number against the site inventory table, which documents the exact date the firmware patch was applied.
4. If a site coordinator attempts to record an exposure with an outdated firmware version after the site documented cut-over date, the EDC fires an immediate soft query requiring confirmation.

When the FDA requests the sensitivity analysis, the biostatistician executes a single structured query joining EXP_ID, SW_VERSION, DD_NUM, and PRIMARY_ENDPOINT. The stratified analysis is generated, audited, and submitted within 48 hours.

---

What Should a Vendor Demonstration Prove on a Configurable EClinCloud EDC Before First Subject In?

When evaluating an EDC platform for a device investigation, regulatory and data management teams must look beyond general marketing claims. Vendors frequently advertise compliance with 21 CFR Part 11, EU Annex 11, or ISO 13485. However, as emphasized in regulatory inspection findings, platform compliance is not study-specific compliance. A platform may possess an audit trail engine, but if the study build does not configure the necessary fields, the trial remains non-compliant.

When assessing a configurable platform such as EClinCloud EDC, sponsors should run an objective demonstration against the configured study build. On its public EDC page and Trust page, EClinCloud describes:

• AI-assisted study build with data-manager review before go-live;
• Optical Character Recognition (OCR) source document capture;
• Remote clinical review;
• Electronic database lock and export;
• ALCOA+ access-control language and validated mid-study database changes;
• Company-described alignment with 21 CFR Part 11, EU Annex 11, ICH E6(R3), GAMP 5, CDISC, and China GCP (2026);
• Company-published certifications including ISO 27001, ISO 9001, ISO 20000, and ISO/IEC 42001:2023.

These are company descriptions. They are not independent testing, not FDA approval, and not proof that a given study configuration is compliant. EClinCloud does not claim a hard-coded medical-device investigation module, and the software is not itself an FDA-cleared medical device. Reconstructability is a property of the sponsor's study build. We do not republish EClinCloud's marketing percentages for build effort or OCR accuracy as our findings.

┌────────────────────────────────────────────────────────────────────────┐
│             Pre-FSI Reconstructability Acceptance Flow                │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
                                    ▼
       ┌──────────────────────────────────────────────────────────┐
       │ 1. Simulate Device Exposure Event                        │
       │    - Select Unit ID (SDI-001042)                         │
       │    - Select Firmware Build (v2.0.4)                      │
       │    - Enter Exposure Timestamp                            │
       └────────────────────────────┬─────────────────────────────┘
                                    │
                                    ▼
       ┌──────────────────────────────────────────────────────────┐
       │ 2. Trigger Device Deficiency & Intervention              │
       │    - Flag Malfunction / Usability Error                  │
       │    - Verify Auto-Inheritance of Unit ID & Firmware Build │
       │    - Record Corrective Action (Unit Replacement)         │
       └────────────────────────────┬─────────────────────────────┘
                                    │
                                    ▼
       ┌──────────────────────────────────────────────────────────┐
       │ 3. Execute Primary Endpoint Entry                        │
       │    - Input Quantitative Outcome Measure                  │
       │    - Verify Foreign Key Link to Exposure Event           │
       └────────────────────────────┬─────────────────────────────┘
                                    │
                                    ▼
       ┌──────────────────────────────────────────────────────────┐
       │ 4. Perform Test Export & Join Verification               │
       │    - Export Dataset (CSV / SAS)                          │
       │    - Run Relational Join Query                           │
       │    - Can Endpoint trace to Unit ID & Firmware Version?   │
       └────────────────────────────┬─────────────────────────────┘
                                    │
                     ┌──────────────┴──────────────┐
                     ▼                             ▼
              [PASS: Go-Live]              [FAIL: Halt Build]

Before first subject in, data managers should execute the following Vendor Demonstration & Acceptance Checklist against the configured study build:

Reusable Vendor Demonstration Checklist (MedDeviceGuide Design Proposal)

• Test Case 1: Dynamic Foreign Key Inheritance
  • Action: Create an exposure record selecting a test device unit (DEV-TEST-01). Mark the session as having experienced a deficiency.
  • Acceptance Criteria: The spawned Device Deficiency eCRF must automatically inherit the DEV-TEST-01 identifier, model, and active software version without requiring manual text re-entry by the site user.
• Test Case 2: Controlled Firmware Version Management
  • Action: Attempt to enter an unapproved software version string (e.g., v2.2.0-beta) into the exposure form.
  • Acceptance Criteria: The EDC must reject free-text entry, restricting inputs to the authorized dropdown list established by the protocol configuration.
• Test Case 3: Near-Miss Safety Escalation Routing
  • Action: Enter a device deficiency where NEAR_MISS_FLG is set to "Yes" (a deficiency that did not cause an SAE, but might have led to one if circumstances had been less fortunate).
  • Acceptance Criteria: The EDC audit trail logs the entry. An internal workflow alert to the Sponsor Safety Officer (our design proposal) may support MDR Article 80(2) reporting. Do not treat a 24-hour email as the legal clock; MDCG 2020-10/1 Rev.1 uses 2- and 7-calendar-day reporting windows as guidance.
• Test Case 4: Human Acceptance of AI-Assisted Study Build
  • Action: If utilizing AI-assisted build utilities (such as EClinCloud study build tools) to generate eCRFs from the protocol, review the generated cross-form validation rules.
  • Acceptance Criteria: A human data manager must formally sign off on each rule, verifying that device-specific foreign keys and validation checks were not omitted in favor of generic drug trial templates.
• Test Case 5: Mid-Study Database Schema Amendment
  • Action: In a staging environment, simulate a protocol amendment that introduces a new firmware release (v2.1.0) and adds a battery temperature monitoring field mid-trial.
  • Acceptance Criteria: The database change must deploy without invalidating existing audit trails, altering historical exposure records, or disconnecting previously locked visit forms.
• Test Case 6: Human-Readable Export Reconstructability (FDA Oct 2024 Q5 / Q12)
  • Action: Generate a full study data export (CSV/SAS) including associated metadata and audit trail records.
  • Acceptance Criteria: The data manager must be able to execute a single script or SQL join that connects every primary endpoint record to its corresponding device unit, software version, and deficiency history. If the export cannot perform this join without external manual spreadsheet manipulation, the build fails UAT.

---

Recommended Reading

Malaysia MDA Automated Re-Registration: MeDC@St 2.0+, July 2026 Switch & CN Trap

Regulatory Quality Systems2026-09-04 · 22 min read

Does ISO 14155:2026, FDA's Still-Recognized 2020 Edition, or ICH E6(R3) Set the Recording Rule?

Navigating the landscape of international standards and regulatory guidances requires extreme care regarding legal authority, recognition dates, and jurisdictional scope.

ISO 14155:2026 vs. ISO 14155:2020

In March 2026, the International Organization for Standardization published ISO 14155:2026 (Fourth edition: Clinical investigation of medical devices for human subjects — Good clinical practice), cancelling and replacing the Third edition (ISO 14155:2020).

A critical refinement in ISO 14155:2026 is found in Clause 3.19, which updates the definition of a device deficiency (ISO Online Browsing Platform extract, 2026-09-07):

inadequacy in the identity, quality, durability, reliability, usability, safety or performance of a medical device, including malfunctions, use errors or inadequacy in the information supplied by the manufacturer including labelling. Note 1 to entry: This definition includes device deficiencies related to the investigational medical device or the comparator.

The explicit insertion of usability expands the GCP recording category to use-error and user-interface events, including misread onscreen prompts and physical-latch difficulties. That is a definition change in the standard. It is not a claim that ISO 14155:2026 incorporates IEC 62366-1 by reference.

Recording versus definition. Clause 3.19 is a definition. The public table of contents places operational AE and device-deficiency duties in Clause 7.4 (Adverse events and device deficiencies). We have not extracted the paywalled 7.4 subclauses, so we cite 7.4 as the AE/DD clause heading, not as a numbered field list.

Regulatory recognition is a separate legal fact from standard publication. As of the 25 May 2026 update of the U.S. FDA Recognized Consensus Standards database, the detail record for ISO 14155 Third edition 2020-07 remains Recognition List Number 055, FR Recognition Number 2-282 (Date of Entry 21 December 2020). This pass found no recognized 2026 edition on that record.

What does this mean for sponsors? An IDE is not a 510(k) Declaration of Conformity exercise. If you rely on ISO 14155 in a U.S. file that uses recognized consensus standards, cite the recognized 2020 edition under 2-282 until the database changes. When designing eCRFs for a global investigation, include usability and use-error categories from the 2026 definition so the same build can support MDR/ISO 14155:2026 recording without waiting for FDA recognition. That is a design choice, not a statement that FDA has recognized the 2026 edition.

The ICH E6(R3) Boundary: Pharmaceutical GCP Is Not Device Law

Many commercial EDC vendors heavily promote compliance with ICH E6(R3) (Good Clinical Practice), highlighting its modern principles on data governance, risk-based quality management (RBQM), and computerized systems.

Device clinical operations teams must understand a fundamental regulatory boundary: ICH E6(R3) is not universally mandatory for medical device clinical investigations. The International Council for Harmonisation (ICH) develops standards specifically for pharmaceuticals.

• In the United States, medical device investigations are governed by 21 CFR Part 812 and 21 CFR Part 50/56, not ICH E6.
• In the European Union, medical device investigations are governed by EU MDR 2017/745 Chapter VI. ISO 14155 is the device GCP standard. As this site's ISO 14155:2026 clinical investigation guide records, EN ISO 14155:2020/A11:2024 was the MDR-harmonized edition after the January 2026 implementing decision; ISO 14155:2026 is the current ISO edition and was not the harmonized citation in this pass.

ICH E6(R3) becomes relevant to a device sponsor only under specific circumstances:

1. When evaluating a drug-device combination product where the pharmaceutical component is primary;
2. When conducting a study in a jurisdiction whose national legislation explicitly references ICH GCP for all health products;
3. When an institutional review board (IRB) or corporate standard operating procedure (SOP) voluntarily adopts ICH E6 principles as institutional policy.

Citing ICH E6(R3) as the legal justification for device deficiency recording in an FDA IDE or EU MDR submission reveals a lack of regulatory precision. Rely on 21 CFR 812, EU MDR Article 80, and ISO 14155 as your binding legal and standard authorities.

A Note on FDA CSA vs. Clinical EDC Validation

Some teams erroneously attempt to apply FDA draft guidance on Computer Software Assurance (CSA) to their clinical EDC systems. FDA CSA guidance applies specifically to software used as part of production or the quality management system under 21 CFR 820 / ISO 13485 (QMSR). Clinical EDC validation is governed by 21 CFR Part 11, the predicate clinical regulations (21 CFR 812), and FDA October 2024 guidance on electronic systems in clinical investigations. Do not substitute manufacturing CSA documentation for formal clinical study UAT.

---

What Does This Cost in Build and UAT Effort Versus the Cost of an Unreconstructable Pivotal Dataset?

Implementing relational tables, software-build dropdowns, and automated deficiency linking requires additional upfront effort during study build. Clinical operations leaders often ask: What is the real resource impact?

Upfront Build and UAT Effort

The hours below are a MedDeviceGuide planning illustration, not a survey, not a vendor quote, and not a measured industry benchmark. Use them to size UAT, then replace them with your CRO or data-management estimate:

• eCRF design and specification: dedicated inventory, exposure-link, and deficiency tables — typically a few additional specification days when planned before first build.
• Relational logic and edit-check programming: foreign keys, near-miss routing, and dynamic lookups — typically a similar order of magnitude of specialized EDC programming.
• UAT: executing the six-part demonstration checklist and verifying a relational export join — typically one to two structured test days.

In other words, reconstructability is a pre-FSI configuration problem measured in days of specialist time, not a closeout surprise. When using AI-assisted configuration and professional study build services described by EClinCloud, specification time may be shorter, provided human data managers audit the generated architecture. We do not treat vendor build-time percentages as our findings.

The Downstream Cost of an Unreconstructable Dataset

Compare that planning envelope with the direction of failure costs, again as analysis rather than a priced dataset:

• Regulatory information requests and review pauses: if FDA or a European competent authority cannot reconstruct device exposure, the review clock can pause while the sponsor rebuilds the join from paper logs.
• Retrospective site audits: reconciling serial numbers and firmware versions from engineering logs across many sites is typically far more expensive than the UAT days above.
• Compromised analysis: if software versions cannot be disaggregated, a subset of subjects may become unevaluable, with knock-on enrollment or power consequences that dwarf study-build effort.
• Commercial delay: in a competitive device market, a multi-month launch slip is usually the dominant cost, even when no public source publishes a universal dollar figure for it.

The operational conclusion is still the UAT gate: do not go live if a test export cannot join a device deficiency and firmware version to a primary clinical endpoint. If that join needs a side spreadsheet, the build has failed.

---

Frequently Asked Questions (FAQ)

Does 21 CFR 812.140 require a software-version field in EDC, or only batch number or code mark plus exposure date and time?

21 CFR 812.140 does not use the words "software version." 21 CFR 812.140(a)(2) requires records of receipt, use, and disposition including "the batch number or code mark." Exposure date and time sit in 812.140(a)(3)(iii) ("the date and time of each use"), not in (a)(3)(ii). Paragraph (a)(3)(ii) covers observations including adverse device effects, subject condition, history, and diagnostic tests. For a software-driven investigational device, the firmware build is the functional identity of the article that was used. Under FDA October 2024 Q5, inspectors may request a human-readable copy of the records needed to reconstruct the investigation, including metadata and audit trails. A dedicated software-version field is an operational design proposal so that copy can answer a version question. It is not 812 text.

Is a device deficiency the same thing as an adverse device effect or a UADE, and must every deficiency be reported under MDR Article 80(2)?

No. A device deficiency is a physical, digital, or user-interface inadequacy of the investigational device (including malfunctions, use errors, and labeling inadequacies), as defined in MDR Article 2(59) and ISO 14155:2026 Clause 3.19. An Adverse Device Effect (ADE) is an adverse event in a human subject related to use of the device. A UADE is the U.S. 21 CFR 812.3(s) reporting category. A deficiency can occur without harming a subject (for example, an error code during pre-procedure calibration). Under MDR Article 80(1), the sponsor must fully record CIP-critical AEs, all SAEs, near-miss device deficiencies (80(1)(c)), and related new findings—not "every deficiency" as a statutory list. Broader recording of all deficiencies is an ISO 14155:2026 Clause 7.4 / CIP choice. Under Article 80(2), only SAEs with a reasonably possible causal relationship and near-miss deficiencies must be reported without delay. Operational 2-/7-calendar-day windows are MDCG 2020-10/1 Rev.1 guidance.

Does using EClinCloud EDC, or any vendor Part 11 or ISO 14155 marketing language, make the investigation automatically compliant?

No. Software vendors provide technical capabilities (role-based access, electronic signatures, time-stamped audit trails, configurable tables), but compliance is a property of the study-specific implementation. Neither FDA nor EU notified bodies certify or "approve" EDC platforms for general clinical use. EClinCloud's public Trust page lists company-described alignment with 21 CFR Part 11, EU Annex 11, GAMP 5, CDISC, and ISO certifications as published. Those descriptions are not an FDA or notified-body determination, and they do not prove that a given study configuration can reconstruct device version, deficiency, and endpoint. The sponsor remains responsible for the data model, edit-check validation, and export UAT.

Must a device investigation follow ICH E6(R3) computerized-system sections as if they were device law?

No. ICH E6(R3) is an international guideline developed for pharmaceuticals. It is not statutory device law. Device clinical investigations in the United States are governed by 21 CFR Part 812; in the European Union, they are governed by MDR 2017/745 and ISO 14155. While EDC vendors frequently highlight ICH E6(R3) because they serve pharmaceutical clients, device sponsors should cite ISO 14155 and regional medical device regulations in their filings, referencing ICH E6 only when evaluating drug-device combination products or complying with a named institutional policy.

If FDA still recognizes ISO 14155:2020, may we design the EDC around ISO 14155:2026 dual categorization anyway?

Yes, and doing so is a reasonable global-trial design choice. While the FDA Recognized Consensus Standards database (page last updated 25 May 2026) still lists ISO 14155 Third edition 2020-07 under recognition 2-282, ISO 14155:2026 updates the deficiency definition (usability in Clause 3.19) and places AE/DD conduct in Clause 7.4. Designing eCRFs to the 2026 definition does not mean FDA has recognized the 2026 edition. Keep the recognition citation on 2-282 for U.S. standards-recognition purposes until the database changes.

Where should investigational-device accountability live if the EDC, IRT/RTSM and a paper accountability log disagree?

The trial protocol and Clinical Monitoring Plan must designate the authoritative system of record for device accountability before study initiation. In modern trials, a validated Interactive Response Technology / Randomization and Trial Supply Management (IRT/RTSM) system or an integrated EDC inventory module typically serves as the primary system of record for unit shipments and site receipts. If a discrepancy arises between a physical paper log and an electronic record, the site CRA must issue a data query, verify the physical unit serial number, and document an audit-trailed reconciliation. The locked EDC exposure record must match the designated accountability system before database lock. A well-kept paper log can still satisfy 812.140 even if the EDC is thin; the expensive failure is then statistical reconstructability, not a missing statute.

---

Recommended Reading

Digital Twins and Synthetic Data in Medical Device Validation

Regulatory Digital Health & AI2026-04-30 · 11 min read

Related Guides & Clinical Operations Resources

To further refine your medical device clinical investigation and data governance strategies, explore our detailed operational guides:

• Study-Specific EDC Validation & Part 11 Audit Trail Guide — Detailed IQ/OQ/PQ protocols, GAMP 5 risk categorization, and audit trail inspection readiness.
• ISO 14155:2026 Clinical Investigations for Medical Devices — Comprehensive breakdown of medical device GCP, safety reporting timelines, and dual categorization.
• Two Frameworks: ISO 14155 and ICH E6(R3) Compared — Why medical device GCP diverges fundamentally from pharmaceutical trial rules.
• Safety Reporting in Medical Device Clinical Trials — Understanding reporting clocks for UADEs, US ADEs, and MDR Article 80 notifications.
• Medical Device Trial Master File (TMF/ISF) ISO 14155 Guide — Device-specific essential document management, surgical training logs, and explant records.
• Investigational Device Exemption (IDE) Clinical Trials Guide — Navigating Significant Risk (SR) vs. Non-Significant Risk (NSR) determinations and FDA submission gates.
• Investigational Device Rules Compared Across Four Jurisdictions — Comparing US IDE, EU MDR, Saudi SFDA, and Health Canada clinical trial authorizations.
• Digital Health Technologies (DHT) in Device Investigations — Deciding whether a connected sensor is the investigational article or a measurement tool.
• Medical Device CRO Selection & Due Diligence Guide — Key technical and regulatory criteria for selecting device-specialized clinical partners.
• 21 CFR Part 11 Electronic Records and Signatures — Technical requirements for access control, audit logs, and electronic signatures.
• CSV to CSA Transition Guide for Medical Devices — Applying Computer Software Assurance to production and quality system software without misapplying it to clinical trial EDC.
• Statistical Analysis Plans for Device Trials — Aligning SAP estimands, missing data handling, and version sensitivity analyses.