EHR Integration Services: Scope, Standards and Partners

In 2025, 76% of U.S. non-federal acute care hospitals reported engaging in all four core electronic exchange activities (finding, sending, receiving and integrating patient health information), up from 23% in 2014, according to ONC's hospital exchange statistics. The exchange that does happen still varies by site, by vendor and by version, which is why connecting a product to a hospital EHR takes engineering and approvals rather than an API key.

EHR integration services are the work of getting a product into a live clinical system and keeping it correct there. That covers scope confirmation, interface design, build against a named standard, vendor program onboarding, testing, go-live and post-launch monitoring, and the sequence matters because each step gates the next.

Below are the standards behind each data flow, the phases that stretch a schedule, the choice between in-house work, a partner and a platform, and the questions that separate a partner who has run production interfaces from one who has only run sandbox demos.

What EHR integration services cover and which standard each part uses

Your product arrives at an organization that already runs a production clinical system, with a version number, a configured interface engine and a team whose job is deciding what connects to it. By 2024, 91% of office-based physicians reported using a certified EHR, and another 4% ran a non-certified system, per the ONC data brief on physician EHR adoption. The digitization argument is settled. What remains is the connection work.

The estimate behind an integration quote is really a scope document. Before the first interface is built, three decisions set most of the schedule: whether the product needs read-only or write-back access, how many sites and EHR instances it must reach, and how each health system's security review treats a newly connected application. Write-back raises the review burden because the product touches the chart rather than reading it. A second site on a different EHR version restarts the approval path even when the interfaces look identical. Teams that lock these decisions early avoid the mid-project rescoping that stretches timelines more than the build itself.

Once scope is fixed, each service maps to a specific standard. The table shows which one carries each data flow.

Service	Standard or format	Typical use	Data direction
Admissions, discharges and transfers	HL7 v2 ADT messages (A01, A08) over MLLP	Patient demographics and encounter status feeds	Read
Lab and observation results	HL7 v2 ORU^R01 messages	Results delivered to downstream applications	Read
Orders	HL7 v2 ORM^O01 messages	Order messages sent to or received from the EHR	Read or write, depending on interface
Patient, encounter, observation and medication data	FHIR R4 resources constrained to US Core	On-demand queries for individual records	Read, with some write
Clinician-facing app launch and identity	SMART App Launch (OAuth 2.0 with OpenID Connect)	Launching an app in EHR context with scoped access	Read
Population or cohort extraction	FHIR Bulk Data Access ($export)	Asynchronous NDJSON file exports	Read
Clinical summaries and documents	C-CDA document templates	Discharge summaries and care summaries	Read or exchange
Eligibility and claims	X12 270/271 eligibility and 837 claims	Payer eligibility checks and claim submission	Exchange with payers
Vendor program onboarding	Vendor-specific developer program requirements	Sandbox access, app registration and production approval	Not a data exchange

Every row is a separate interface with its own specification, test plan and approval path. Row count is what a partner is really costing out when you ask for an estimate, and it's the number that changes when a health system adds a second EHR at a newly acquired site.

Where HL7 v2 still carries the work

Most event traffic inside hospitals remains HL7 v2 over MLLP. ADT messages (A01 for an admit, A08 for an update) tell your product that a patient exists, which encounter is open and where they are. ORU^R01 delivers results, one observation per OBX segment with local codes and units. ORM^O01 carries orders. These messages are pipe-delimited, versioned (2.3 and 2.5.1 both remain in service), and depend on acknowledgment semantics: your listener returns an ACK or a NAK, and a NAK sends the sender's queue back into retry. Assume at-least-once delivery and make your write path idempotent.

The cost sits in the local dialect. Two hospitals on the same vendor and the same version will classify patients differently, use different codes for the same lab test and fill optional segments inconsistently. That dialect problem is why site count belongs in the estimate: a second hospital still needs its own mapping tables, its own test pass and its own approval, regardless of how similar the feed spec looks on paper.

FHIR R4 queries and the profile that constrains them

FHIR R4 with US Core constraints is what most health systems expose for on-demand reads: Patient, Encounter, Observation, MedicationRequest and the searches defined around them. A successful read in a vendor sandbox proves little about production, because implementations are not uniform. Vendors ship different FHIR versions, and two systems on the same version can still populate the same resource differently. Profile validation at the boundary is the control that catches the divergence before a malformed payload reaches clinical logic.

Bulk export and documents

Population-scale reads go through FHIR Bulk Data Access. The specification defines export for a pre-authorized client, with the server returning downloadable files after it completes extraction and transformation, as set out in the HL7 Bulk Data Access implementation guide. Build that as a job pipeline: kickoff, poll status, download NDJSON in parts, reconcile record counts and make downloads resumable so a dropped connection doesn't restart a long extraction.

C-CDA covers what neither feeds nor queries handle well: discharge summaries, care summaries and outside records. Parsing it means handling document templates, narrative sections and codes that don't match your internal vocabulary.

Ekipa AI builds interoperability layers for healthcare products, including its own Clinic AI Assistant, and can take on that layer as a module-based engagement without taking over the rest of the product.

SMART on FHIR scopes and authorization failure points

The EHR's authorization server issues OAuth 2.0 tokens, and the scopes in the request name exactly what the app may do. SMART separates them into three families. Launch context comes from launch for an app started inside the EHR, or launch/patient for a standalone app where the EHR prompts the user to pick a patient. Resource access comes from patient/*.rs for read and search on the current patient, or user/*.cruds for create, update and delete across what the signed-in user can reach. Identity comes from the OpenID Connect scopes openid and fhirUser, as the SMART launch context and scope definitions set out.

The authorization server can grant less than you asked for. Persist the granted scope set at token exchange, store it alongside the token, and drive feature access from the granted scope rather than from what the app requested.

Four failure points account for most broken launches. Endpoint values differ between sandbox and production, so read the server's discovery metadata instead of hard-coding a vendor URL. A missing fhirUser scope leaves no authenticated user representation, which breaks attribution and audit trails. A wrong launch scope loses patient context, and the symptom is an empty screen rather than an error. A client secret in front-end code fails any competent security review, per the SMART app launch flow.

Test in-EHR and standalone launch as separate paths, and test each scope combination on its own, because an app can receive patient context without user identity, or identity without write permission. Add token refresh and the denial path to the matrix. The EHR owns the authorization server and app registration; engineering owns requesting the minimum scopes and validating what came back. The full launch sequence is in our SMART on FHIR walkthrough.

How an integration project runs and what sets its timeline and cost

Schedule is decided in the scope conversation, months before the first interface is built. The phases below show who owns each gate.

Phase	What is decided or delivered	Owner	Evidence of completion
1. Scope confirmation	EHR vendors, versions, sites, data elements, read-only or write-back access	Product and integration leads	Scope document with interface list
2. Security and vendor program onboarding	Security questionnaires, penetration test evidence, SOC 2 or HITRUST reports, vendor program approval	Compliance and the health system	Approved questionnaire and program registration
3. Interface design and profile mapping	Message and resource mapping to HL7 v2, US Core and local codes	Engineering	Mapping specification and capability matrix
4. Build	Interface code, SMART launch configuration, error handling	Engineering	Code review and unit test results
5. Testing	Vendor sandbox tests and each health system's test environment	Engineering with the health system's interface team	Test reports for each scope and failure path
6. Go-live with rollback	Production enablement and rollback path	Engineering, product and the health system	Signed go-live checklist and rollback test
7. Monitoring and support	Success rate, failure queues, field completeness, clinician use	Engineering with the support owner	Dashboards and incident log

Phase 1 and phase 2 consume more calendar time than phase 4 on most engagements, and test environment access is usually the binding constraint. Site type changes what's available: in 2024, 19% of U.S. substance-use and mental-health treatment facilities reported participating in a health information exchange organization, per ONC's facility data brief. A product selling into behavioral health should expect more document handling and less event feed per site.

What one scope change does to the plan

Take a hypothetical product that reads ADT and ORU feeds from one EHR at one site, then adds task write-back at three sites running two EHR versions. The first release covers one interface pair, one security review and one test environment.

The write-back request reopens scope (new data elements, new user roles), reopens security review because the product now modifies the record, adds mapping work for a second EHR version, and triples testing because each site runs its own test environment and its own interface team calendar. The build for the write-back interface is the small part. The approvals around it are not. This is why confirming access type and site list first is the step that protects a launch date, and how implementation support engagements start with us.

After launch, measure interface success rate, time to resolve failures, completeness of the fields the product depends on, and whether clinicians use the integrated workflow. A healthy interface that nobody opens is a failed project with green dashboards.

Build in-house, hire a partner or use an integration platform

Decide with five inputs in front of you: the number of EHR instances, how often interfaces change after launch, whether anyone on the team has worked a vendor developer program before, the time to first paying customer, and who is on call when a feed stops at 2 a.m.

Model	Best fit	What you still own	Main risk
In-house integration team	Long-term core capability with many EHR instances and frequent interface changes	Everything: vendor programs, security reviews, mapping, testing and on-call duty	Hiring time and knowledge concentrated in a few engineers
Partner engagement (project, dedicated team or time-bound support)	One defined build, a capability gap or a fast start before hiring	Scope, acceptance criteria and production ownership, agreed in the contract	Knowledge stays with the partner unless handover is contracted
Integration platform (interface engine or hosted integration service)	Many similar connections using standard message types	Per-site mappings, vendor program enrollment, content validation and monitoring	Licensing limits and constraints on custom profiles and transformations

A platform cuts the code you write and leaves the per-site work intact: mapping local codes, enrolling in each vendor program, validating content and monitoring what runs. A partner can cover a single build, a dedicated team or time-bound support after your own team takes over, and the contract should name who operates production monitoring after handover. In-house teams carry the full weight of security reviews and on-call rotation, and two or three engineers holding every mapping decision is a continuity problem.

Write down the three numbers: EHR instances, expected change rate, and the named owner of each runbook. Then choose the model that addresses the gaps instead of the one that appears cheapest per month. Our post on EHR integration software explains how the platform options differ in practice.

Security, BAA and compliance duties in every data flow

HIPAA is law, administered by HHS through the Office for Civil Rights, and its text sits in 45 CFR Parts 160 and 164.

A business associate agreement is required before a vendor creates, receives, maintains or transmits protected health information for a covered entity. That requirement comes from 45 CFR 164.502(e), with contract terms in 164.504(e) and the parallel condition in 164.308(b); HHS guidance on business associates sets out who counts as one. The technical safeguards in 45 CFR 164.312 cover access control, audit controls, integrity and transmission security. Minimum necessary use under 164.502(b) and 164.514(d) narrows each data flow to what the workflow needs, which changes your scope requests and message filters. Certification under 45 CFR Part 170 and the information blocking rules in 45 CFR Part 171 shape what a health system can be asked for and how quickly it must respond.

• Signed BAA before any PHI access, including test environments with real records. Owner: compliance, with counsel.

• Data minimization per interface, documented field by field. Owner: product.

• Audit logging across every read and write, including write-back. In our view this is the control most often built for reads and forgotten for writes. Owner: engineering.

• A security review pack ready before the first questionnaire arrives: completed questionnaires, penetration test evidence, and SOC 2 or HITRUST reports, which are industry assurance evidence rather than legal requirements. Owner: compliance.

• A repeat of the review when a new site is added, since each health system runs its own. Owner: product and compliance.

Breach risk is the argument that gets budget approved: HHS publishes every breach of unsecured protected health information affecting 500 or more people on its breach portal, and each new data flow adds to that exposure. None of the above is legal advice; counsel should confirm agreement terms and the minimum necessary analysis for each flow. It's also the reason our healthcare engineering practice treats the compliance architecture as part of the interface build.

How to evaluate an integration partner and spot red flags

Score candidates on the artifacts they can produce, not the answers they give. A partner who has run production interfaces can pull a runbook, a test plan and a capability matrix on request. A partner who has not will offer a slide deck.

Criterion	What to ask for	Evidence to request	Red flag
Healthcare integration experience	Production HL7 v2 or FHIR interfaces with named EHR platforms and versions	Anonymized architecture, sandbox test results and a description of a live interface	Cannot describe a production interface or the EHR versions it supported
HIPAA and BAA readiness	Signed BAA before any PHI access and documented safeguards	BAA template, policy list and latest SOC 2 or HITRUST report	Requests PHI before the BAA is signed
Testing approach	Contract tests against US Core, scope tests and failure-path tests	Test plan and versioned capability matrix per EHR and endpoint	No plan for sandbox and production differences
Support model	Monitoring, on-call coverage and a response target for failed messages	Runbook, alert thresholds and a sample incident log	Ticket-only support with no owner for failed messages
Handover	Transfer of code, documentation and production ownership	Repository access, runbooks and the capability matrix	Knowledge stays with the vendor after go-live

The testing row carries the most weight. US Core defines minimum constraints, required elements, vocabularies, value sets and REST interactions for patient data access, and it is based on FHIR R4, as the US Core Implementation Guide specifies. Two systems can both expose Patient, Observation and MedicationRequest and still disagree on required fields, coding systems, cardinality, references and search behavior. A partner who tests only successful reads has not tested the interface.

Contract tests should cover authorization scopes, search parameters, pagination, error responses, terminology bindings and conditional updates, with results feeding a versioned capability matrix per EHR and endpoint that records supported profiles, known limitations and observed behavior under test. One test worth asking for by name: query Observation by patient and category, then assert that every returned resource carries its required status element, a category code bound to the required value set and a subject reference that resolves. A second assertion submits a conditional update without the precondition the server expects and checks that the error response comes back correctly rather than writing. Two endpoints can both claim US Core conformance and still fail these checks on different elements, which is exactly the disagreement a happy-path read never surfaces.

One flag sits outside the table because it predicts schedule rather than quality: a fixed go-live date quoted before scope is confirmed. The date is a guess wearing a project plan. The decision between read-only and write-back access, the number of sites and each health system's own security review all sit upstream of any honest timeline, and that pre-interface scope is where most of the calendar risk lives, often more than in the build itself.

Ask how the candidate handles each health system's security review and test environment scheduling, because those queues consume weeks your build team cannot control. I weigh that answer as heavily as the technical evidence. If it is vague, the delays land on your launch date.

Conclusion

Most of the schedule risk sits in decisions made before the first interface exists: which EHR vendors and versions you support, how many sites you connect, which data elements move, and whether access is read-only or write-back. The build is usually the smaller variable. Each scope answer changes what security review, mapping and testing have to cover, so fix them in writing before anyone commits to a date. A change after week one reopens reviews you already passed.

Security review, vendor program approval and test environment access consume calendar time outside your control, which is why they belong in the plan before development does. Two checks close the loop: run each candidate partner through the scorecard and sign the BAA before PHI moves, then confirm who owns production after handover. Ownership means a specific team watching interface success rate, time to resolve failures, field completeness and clinician use. That team also needs authority to approve the changes every go-live eventually needs.

For the wider picture, see our EHR integration and interoperability guide, FHIR vs HL7 and our bulk FHIR export guide. To scope an EHR integration for your product, explore Ekipa's implementation support or book a consultation with Ekipa's HealthTech integration engineers.

Frequently asked questions

Which standard should a product connect with first, HL7 v2 or FHIR R4?

The data flow decides, not preference. Event notification (an admit, a posted result, a placed order) still arrives as HL7 v2 in most hospitals, while on-demand record reads usually go through FHIR R4 constrained to US Core. Most production products end up supporting both, and the standards section above maps each service to its format.

Can we run early testing before a business associate agreement is signed?

Yes, if the test plan is built around data that is not PHI. Synthetic or de-identified records cover schema validation, mapping development and the first pass of contract tests, which is most of the work that happens before environment access opens. Have counsel confirm the de-identification approach, then schedule one validation pass against real records after the agreement is in place, because generated data will not reproduce a specific instance's search behavior or configuration quirks.

Is FHIR enough to connect to any hospital EHR?

No. US Core sets a floor, and each implementation sits somewhere above it with its own version, configuration and search behavior. Every EHR instance needs mapping, profile validation and contract tests before it can be trusted. FHIR gives you a common surface for the request, not a common payload in return.

Does information blocking apply to our integration requests?

It can, depending on your role. The rules in 45 CFR Part 171 apply to actors, a set that includes health care providers, certified health IT developers and health information networks, and a digital health company's position determines whether it is one. That analysis belongs with counsel. The compliance section covers the rules an actor has to meet.

Can a partner take only the interoperability layer rather than the whole product?

Yes. Capability-specific engagements exist for exactly that scope: an interoperability layer, a data pipeline, a clinician dashboard or a security enhancement can be handed to an outside team while yours keeps the product. Ekipa AI works on that module-based basis for SaMD products. The slice still needs the same rigor as a full build, meaning defined FHIR profiles, agreed scopes and contract tests at the boundary, so specify the interface contract before you specify who builds it.