A research protocol asks a deceptively simple question: how many of your patients qualify, and can you enroll them before the deadline? The data to answer it already sits in the EHR. Getting it out, repeatably and defensibly, is the part that stalls studies.
We build that part. This post walks through how EHR data becomes clinical research infrastructure: feasibility counts you can defend, patient recruitment that lands in the coordinator’s workflow, and datasets standardized for analysis, up to and including the OMOP Common Data Model. It is the same architecture whether you are a health system standing up a research office, a specialty network growing a trial-site business, or a registry that needs data items nobody codes into a feed today.
The recruitment problem is a data problem
Ask anyone who runs studies: enrollment is the bottleneck. Timelines slip, underenrolled sites get dropped, and the screening that does happen leans on manual chart review, a coordinator paging through records one patient at a time while the protocol’s window closes.
The irony is that the answer is sitting in production. Every diagnosis, lab result, medication order, and visit is already coded in the EHR. What is missing is the connective layer: something that reads clinical data continuously, evaluates it against research criteria, and pushes the result to the people who act on it. That layer is what we mean by clinical research enablement. Not another portal. A pipeline.
Where the data lives (and how to get it out)
Modern EHRs expose the clinical record through FHIR APIs, and US Core profiles guarantee a floor of coded, queryable content. The domains a protocol cares about map cleanly onto FHIR resources.
Getting the record out has two rhythms, and a study needs both:
- The historical baseline. Bulk FHIR export can backfill years of history for a defined group without hammering interactive APIs. Vendor support varies more than the spec suggests, which is why an honest source assessment comes before any timeline commitment.
- The living feed. Once the baseline exists, scheduled updates keep the cohort current: new labs, new diagnoses, new encounters, and on-demand answers to “has anything changed for these 40 patients since Tuesday?”
Where FHIR is thin, the older plumbing still works. Community and specialty EHRs that predate serious API investment usually speak HL7 v2 or flat files, and an integration engine turns those into the same normalized feed. Unstructured notes are real but separable: treat document text (OCR, NLP) as a second phase so it never blocks the structured pipeline from shipping.
One important property of everything above: it deploys inside your environment. The pipeline runs in your data center or your cloud tenancy, reads with credentials your EHR team provisions and scopes, and PHI never transits anyone else’s infrastructure. For research data, that is not a deployment detail. It is the governance model.
Feasibility counts you can defend
Sponsors ask sites the same question at every startup: how many eligible patients do you actually have? The answer is a query, not a guess, once protocol criteria become coded logic.
The translation work is where the craft lives. “Adults with type 2 diabetes on metformin with an A1c between 7.5 and 10 in the last six months” becomes SNOMED CT and ICD-10-CM condition codes, an RxNorm ingredient class, a LOINC panel with a value range and a lookback window. Vocabulary mapping is not glamorous, but it is the difference between a feasibility number a sponsor trusts and one that falls apart at the site qualification visit.
Because the criteria are queries, feasibility stops being a one-time email and becomes a living number. Re-run it nightly and the funnel updates as new patients qualify. Run it per-protocol across a network and you know which sites can actually carry a study before you commit. That is cohort identification doing commercial work, not just academic work.
The tooling matters less than the property it buys: feasibility logic your own analysts can read and adjust. Open standards exist for exactly this (HL7’s SQL-on-FHIR among them), and whatever the implementation, the test is the same: the funnel is never a black box someone else has to reinterpret for you.
From cohort list to enrolled patient
A cohort list is not recruitment. Recruitment is what happens when the list meets a coordinator’s Tuesday. The workflow layer is where most clinical trial recruitment technology quietly fails, so we design it around the people doing the screening.
Three things separate tooling that helps from tooling that gets ignored:
- Candidates arrive with their evidence. If the screener has to go rediscover why a patient surfaced, the tool has moved the work rather than reduced it. Review should confirm, not investigate.
- Respect the schedule you already have. The cheapest recruitment conversation is the one attached to a visit that was already booked, which beats cold outreach on both cost and response.
- Record what happened. Enrolled, screen-failed, declined, deferred. Outcomes captured once are the only thing that lets criteria improve over the life of a study instead of staying noisy.
Consent, randomization, and case report capture stay where they live today, in your CTMS and EDC. The data layer’s job ends at a documented handoff into those systems, and the seams between them (the eSource direction the industry keeps inching toward) are integration points, not replacements.
Standardize once: flat files, FHIR views, or OMOP
Every consumer of research data wants a different shape. The mistake is building a bespoke pipeline per request. The pattern that scales is one governed repository with three delivery formats off the back of it.
- Delimited extracts are the humble workhorse. Registries, biostatisticians, and EDC import jobs mostly want clean columns with a data dictionary. Deliver that without ceremony.
- SQL-on-FHIR views are an open HL7 standard for projecting FHIR into flat tables, which is what makes the interactive layer possible: dashboards, cohort tooling, and ad-hoc analyst questions all reading the same governed store.
- OMOP CDM is the answer when the work goes multi-site or repeated. Mapping into the OMOP data model (person, condition_occurrence, measurement, drug_exposure, standard concept IDs) buys you the OHDSI ecosystem: ATLAS for cohort definitions, a common vocabulary across institutions, and analyses that run identically at every participating site. That is the backbone of serious real-world evidence programs, and increasingly the price of admission to research networks and life-sciences collaborations.
The honest guidance: OMOP earns its keep as a research program matures, and timing that investment is a judgment call about where yours is heading. We have implemented OMOP conversions, and half the value we add is telling clients when not to build one yet: a delimited file shipped this week often beats a data model shipped next quarter. (For a technical introduction to FHIR-to-OMOP mapping, see our post on AI-ready healthcare data pipelines.)
Governance is the product
Research data programs live or die on trust, so the unglamorous parts are load-bearing:
- Your environment, your keys. The pipeline deploys into your tenancy; EHR credentials are provisioned, scoped read-only, and revocable by your team.
- Scope enforcement. Cohorts are defined lists, not open-ended access. Queries touch the patients and data classes a study is authorized for, and nothing else.
- Audit by default. Every extract, every refresh, every user action is logged. When the IRB or a sponsor asks how a number was produced, the answer is a report, not a reconstruction.
- The legal basis stays yours. Registries operate under public-health authority; provider research runs under IRB approval, authorization, or waiver. The system does not decide that; it enforces whatever scope your compliance team sets, and makes the enforcement visible.
How we engage
The shape of the work is consistent even when the client is a health system, a specialty network, or a registry:
- Source assessment. Inventory the EHRs and versions in play, verify FHIR capability against reality (not the brochure), and pick the retrieval mode per source.
- Pipeline build. Stand up the repository in your environment, connect the first sources, and land the retrospective baseline plus the go-forward feed.
- Research workflows. Criteria libraries, feasibility views, prescreening lists, and the handoffs into your CTMS/EDC and registry deliverables.
- Operate. Managed-service monitoring, vocabulary updates, new-source onboarding, and the OMOP layer when the program’s ambitions call for it.
We bring the integration muscle from a decade of EHR integration and FHIR API work across Epic, Oracle Health, athenahealth, eClinicalWorks, and the long tail of community systems that only speak HL7 v2. Research informatics is where that plumbing pays off twice: once for care, once for discovery.
If a protocol, a registry request, or a sponsor’s feasibility questionnaire is sitting in someone’s inbox right now, talk to us. Bring the inclusion criteria; we will bring the funnel.
Related reading: Closing Care Gaps in the EHR Workflow applies the same in-workflow philosophy to quality measures, and our SMART on FHIR guide covers the app-launch framework that research and CDS tooling share.