Healthcare data integration doesn’t get safer, more reliable, or easier to maintain just because you picked the right protocol. HL7 v2 and FHIR only answer how the data is formatted — they say nothing about whether that data stays encrypted in flight, whether a throttled vendor endpoint quietly drops a lab result instead of failing loudly, or whether the field mapping between two systems that both claim FHIR support actually reconciles cleanly. Those are separate engineering problems, and they determine whether an integration survives contact with a real clinical environment.

Eighty-five percent of healthcare practices reported at least one operational disruption caused by a third-party vendor failure in the past year, according to Omega Systems’ 2026 healthcare IT landscape report — and a meaningful share of those failures happen exactly where two systems hand data back and forth. Teams that treat protocol selection as the whole integration plan are usually the ones surprised by that kind of failure six months in. If you haven’t worked through HL7 v2 versus FHIR yet, our EHR integration guide for founders is the better starting point; this post picks up from there and covers the security, reliability, mapping, and maintenance work that actually determines whether an integration holds up in production.

Protocol Isn’t the Whole Integration (And Why This Guide Goes Further)

Picking HL7 v2, FHIR, or a hybrid of both settles the data format question. It doesn’t settle whether protected health information is encrypted correctly in transit and at rest, whether your integration can absorb a vendor’s rate limit without silently losing a record, whether two systems that both claim to speak the same protocol actually agree on how a field is structured, how long a vendor’s sandbox and certification process will realistically take, or who owns the interface once it’s live and something breaks. This guide assumes you’ve already made — or are close to making — the protocol call, and focuses entirely on what comes after it.

That’s deliberate. Protocol comparisons are useful, but they tend to leave engineering leads with a false sense that the hard part is over once a format is chosen. It isn’t. The considerations below are what a technical buyer actually gets asked about when a partner is scoping a real build: security posture, uptime behavior under load, data quality after mapping, the certification timeline no one budgets for, and what happens after go-live.

Security and Encryption: Protecting PHI in Motion and at Rest

None of this is optional in the way most engineers assume. Under the current HIPAA Security Rule, encryption of ePHI is technically an addressable implementation specification rather than a flatly mandatory one — HHS’s own guidance on the point is direct: a covered entity has to implement it if a risk assessment finds it reasonable and appropriate, or document an equivalent safeguard if it doesn’t. In practice, for a system moving protected health information between two EHR platforms, there’s no credible equivalent-safeguard argument. Healthcare data integration work should treat encryption as required, not optional, and build accordingly.

Encryption in Transit

Every API call and HL7 message in transit needs TLS 1.2 or higher, and “the vendor connection is encrypted” isn’t automatically the same statement as “the connection is configured correctly.” Weak cipher suites, expired certificates, and misconfigured endpoints all produce a technically-encrypted connection that still fails an audit. Verify the actual configuration on both ends of every interface, not just the presence of HTTPS in the URL.

Encryption at Rest

The source EHR is rarely the part that gets overlooked — it’s everything staged in between. Message queues, integration logs, and mapping tables that temporarily hold PHI while it’s translated between systems need the same encryption-at-rest treatment as the production database, and they’re the part of the architecture most likely to get built fast and audited late.

Access Control and Audit Logging

When a third-party middleware layer sits between two HIPAA-covered systems, access control and audit logging have to exist at that middleware layer too, not just at the EHR endpoints on either side. This is a common gap: an integration engine with broad service-account access and no per-user audit trail of its own creates exactly the kind of visibility hole a Security Rule risk assessment is supposed to catch before it becomes a breach investigation.

API Rate Limits and Reliability: Designing for the Vendor’s Terms, Not Yours

Vendor API access is a privilege the vendor controls, not a right the integrator negotiates from strength — and the 21st Century Cures Act’s information-blocking provisions exist partly because that imbalance used to be worse. Health IT developers who improperly restrict access to certified APIs can now face real penalties, which is part of why most major EHR platforms publish some form of developer access today. But “access exists” and “access is unlimited” are different things, and almost every vendor throttles.

Why Vendors Throttle, and What Actually Happens When a Limit Is Hit

athenahealth’s own developer documentation is a useful concrete example: production API access allows 50 token requests per minute, dropping to 5 per minute in the preview environment, and exceeding either limit returns an HTTP 429 and blocks new token requests for the rest of that minute. That’s a relatively transparent policy as these go — plenty of vendors only communicate specific limits during partner onboarding. What matters operationally is consistent either way: once a limit is hit, a request gets queued, rejected, or in the worst implementations, silently dropped, and which of those three happens is not something you want to discover for the first time in production.

Designing for Reliability

The fix is architectural, not aspirational. Retry logic with exponential backoff, a dead-letter queue for messages that fail repeatedly, and monitoring that flags a stalled or throttled endpoint before a human notices missing data are the difference between a request that eventually succeeds and clinical data that vanishes without a trace. This matters most for high-volume, time-sensitive traffic — urgent care practices running high-volume real-time data feeds are exactly the environment where a silently dropped record during a rate-limit event has real consequences, not just an inconvenient retry.

SLA and Uptime Expectations to Plan Around

Not every EHR vendor publishes an uptime SLA, and fewer still enforce one in a way that actually helps you when their API goes down. Ask about uptime guarantees, planned maintenance windows, and status-page transparency before the build starts, and design your own failover and alerting on the assumption that the vendor’s endpoint will go down at some point — because eventually, it will.

Data Mapping and Normalization: Where “Compatible” Systems Still Disagree

Two systems that both claim to support FHIR R4, or both speak HL7 v2, aren’t guaranteed to agree on what’s actually inside a message. This is the part of healthcare data integration that protocol selection never touches, and it’s usually where a “quick” integration turns into a six-month project.

Field-Level Mismatches

Code sets are the most common offender — local or site-specific code usage that varies even within a standardized system, units that differ from one system to the next, and free-text fields on one side that need structuring into discrete data on the other. A lab value that’s numerically correct but tagged with the wrong unit is arguably worse than a missing value, because it looks trustworthy right up until it isn’t.

The Normalization Layer

Most real integrations need a translation and mapping layer even between two systems that both technically claim protocol compliance, because compliance describes the wire format, not the semantics underneath it. Off-the-shelf middleware handles a lot of common mismatches out of the box, but it doesn’t handle every practice’s specific workflow quirks — and when it doesn’t, a custom-built mapping and integration layer is usually the more honest answer than forcing a generic tool to do something it wasn’t built for.

Testing Against Real Production-Like Data

Vendor sample payloads are clean by design, which makes them a poor test of whether your mapping logic survives contact with an actual patient population. Test against de-identified, production-like data before go-live — duplicate patients, partial records, inconsistent formatting, all of it — because that’s the data the integration will actually see once it’s live, and vendor sandboxes rarely replicate it faithfully.

Vendor Sandbox and Certification Processes: The Timeline Nobody Budgets For

Every major EHR vendor gates production API access behind some form of sandbox and certification process, and the engineering work is rarely what sets the calendar — the review queue is.

What a Typical Certification Process Involves

The pattern is consistent across vendors even when the names differ: register as a developer, get sandbox credentials and synthetic test data, build and test against that sandbox, submit for a security and functional review, then wait before production credentials are issued. Epic’s developer certification process is a useful concrete example — developers work through Epic’s Connection Hub (the successor to the earlier App Orchard program), get sandbox access to build against a simulated Epic instance, and go through a review cycle before a connection is allowed to go live at an actual customer site.

Why This Varies by Vendor and Extends Timelines

Timelines here are genuinely vendor-dependent: a straightforward, read-only FHIR R4 integration against Epic’s sandbox can realistically move through development, testing, and certification in six to ten weeks, while a broader or bidirectional build runs considerably longer, independent of how good the underlying code is. That gap between “engineering is done” and “certification is done” is one of the most common reasons integration timelines slip, and it has nothing to do with how well the team writes code.

Scoping Realistic Timelines Before the Build Starts

Ask about a vendor’s specific certification requirements — what’s reviewed, what documentation is expected, typical review turnaround — before the build starts, not after the first submission bounces back. A partner who’s been through a given vendor’s process before can tell you which steps to start in parallel with development; a partner encountering it for the first time finds out the hard way, on your timeline.

The Maintenance Burden After Go-Live

An integration that passes testing and goes live isn’t finished — it’s just entered the phase most project plans don’t budget for. Vendor API versions change; field mappings drift as either system evolves. An interface that worked cleanly for eight months can break silently the day a vendor pushes an unannounced update, and the first sign of trouble is often a clinician noticing missing data rather than an alert firing.

Interfaces that hold up in production share a few maintenance habits:

  • Monitoring and alerting that catches a broken or stalled interface before a person does, not after.
  • Versioned mapping documentation, so a change on either system’s side doesn’t turn into forensic archaeology six months later.
  • An actual team that owns the interface post-launch, rather than a vendor that handed over a “finished” integration and moved on.

This is a recurring reality in categories with heavy third-party API churn — pharmacy network integrations are a good example, since pharmacy networks change their own APIs on their own schedule. Our EHR integration services include this ongoing layer for exactly that reason: an integration you can’t afford to have fail quietly needs a team still watching it in year two, not just the year it launched.

Building an Integration That Actually Holds Up in Production

Protocol choice, security, reliability, data mapping, vendor certification, and post-launch maintenance aren’t separate line items on a healthcare data integration project — they’re one scope, and skipping any of them just moves the cost later in the timeline, usually to a worse moment than if it had been planned for up front.

If you’re still working through the protocol-level decision, our EHR integration guide for founders covers that ground. If you’ve already made that call and are ready to talk through the rest of it — security posture, vendor certification timelines, and who owns the interface after go-live — talk to our team about where your build actually sits.