EHR integration is the process of connecting your application to an electronic health record system so clinical and administrative data can flow between them safely and accurately. The two standards that make this possible are HL7 v2, the long-established messaging format used by most hospitals, and FHIR (Fast Healthcare Interoperability Resources), the modern REST/JSON API standard now mandated across much of the industry. In practice, a robust integration usually supports both: FHIR for new web and mobile experiences, and HL7 v2 for the older interfaces still running inside most healthcare organizations.
Why EHR integration is hard (and why standards exist)
Healthcare data is high-stakes, deeply structured, and spread across dozens of vendor systems that rarely speak the same dialect. A single patient encounter can touch scheduling, admissions, labs, pharmacy, billing, and clinical documentation, each potentially in a different system. Without shared standards, every connection becomes a bespoke, brittle project. HL7 and FHIR exist to reduce that chaos to a predictable set of message types, data models, and exchange patterns.
Getting integration right matters for more than convenience. Poorly mapped data can put the wrong allergy or medication in front of a clinician. Standards, validation, and careful data mapping are what keep an integration from becoming a patient-safety risk.
HL7 v2 vs. FHIR: what is the difference?
Both come from HL7 International, the standards body behind healthcare interoperability, but they solve the problem differently.
- HL7 v2 is a pipe-and-hat delimited messaging standard (segments like MSH, PID, OBR, OBX) typically exchanged over MLLP/TCP. It is battle-tested, ubiquitous in hospitals, and event-driven: an admission triggers an ADT message, a lab result triggers an ORU message. It is also notoriously flexible, meaning two systems can both be "compliant" yet still disagree on how a field is used.
- FHIR is a modern web standard built on RESTful APIs, JSON or XML payloads, and discrete Resources such as Patient, Observation, Encounter, MedicationRequest, and DocumentReference. You interact with it the way you would any REST API (GET, POST, search parameters), which makes it far friendlier for web, mobile, and cloud applications.
A useful rule of thumb: HL7 v2 moves data between backend systems as events happen, while FHIR is ideal for building applications on top of health data. Many real-world integrations run an engine that ingests HL7 v2 and exposes it as FHIR resources for developers.
The core FHIR concepts you actually need
FHIR is large, but most projects rely on a small, high-value subset. Focus first on these:
- Resources and references: Every clinical concept is a resource with a stable ID, and resources link to each other (an Observation references a Patient). Model your data around these relationships rather than flattening everything.
- US Core and other profiles: Base FHIR is intentionally generic. Implementation guides like US Core constrain resources to real-world requirements and define which fields are mandatory. Build against the relevant profile for your region.
- Search and pagination: FHIR's search API (for example, GET /Observation?patient=123&category=vital-signs) is how you query data. Plan for paging, filtering, and _include to reduce round trips.
- SMART on FHIR: The OAuth 2.0-based authorization framework that lets third-party apps launch inside an EHR with scoped, patient-specific access. If you are building an app that plugs into Epic, Cerner/Oracle Health, or similar, SMART on FHIR is the entry point.
The authoritative reference for all of this is the official HL7 FHIR specification, which documents every resource, search parameter, and data type.
How do you plan an EHR integration project?
Successful integrations are less about heroic coding and more about disciplined planning. A dependable sequence looks like this:
- Map the use case to data. Decide exactly which events and resources you need. "Sync patient demographics and lab results" is far more tractable than "connect to the EHR."
- Inventory the source systems. Identify each EHR's supported standards, versions, API endpoints, and rate limits, and confirm whether you get FHIR, HL7 v2, or both.
- Design the data mapping. Create an explicit mapping between source fields, code systems (LOINC, SNOMED CT, ICD-10, RxNorm), and your internal model. This is where most defects hide.
- Choose an integration approach. Direct API calls, an interface engine (Mirth/NextGen Connect, Rhapsody), or a managed interoperability platform, depending on volume and how many systems you touch.
- Validate relentlessly. Use conformance tools, test against sandbox environments, and confirm real messages parse correctly before touching production.
- Plan for errors and reconciliation. Networks fail and messages arrive out of order. Build retries, dead-letter handling, and duplicate detection from day one.
Security and compliance are not optional
Any system handling protected health information must be designed for compliance from the start, HIPAA in the US and GDPR in Europe among them. Practical essentials include:
- Encryption in transit (TLS) and at rest for all PHI.
- OAuth 2.0 and SMART scopes so applications receive only the minimum access they need.
- Comprehensive audit logging of who accessed which record and when.
- De-identification for analytics and test environments so real patient data never leaks into lower environments.
- Business Associate Agreements with every vendor in the data path.
Treat security as an architectural requirement, not a final checklist. Retrofitting compliance onto a finished system is expensive and risky.
Common pitfalls to avoid
- Assuming "FHIR compliant" means "identical." Vendors implement optional fields and extensions differently; always test against the actual target system.
- Skipping terminology mapping. Mismatched codes for the same lab or diagnosis quietly corrupt downstream analytics.
- Underestimating HL7 v2's persistence. Even FHIR-forward organizations still run critical v2 interfaces you will need to support.
- Ignoring patient matching. Deduplicating and correctly linking patient identities across systems is a project in itself.
Frequently asked questions
Is FHIR replacing HL7 v2?
Not entirely, and not soon. FHIR is the strategic direction and is required for many patient-access APIs, but HL7 v2 remains deeply embedded in hospital operations. For years to come, most serious integrations will need to speak both, often bridging v2 messages into FHIR resources.
Do I need a dedicated interface engine?
It depends on scale. For a single API integration, direct FHIR calls may be enough. Once you are connecting to multiple systems, transforming message formats, and routing high volumes, an interface engine or interoperability platform pays for itself in reliability and maintainability.
How long does an EHR integration take?
A focused, well-scoped integration against a modern FHIR sandbox can reach a working prototype in weeks. Production readiness, including terminology mapping, security review, and testing against real vendor quirks, typically extends the timeline to a few months, depending on the number of systems and data types.
What skills does the team need?
Beyond strong backend and API engineering, you want people who understand healthcare data models, terminology standards, SMART on FHIR authorization, and compliance. The domain knowledge is what separates an integration that merely connects from one that is safe and durable.
How Direlli can help
Direlli builds and integrates healthcare software for clients across the US, Europe, and MENA, including custom EHR development and standards-based HL7 and FHIR integrations. With a 5.0 rating on Clutch and dedicated engineering teams experienced in compliant, interoperable systems, we can help you scope, design, and ship your integration with confidence. Contact us to talk through your project.
