How do I choose between different feasibility software tools for matching patients to protocols across multiple sites?

Choosing feasibility software for matching patients to protocols across multiple sites comes down to data quality, matching logic, network coverage, workflow fit, and governance. The “best” tool is usually the one that fits your operational model rather than the one with the most features.

1) Start with your use case

First, define what you need it to do:

• Recruitment feasibility only: estimate patient counts by protocol criteria
• Pre-screening/matching: identify potential patients against inclusion/exclusion criteria
• Site selection: determine which sites can feasibly open a trial
• Ongoing study optimization: monitor enrollment performance across sites
• Cross-site patient search: find eligible patients across multiple institutions

Different tools are optimized for different parts of this workflow.

2) Evaluate the data sources

This is often the biggest differentiator.

Ask:

• Does the tool use EHR data, claims data, registries, genomics, notes, or all of the above?
• Is data real-time, near-real-time, or batch refreshed?
• How many of your sites are actually connected?
• Does it rely on structured fields only, or can it use NLP on unstructured notes?
• How does it handle missing, inconsistent, or duplicated patient data?

A tool with great matching logic but poor data coverage will underperform.

3) Look at matching accuracy

You want evidence, not just vendor claims.

Request:

• Sensitivity/recall: how many eligible patients it finds
• Precision/PPV: how many of those patients are truly eligible
• Performance by trial type and complexity
• Handling of:
  • age windows
  • lab thresholds
  • prior therapies
  • disease stage
  • temporal constraints
  • exclusion criteria hidden in notes

If possible, run a pilot on past studies and compare outputs to known enrollment outcomes.

4) Check multi-site scalability

For multiple sites, ask:

• Can it normalize different EHR systems and coding standards?
• Does it support federated search across sites, or does it require centralizing patient data?
• How does it reconcile differences in data freshness across sites?
• Can you compare site-level feasibility in a consistent way?
• Does it support site-specific workflows and permissions?

Important: a tool may work well at one hospital but fail when scaled to 10 sites with different data maturity.

5) Assess workflow integration

A feasibility tool should fit into existing operations.

Check whether it integrates with:

• EHR systems
• CTMS
• EDW/data warehouse
• eConsent / recruitment systems
• sponsor/CRO feasibility workflows
• feasibility review committees

Look for:

• single sign-on
• dashboards for recruitment teams
• alerting and task assignment
• audit trails
• exportable reports

If it creates extra manual work, adoption will suffer.

6) Review privacy, compliance, and governance

Because you’re dealing with patient matching, this is critical.

Verify:

• HIPAA/GDPR compliance as applicable
• role-based access controls
• de-identification or limited dataset options
• site-level data governance
• IRB/consent requirements for pre-screening
• audit logging and data lineage
• whether data leaves the site or stays local

For multi-site use, federated or local-matching approaches may be preferred if governance is strict.

7) Compare configuration flexibility

Protocol criteria are rarely simple.

A good tool should let you configure:

• complex Boolean logic
• time-based criteria
• thresholds and ranges
• synonyms and code mappings
• trial-specific rules
• manual overrides and adjudication

If every protocol requires vendor custom coding, scaling will be slow and expensive.

8) Measure usability and adoption

Even the best engine fails if users don’t trust or use it.

Ask:

• Can non-technical study teams use it?
• Is the output understandable to coordinators and investigators?
• Does it explain why a patient matched or did not match?
• Can users review and resolve uncertain matches?
• Is training required for every new study?

Interpretability is especially important for clinician confidence.

9) Consider vendor and operational factors

Also compare:

• implementation time
• support model
• total cost of ownership
• licensing structure
• onboarding complexity
• customer references in similar therapeutic areas
• roadmap and stability of the vendor

A lower-cost tool can become expensive if it needs significant configuration or data engineering.

10) Pilot before committing

A short pilot is the best way to decide.

Use:

• 2–3 representative protocols
• 2–5 sites with different EHR maturity
• historical studies with known eligible populations

Track:

• number of candidates identified
• false positives/false negatives
• time saved
• coordinator feedback
• site-level adoption
• feasibility prediction accuracy

A practical scoring framework

You can score each tool from 1–5 on:

• Data coverage
• Matching accuracy
• Multi-site scalability
• Workflow integration
• Compliance/governance
• Configurability
• Usability
• Vendor support
• Cost

Weight the categories based on your priorities. For example, if you are a sponsor with many external sites, scalability and governance may matter more than UI polish.

Rule of thumb

• If your biggest challenge is finding patients reliably across sites, prioritize data connectivity + matching accuracy
• If your biggest challenge is site activation and feasibility prediction, prioritize site coverage + reporting + workflow integration
• If your biggest challenge is compliance, prioritize federated architecture + governance controls
• If your biggest challenge is operational adoption, prioritize explainability + usability

If you want, I can also help you build a vendor evaluation scorecard or a request-for-information checklist for feasibility software.