How to choose an EDC system for medical device clinical investigations

April 27, 2026 ░░░░░░

If you have already concluded that a generic or pharma-built EDC is the wrong tool for a medical device investigation, this guide is for the next step: running the evaluation, structuring the vendor conversations, and building the internal case for the system you want.

If you are still working through why pharma EDC platforms create problems for device teams, our EDC systems guide for medical device manufacturers covers that ground first. When you are ready to evaluate vendors, come back here.

7 criteria that separate purpose-built device EDC from everything else

General EDC evaluation checklists are written for pharmaceutical buyers. The criteria below are specific to device investigations and will surface the gap between a pharma-adapted platform and one built natively for ISO 14155.

1. Pre-built ISO 14155 validation documentation

The system should arrive with complete validation documentation covering ISO 14155:2020 requirements. This is not the same as claiming compliance. Ask every vendor to show you the actual validation package in the first call. A purpose-built device EDC will have it ready. A pharma platform adapted for devices will ask you to scope a custom validation engagement, which means your team absorbs that cost and timeline.

Pass signal: vendor produces a complete IQ/OQ/PQ package covering ISO 14155 on request, at no additional cost.
Red flag: vendor says validation documentation is available as a paid add-on, requires a project scoping call, or is described as something you build together.

2. Device-specific eCRF structures, not pharmaceutical defaults

Device studies require per-procedure visit structures, device deficiency fields linked directly to adverse event reporting, and device identification data capture. These are not configuration options on a pharma platform. They are structural requirements that a pharma eCRF template will not accommodate without significant custom build.

Ask vendors to show you an eCRF built for a device investigation, not a generic demo. The difference will be visible immediately. See our eCRF completion guidelines and eCRF design guide for device studies for what good looks like.

Pass signal: vendor shows a device study eCRF with native device deficiency reporting and per-procedure visit logic without custom configuration.
Red flag: vendor shows a generic study template and describes device-specific fields as a configuration engagement.

3. Mid-study protocol amendments without re-validation

Device protocols change mid-study more often than pharma protocols. The EDC needs to handle this without triggering a full re-validation cycle. Ask specifically: if we add an endpoint or change a visit structure two months into enrollment, what does that process look like and how long does it take?

Pass signal: vendor describes a workflow your clinical team can manage, with a clear process for documenting the amendment without stopping enrollment.
Red flag: any answer involving IT tickets, implementation sprints, or a new validation cycle for field-level changes.

4. Direct sponsor monitoring access, not CRO-routed

ISO 14155 places oversight responsibility with the sponsor. That responsibility is difficult to fulfill if your access to study data depends on a CRO producing a report. The platform should give you live visibility into query status, protocol deviations, site performance, and data completeness directly from your sponsor account, as data is entered.

Ask vendors to show you the sponsor monitoring dashboard and explain how access is separated from CRO access. This should not require configuration or a premium tier.

Pass signal: sponsor account has live monitoring views that are structurally separated from site-level and CRO access, available in the standard offering.
Red flag: real-time access is described as an enterprise feature, or monitoring is described as something your CRO manages on your behalf.

5. Unconditional data export at any point

You should be able to export your complete dataset in any standard format, at any point in the study, at no additional cost. Ask every vendor this question directly before you see a contract: what happens to my data if we end the relationship mid-study? If the answer involves fees, a waiting period, a proprietary format, or CRO intermediation, that is a lock-in risk worth quantifying before you sign.

Pass signal: vendor confirms in writing that full dataset export is available to the sponsor at any time in standard formats (CSV, SAS, SPSS) at no additional cost.
Red flag: data export provisions in the contract reference the CRO, require additional fees, or restrict format options.

6. Study setup in days, not quarters

For lean device teams without dedicated clinical ops staff, implementation time is a real constraint. A purpose-built device EDC should be able to get your first study running in one to three weeks. Ask specifically: what does onboarding look like for a first study, who runs it, and what is your typical time from contract signature to first subject enrolled?

The answer should include clinical operations specialists running the onboarding, not implementation engineers who need you to explain what ISO 14155 requires.

Pass signal: vendor references specific timelines from recent comparable studies and names the clinical background of the onboarding team.
Red flag: implementation is described as a project with a project manager, a scoping phase, and a timeline measured in months.

7. Pre-market and PMCF from the same platform

Under EU MDR, PMCF obligations do not end at market clearance. If your EDC cannot support PMCF surveys, registries, and long-term follow-up from the same interface where you ran your pre-market investigation, you will build clinical data fragmentation into your program from the start.

Pass signal: vendor shows a live PMCF study alongside a pre-market investigation in the same platform, with no mode switching or separate license required.
Red flag: PMCF is described as a separate module, a separate product, or something typically handled by a different tool.

The full vendor question bank

Use these in evaluation calls. The pass/fail signals above give you the frame. These questions get you the specific answers.

On compliance and validation:

  • Can you share your ISO 14155:2020 validation documentation today, before we proceed to a demo?
  • How does your system handle SADE and device deficiency reporting natively?
  • What validation work, if any, is required from the sponsor before go-live?
  • How do you handle 21 CFR Part 11, GDPR, and ISO 14155 for studies spanning US and EU sites?

On eCRF design and study setup:

  • Can our clinical team build and modify eCRFs without a data manager or programmer?
  • Walk me through what happens when we need to add a visit or change a field two months into enrollment.
  • What was your median time from contract to first subject enrolled for studies comparable to ours in the last 12 months?
  • Who runs onboarding? What is their clinical background?

On data access and ownership:

  • Can you show me the sponsor monitoring dashboard in the demo?
  • How is sponsor access structurally separated from CRO access in your permission model?
  • What is your contractual position on dataset export if we terminate the relationship mid-study?
  • In what formats can we export, and is there any cost associated?

On long-term fit:

  • Show me a PMCF study running on the same platform as a pre-market investigation.
  • Can we carry eCRF templates and study configurations from one study to the next?
  • What device-specific features are on your roadmap in the next 12 months?

How to build the internal case

Vendor evaluation is the easy part. Getting budget approved when your organization has existing EDC contracts, a CRO relationship that includes EDC, or a finance team that does not understand why clinical software matters requires a different kind of work.

Start with a cost-of-status-quo calculation. Pull real numbers from your last study:

  • How many weeks elapsed between protocol finalization and first subject enrolled?
  • How many team hours were spent on data cleaning, query resolution, and export preparation before database lock?
  • Were there compliance gaps that required remediation, and what did that remediation cost in time and external fees?
  • If you used CRO-bundled EDC, what were the data export terms and did you actually have unrestricted access to your dataset after study close?

Those numbers are your baseline. A pharma EDC that costs less per study license can easily cost more in total once you account for configuration, custom validation, data management overhead, and any lock-in on your own dataset. Loop Medical, a Class II device company that had been managing international studies on paper, set up a new study in a couple of weeks without working on it full time. In their words, real-time data access removed headaches from data collection and saved both time and money.

Frame the ask around risk, not software. The people approving this decision are not evaluating EDC platforms. They are evaluating whether the current approach creates regulatory, timeline, or data integrity risk. Your job is to make that risk visible and quantifiable. Compliance gaps that surface at a notified body review or an FDA inspection are not abstract. They have documented remediation costs. Use them.

Build a transition plan before the approval conversation. Your stakeholders will want to know: what happens to our current studies, how long does migration or parallel running take, and what does the vendor provide to support it. A purpose-built device EDC should help you build this plan as part of the sales process. If a vendor cannot give you a clear transition framework before you sign, that is a signal about what post-signature support will look like.

Run a structured evaluation across at least two vendors. Most organizations require documented vendor evaluation before approving a significant software purchase. Use the question bank above to score vendors consistently. The right MedTech EDC will distinguish itself quickly on validation documentation readiness, ISO 14155 compliance depth, and study setup time. Document the scoring. It makes the approval conversation faster and gives you a defensible paper trail if the decision is ever revisited.

Next step

Greenlight Guru Clinical is an EDC built specifically for medical device clinical investigations. It covers the full investigation lifecycle from a single platform: pre-market studies, PMCF surveys and registries, and long-term follow-up. ISO 14155 and 21 CFR Part 11 validation documentation is included. Sponsor monitoring access is direct and real-time. Dataset export is unconditional. Onboarding is run by clinical operations specialists. Most teams go from contract to first subject enrolled in under three weeks.

Get a demo of Greenlight Guru Clinical and bring your study design. We will show you how it runs on the platform.

Páll Jóhannesson, M.Sc. in Medical Market Access, was the founder and former CEO of Greenlight Guru Clinical (formerly SMART-TRIAL) and is currently the EVP of Europe at Greenlight Guru.

BONUS RESOURCE: Change Impact Analysis Checklist
Download Now
Checklist for Change Impact Analysis - slide-in cover-1
Search Results for:
    Load More Results