How to Scope an EHR Integration in One Discovery Call: The Nine Questions

An EHR integration estimate is only as good as the questions asked before it. Teams often arrive at the first call with a vendor name and a deadline, expecting a number back. That number depends on answers nobody has asked for yet, starting with whether the patient or the clinic connects the data and whether anyone has begun the vendor approval process.

Each question below moves either the connection path or the budget and calendar. This article lays out the nine questions we use to scope an EHR integration in one discovery call, with what each answer changes. The last sections show how the answers combine into a recommended connection path.

If you want the theory behind the decision tree first, our EHR integration timeline guide covers it in depth. This piece is the practical companion: the questions themselves, in the order we ask them.

The Nine Questions at a Glance

1. Who connects the data decides between patient-facing and provider-facing integration.

2. The intended use of the data sets the purpose of use, which limits how the data can be reused.

3. The EHR vendor list decides between direct FHIR or proprietary integrations and a gateway or network.

4. A need for write-back narrows the options to direct integration or an integration engine.

5. Clinical notes add a notes workstream and sometimes de-identification.

6. Sandbox access and BAAs set the calendar.

7. The compliance perimeter shapes consent and architecture.

8. Planned scale decides which commercial model fits.

9. The current stack decides whether the estimate covers features or the whole project.

Why One Discovery Call Is Enough to Set the Direction

Two decisions shape almost everything about an EHR integration. A third follows from them. The first is who authenticates, the patient or a provider organization. The second is the legal basis for the data, individual access or treatment. Only then does the connection method come into focus, whether that is a direct FHIR API, a patient-mediated gateway, a network aggregator or an integration engine.

Timeline, cost, coverage and the legal reuse of the data all follow from those answers. A discovery call places the project on that tree with enough confidence that the next conversation is about a specific path and its constraints. Technical detail comes later, in the build plan.

The nine questions below map onto those decisions, plus the practical factors that set the size and pace of the work.

The Nine Questions for EHR Integration Scoping

Who Connects the Data, the Patient or a Provider Organization?

Who connects the data decides whether an EHR integration is patient-facing or provider-facing. If the end user is a patient linking their own records, the integration is patient-facing and runs under the HIPAA individual right of access, usually through a SMART on FHIR patient launch. If the buyer is a clinic or health system and the product runs inside care delivery, it is provider-facing and runs under a treatment relationship.

The simplest way to find out is to ask who clicks "connect." Products can serve both sides over time. The first integration should still commit to one, because the legal basis and the technical path differ. Our breakdown of patient-facing and provider-facing EHR integration covers the differences side by side.

What Will the Data Be Used For?

The intended use of the data sets the purpose of use. The purpose of use then limits what the data can be reused for later. TEFCA, the US national exchange framework, defines six exchange purposes. Two matter most here: Treatment and Individual Access Services. Records pulled under a treatment purpose are tied to that purpose and hard to repurpose. Records a patient authorizes through individual access have a cleaner basis for product use where the patient consents.

The question matters most for teams that plan to train models on clinical data. It is also the one most often answered too late. We cover the details in buying clinical data for AI. During scoping we frame the tradeoffs, while the client's counsel makes the final call.

Which EHR Vendors or Systems Matter?

A named list of EHR vendors points toward direct integrations, while an open-ended list points toward a gateway or a network. With named vendors, the deciding factor is whether each one exposes a FHIR R4 API or a proprietary one. With "whatever our users have," one connection that covers many systems usually beats building each vendor separately.

FHIR work compounds. The first FHIR vendor is the investment, while each one after it reuses most of the SMART on FHIR authorization flow and the resource handling. Every proprietary system starts from scratch. We explain why in FHIR vs. proprietary API, and it is the single biggest cost multiplier we see in direct integrations.

Does the Product Need Write-Back or Read-Only Access?

Write-back into the EHR narrows the choice to a direct integration or an integration engine built for bidirectional workflows. Read-only access opens the widest set of options, including patient-mediated gateways and network aggregators. Orders and notes are the usual write-back cases.

The difference is easy to miss when teams talk about "middleware" as one category. A record-retrieval network and a workflow integration platform solve different problems at different price points, as we lay out in EHR connection paths compared.

Do You Need Clinical Notes and How Complete Must They Be?

Clinical notes are the least predictable part of an EHR integration, so their coverage needs a decision at scoping. Structured fields such as problems, medications, labs and allergies follow the USCDI baseline and arrive in predictable shapes across certified EHRs. Notes are where the value usually sits for AI use cases. They are also where coverage varies most, because some arrive inline with the record while others sit behind references that cannot be fetched or are never exposed over the API.

If the use case needs de-identified notes, that becomes a separate workstream with OCR and free-text scrubbing, far bigger than redacting structured fields. Deciding notes coverage at scoping is much cheaper than discovering the gap mid-build. Our article on clinical notes in EHR integrations covers what to expect.

Do You Already Have Sandbox Access or BAAs?

Vendor access and Business Associate Agreements set the calendar of an EHR integration more than the build does. Production access to a major EHR vendor runs through its developer program and app review. Some vendors respond in days while others take weeks. BAAs need to be in place with the vendor and every subprocessor touching PHI before any record moves.

Many projects start with no sandbox access anywhere, which means the approval clock starts on day one. We begin vendor outreach immediately in those cases. The part of the timeline we control is infrastructure: our HIPAA infrastructure and security work uses open-source HealthStack modules to get a compliant baseline running in days.

What Is the Compliance Perimeter?

The compliance perimeter decides which consent flows and safeguards the integration has to support. HIPAA is the default for US clinical data. State rules and international users widen the perimeter. So does a consumer consent model, because a patient-facing app that asks users to share records for a product feature needs a consent flow designed for that purpose from the start.

Getting this on the table early keeps the architecture from being redesigned around a requirement that surfaces during a security review. Our guide to what to prioritize in healthcare compliance helps teams decide what to settle first.

What Scale Are You Planning For?

Planned scale decides which commercial model fits an EHR integration. A handful of provider organizations and a large consumer base call for different economics. Network aggregators are priced for provider workflows, with an upfront commitment and per-query fees that fit a limited number of organizations. A gateway or a direct FHIR integration fits a patient-facing product with many users far better.

Scale also changes how much monitoring and maintenance the integration needs after launch, since EHR vendors change their APIs on their own schedule.

What Is the Current Stack and Infrastructure?

The current stack decides whether an EHR integration can be estimated as a whole project or only feature by feature. It is often unknown on the first call. When we do not yet know the codebase or the data model, we estimate individual features. That keeps the estimate honest until a discovery workshop fills in the rest, before anyone commits to a fixed scope.

When the scope is still uncertain, we usually recommend time and materials over a fixed price, so the number can follow what the first sandbox and vendor review reveal.

From Answers to a Connection Path

Once the nine answers are on the table, most projects fall into one of four patterns:

Patient-facing, broad coverage, read-only, data for product or AI use points to a patient-mediated gateway, where one API covers a large catalog of health systems.

Provider-facing work inside care delivery that needs broad record retrieval points to a network aggregator or QHIN.

Provider-facing with bidirectional workflows across many organizations points to an integration engine.

Named vendors with full control or write-back points to direct FHIR integrations, FHIR-first, with proprietary systems scoped as separate line items.

Real products sometimes combine paths as they grow. A team might start with a gateway for fast patient-facing coverage, then add direct integrations with the vendors that need write-back. The first integration still commits to one path. The scoping call is where that choice gets made.

Caily shows how a clear answer to the first question shapes the work. For Caily, a patient-facing family care platform, we laid the groundwork for integration with seven leading EHR systems, Epic and Cerner among them, so care recipients will be able to pull in their existing health data. The Caily case study covers the platform and its EHR connectivity.

What an EHR Integration Scoping Call Produces

An EHR integration scoping call ends with a recommended connection path and a clear next step. Along with the path, we produce a current-state map of the client's product and data, plus the list of FHIR resources and notes the use case needs. We also write a short compliance and purpose-of-use note that flags the open questions for the client's counsel.

The next step is either a scoped estimate with a defensible range or, when the stack or vendor list is still open, a discovery workshop with time-and-materials pricing until the scope firms up. Either way, the client leaves knowing which decisions are already made and who owns the ones still open.

If you are planning an EHR integration and want to work through these questions with a team that has built healthcare integrations serving 1M+ patients, book a scoping call with us.