EHR access agreements negotiated for clinical trial feasibility purposes look nothing like the standard business associate agreements a CRO legal team handles routinely. The HIPAA framework is still present, but it intersects with a different set of technical requirements — FHIR R4 authorization scopes, data use purpose restrictions, SMART on FHIR application registration, and data residency obligations — that most CRO attorneys have never encountered in a BAA context. Getting these negotiations wrong doesn't just delay the agreement; it can produce an access architecture that limits what data you can actually query, making the feasibility run slower or less complete than intended.
This piece walks through the core technical and legal concepts a CRO team needs to understand before entering EHR access negotiations for a patient matching engagement.
What FHIR R4 Actually Is — and Why It Matters for Your Agreement
HL7 FHIR (Fast Healthcare Interoperability Resources) Release 4 is a data exchange standard published by HL7 International that defines a set of resource types — Patient, Condition, Observation, MedicationStatement, Encounter, and others — and a RESTful API mechanism for querying them. It is not a product or a vendor platform; it is a specification that EHR systems implement to varying degrees of completeness.
For a CRO negotiating EHR access, FHIR R4 matters for two reasons. First, the 21st Century Cures Act (enacted 2016, ONC final rule effective 2022) required most certified EHR technology to support FHIR R4-compliant API access, which means the technical capability generally exists at health systems that run certified EHR platforms. Second, access to FHIR APIs at a health system typically requires the third-party application — your matching platform — to be registered as a SMART on FHIR application within that health system's authorization server. That registration process is not automatic, and it is not the same as signing a data use agreement.
SMART on FHIR is the authorization framework layered on top of FHIR R4. It defines OAuth 2.0 scopes that specify precisely what data a registered application can read. An application registered with scope patient/Condition.read can read Condition resources; it cannot read Observation resources unless that scope is also granted. The specific scopes your matching platform needs — and the scopes the health system is willing to grant — must be explicitly negotiated and documented. This is a technical requirement embedded in your legal agreement, and it cannot be adequately handled by a standard HIPAA BAA template alone.
The Data Use Purpose Restriction: Why "Clinical Trial Feasibility" Needs Its Own Definition
Health systems that grant FHIR R4 access for third-party applications typically restrict data use to a defined purpose. That purpose restriction is enforceable — using access granted for one purpose (feasibility matching) to perform another function (protocol-specific recruitment, commercial analytics, or any other use) violates the agreement and triggers breach provisions under HIPAA's Privacy Rule at 45 CFR 164.514 and the access agreement itself.
The problem that CRO legal teams sometimes encounter is that "clinical trial feasibility" is not a standard defined purpose category in most health system data use agreement templates. Health systems are more accustomed to granting data access for treatment, payment, or healthcare operations purposes, or for IRB-approved research. Feasibility matching occupies an ambiguous space: it uses patient EHR data to evaluate whether a study could be conducted, which is preparation for research rather than research itself under the 45 CFR Part 46 Common Rule definition.
This ambiguity has practical consequences. Some health systems will require an IRB determination — specifically a finding that the feasibility matching activity does not constitute human subjects research — before executing a data access agreement. Others will require a limited data set agreement rather than a full BAA, since the matching output uses de-identified cohort identifiers rather than direct patient identifiers. Getting clarity on which pathway a health system requires before drafting the agreement saves 4–8 weeks in the back-and-forth cycle.
We're not saying that health systems are being unreasonable in requiring this clarity — the regulatory distinctions are genuinely complex, and a health system's privacy office is doing its job by asking the question. The point is that a CRO needs to enter the negotiation prepared to explain precisely what data is accessed, what the output is, and how patient identifiers are handled, rather than presenting a standard BAA and hoping for the best.
De-Identification Architecture: What the Agreement Needs to Specify
HIPAA's Privacy Rule at 45 CFR 164.514 provides two methods for de-identification: expert determination (§164.514(b)(1)) and the safe harbor method (§164.514(b)(2)). The safe harbor method requires removal of 18 specific identifiers including names, geographic data smaller than state level, dates other than year for individuals over 89, and 13 other categories. If the cohort output produced by your matching run is a de-identified list under safe harbor or expert determination standards, it is no longer PHI and the downstream handling obligations change substantially.
Whether your matching platform produces de-identified output, a limited data set (which retains dates and three-digit zip codes but removes direct identifiers), or identified data is not just a technical question — it determines what your data use agreement needs to say and what protections apply. This should be specified explicitly in the access agreement: what data fields the platform reads, what it retains temporarily for matching logic, and what appears in the output delivered to the CRO. Health system privacy offices will ask these questions directly; having precise answers documented in the agreement protects both parties.
For more on how Cohortbridge's data flow handles this specifically, see the patient privacy and data handling page.
EHR Vendor-Specific Access Pathways
The mechanics of FHIR R4 access vary by EHR vendor, and this affects negotiation timelines and technical requirements.
Epic (MyChart / FHIR R4): Epic's SMART on FHIR platform is accessible via its App Orchard or through direct registration with the health system's Epic instance. For population-level queries (returning multiple patients matching criteria, rather than a single patient's record), Epic requires backend services authorization rather than the user-facing SMART launch. Backend services authorization requires a separate registration process, typically reviewed by both the health system and Epic, and may require a formal agreement with Epic. This is distinct from the patient-facing or provider-facing SMART apps that many health system IT teams default to when they hear "FHIR R4 access."
Oracle Health (formerly Cerner): Oracle Health provides FHIR R4 access through its Millennium platform with similar SMART authorization requirements. The code registration process differs from Epic's App Orchard model; population-level access requests go through Oracle Health's developer platform, and the health system's IT team configures access scopes locally. Timeline expectations are similar to Epic — 4–8 weeks for access configuration after the data use agreement is executed.
Athenahealth, eClinicalWorks, MEDITECH: These systems implement FHIR R4 to varying degrees of completeness for population-level queries. Some offer comprehensive API coverage for the resources most relevant to eligibility matching (Condition, Observation, MedicationStatement); others have gaps that may require supplemental structured export files (HL7 v2 ADT, CCD, or custom exports). This affects what criteria can be matched from the API versus what requires a supplemental data feed — which should be addressed in the access agreement's scope section.
Timeline Expectations: 4 Weeks vs. 4 Months
A CRO team that approaches an EHR access negotiation with the right documentation — a precise description of the matching platform's data access pattern, the specific FHIR R4 resources and scopes required, the de-identification approach, and a clear statement of purpose — can typically complete the legal and technical access process at a health system in 4–6 weeks. This assumes the health system already has an established FHIR R4 API infrastructure and an IT team familiar with SMART application registration.
A CRO team that presents a standard BAA and expects the health system to figure out the technical details will spend 3–4 months in back-and-forth, often cycling through multiple drafts as the privacy office, IT team, legal counsel, and research compliance office each raise questions that the original agreement didn't address.
The difference is almost entirely preparation. The questions health systems ask are predictable: What data does the application access? What does it retain? Where does it go? Who sees the output? How is patient privacy protected? A CRO that can answer all of these with specificity — in the initial agreement package rather than in response to redlines — compresses the negotiation timeline materially.
Practical Preparation for the Negotiation
Before entering EHR access negotiations for a patient matching program, a CRO team should be able to answer the following with specificity, in writing:
- Which FHIR R4 resources does the matching platform query? (Specify: Patient, Condition, Observation, MedicationStatement, etc.)
- Does the platform require population-level search (returning lists of patients matching criteria) or single-patient record access? Backend services authorization or SMART user-facing launch?
- What patient identifiers, if any, are transmitted outside the health system's network? Or does the platform operate on-premise, with only de-identified cohort IDs transmitted?
- What is the de-identification standard applied to the output — safe harbor, expert determination, or limited data set?
- Is a Business Associate Agreement sufficient, or does the health system require a Data Use Agreement for a limited data set under 45 CFR 164.514(e)?
- Has an IRB determination been made that the feasibility matching activity does not constitute human subjects research under 45 CFR 46.102(e)?
These are not questions that emerge only in adversarial negotiations. They are standard due diligence questions from a health system privacy office doing its job under the HIPAA Privacy Rule. A CRO that can address all of them at the outset of the negotiation is a credible counterparty — and that credibility visibly accelerates the process.
Cohortbridge's EHR integrations process includes pre-negotiation documentation packages designed to address exactly these questions for the most common EHR environments. For CROs running multiple simultaneous feasibility programs across different health systems, the ability to present a consistent, well-documented access request architecture is the most reliable way to keep data access timelines from becoming the critical path.