What EHR and EMR integration means.
Most healthcare software is only useful if it can read from, and sometimes write to, the system of record: the EHR or EMR. A patient app that cannot show an appointment, a documentation tool that cannot file a note and a scheduling tool that does not see the clinic's calendar all create double entry. Integration is how you avoid it.
This page is the commercial overview for organizations that want an integration built. If you want to understand the standards first, start with our FHIR API and EHR integration guide, then come back. It sits within our broader healthcare software development work, alongside telemedicine app development.
The interfaces we build against.
FHIR R4 APIs
FHIR (Fast Healthcare Interoperability Resources) is, in HL7's words, a standard for health care data exchange published by HL7. Release 4 describes a REST API with search and JSON or XML formats. It is the usual choice for apps that read patients, encounters, observations and appointments.
SMART on FHIR
SMART App Launch is an implementation guide built on OAuth 2.0 for client apps to authorize, authenticate and integrate with FHIR systems. It lets an app launch inside the EHR with the selected patient as context, or run as a backend service without a user present.
HL7 v2 interfaces
The older pipe-delimited messaging format for admissions, orders and results. You meet it when connecting to a hospital interface team, a lab or a billing system. It is usually routed and transformed through an integration engine.
Integration engines
Tools that receive messages, transform them and route them reliably. Mirth Connect is a common one; NextGen describes it as an integration engine it licenses commercially. We use an engine when you have many interfaces or need to translate formats.
Sources (read 2026-11-01): HL7 FHIR R4 overview; HL7 SMART App Launch; NextGen Mirth Connect page, which describes a commercial licensing model with flat-fee annual licensing per server. Check current terms with the vendor before you plan around them.
Vendor developer programs, including Epic.
Large EHR vendors do not let a developer connect to a live hospital system directly. They run developer programs, and hospitals decide which apps they turn on.
Epic. Epic's developer site, fhir.epic.com (read 2026-11-01), offers a free sandbox to "test APIs against example data", software registration and client identifier management, support for DSTU2, STU3 and R4 FHIR versions, and documentation for patient-facing apps as well as clinician-facing tools such as CDS Hooks and FHIRcast. That is the path for Epic EHR integration: register the app, build and test in the sandbox, then work with each customer organization to connect to its live system.
Other vendors. Other EHR vendors, including Oracle Health (Cerner), set their own access rules, API coverage and terms, and these change; we have not summarized them here because we only describe what we have read from the vendor. We read the current documentation for the specific vendor at the start of the project instead of assuming one pattern fits all, and we tell you early if a vendor does not expose what you need.
What an EHR integration project involves.
- 1
Define the data and direction
Which data you need (patients, appointments, results, documents), whether you only read or also write, and who can see what. Writing to a chart is a higher-risk step and gets more design and testing.
- 2
Confirm access with the vendor
Developer registration, sandbox access and the customer organization's approval process. These waits are the usual critical path, so we start them first.
- 3
Map and transform
Mapping your data model to FHIR resources or HL7 segments, including the awkward cases: missing fields, merged patients, time zones and local codes.
- 4
Build and test with synthetic data
Integration code, an interface layer or engine channel if needed, error handling and retry, and a clear way to see when a message failed. No real PHI in development.
- 5
Security review
Access control, audit logging, encryption in transit and at rest, and a BAA with each vendor in the chain, checked before go-live.
- 6
Go-live and monitoring
A staged release, monitoring for failed messages and token expiry, and a support plan for when the vendor changes an API.
We build and run clinical documentation software for home-health agencies that connects to the EHRs agencies use, so the points above come from running integrations, not only designing them. We do not name the product, the clients or the EHR vendors.
EHR software development and companion tools.
A few organizations ask us to build an EHR or EMR from scratch. That is a very large undertaking with heavy regulatory and certification scope, and for most practices it is the wrong first move. What we usually build instead are the tools around an existing EHR: documentation helpers, patient apps, referral and authorization trackers, scheduling and reporting tools, and the integrations that tie them together. If you do have a specialty workflow that off-the-shelf EHRs handle badly, we can scope a focused module first and grow from there.
On cost, the main drivers are the number of systems, read versus write access, the standards involved and the vendor approval path. See the cost section on our healthcare software development page, our pricing page and our guide to custom software development cost. Where the integration runs matters too; see HIPAA-compliant hosting.
Frequently asked questions.
What are EHR integration services?
They are the work of connecting your software to an electronic health record system so data moves between them safely: reading patients, appointments and results, and sometimes writing documentation back to the chart. It is done through standard interfaces such as FHIR APIs and HL7 v2 messages, and often through an integration engine.
Can you integrate with Epic?
We build against the interfaces Epic publishes. Epic runs a developer program at fhir.epic.com with a sandbox for testing against example data, client registration, and R4 among the FHIR versions it supports. A live connection to a particular hospital then depends on that hospital's own approval and configuration, which is outside any developer's control, so we plan for it from the start.
How long does an EHR integration take?
The coding is usually the shorter part. Sandbox access, vendor app review, security questionnaires at the provider organization and interface-team scheduling set the pace. We list those dependencies in the estimate and begin them in the first weeks so they run in parallel with the build.
How much does EHR integration cost?
It depends on the number of systems, whether the integration is read-only or writes to the chart, the standards involved and how many data types you need. We do not publish a figure for it. Our published starting prices are on our pricing page, and we give a fixed estimate after discovery.
FHIR or HL7 v2: which do we need?
Whichever the other system supports for the data you need. Newer EHR APIs and patient-facing apps lean on FHIR; many hospital interfaces for orders, results and admissions still run on HL7 v2. Many projects use both.
Is a Mirth Connect interface engine required?
No. An integration engine helps when you manage many interfaces, transform between formats or need reliable message queuing. A single FHIR API integration can be built directly into your application. We will recommend the simpler option when it is enough.
Do you sign a BAA?
Yes. We sign a BAA before handling protected health information, and we work with synthetic data in development and test.
Tell us which systems need to connect.
Name the EHR, the app or tool on the other side and whether you need to read, write or both. We will tell you what the vendor path looks like and give a fixed estimate.
Start with a free discovery callGet In Touch
Still have questions?.
We're ready to answer your questions and jump start your project