Most digital health companies underestimate EHR integration. The FHIR spec exists, but every major EHR vendor implements it differently. Epic's sandbox environment has its own certification process. Cerner's APIs have their own quirks. HL7 v2 messages look standard until you hit the proprietary segments that vary by hospital. Engineering teams without prior EHR experience routinely burn four to six months on integrations that should take eight to twelve weeks. At RaftLabs, we've built FHIR R4 integrations against Epic, Cerner, Allscripts, Meditech, and Athena. We know the certification workflows, the common data normalization traps, and how to architect a HIPAA-compliant data layer that your legal and compliance teams will accept. We handle the EHR side so your team can focus on the product. Most EHR integration builds ship in 8 to 24 weeks depending on scope, at a fixed price.
Recent outcomes
Voice AI · Research
Text-based interviews converted to automated phone calls
6× deeper insightsAI Automation · Ops
Manual invoice OCR across 40+ gas stations
20k+ txns day oneLoyalty · Retail
SuperValu & Centra loyalty platform with receipt validation
1,062 users in 4 weeksSaaS · Logistics
Multi-carrier shipping hub for Indonesian eCommerce
2,000+ shipments yr 1RaftLabs builds custom EHR integration services for digital health companies, telehealth platforms, and healthcare SaaS products. We develop FHIR R4 API integrations with Epic, Cerner, Allscripts, Meditech, and Athena; HL7 v2 message parsing and transformation; SMART on FHIR app development; bi-directional data sync for patient records, appointments, labs, and medications; and HIPAA-compliant data architectures. A single-EHR FHIR integration typically delivers in 8 to 16 weeks at a fixed price of $40,000 to $90,000.
Trusted by
The FHIR spec is public. Epic publishes developer documentation. So why do digital health companies spend six months on integrations that should take two?
Three reasons. First, every EHR vendor implements FHIR differently. The spec is a framework, not a contract. Epic's FHIR implementation supports certain resource types and ignores others. Cerner's API quirks are different from Epic's. Athena has its own conventions. Your team needs EHR-specific experience, not just FHIR spec knowledge.
Second, production access requires certification. Epic's App Orchard review, Cerner's code program, and similar vendor processes take weeks of their own. You can complete the technical integration while waiting for certification approval, but you cannot ship to customers until it clears.
Third, the data is messy. Patient demographics vary in completeness. Lab result units are non-standard. Medication names and codes differ between systems. Building a normalization layer that makes this data usable in your application adds time that most roadmaps do not account for.
Capabilities
Connection to Epic MyChart and Epic App Orchard, Cerner PowerChart, Allscripts, Meditech, and Athena via their FHIR R4 endpoints. FHIR resource types covered: Patient, Encounter, Observation (labs, vitals), Condition (diagnoses), MedicationRequest, Appointment, AllergyIntolerance, Procedure, DocumentReference, and DiagnosticReport. Read-only queries for single-patient data retrieval on demand, and webhook-based subscriptions for real-time event notifications where the EHR supports them. OAuth 2.0 and SMART on FHIR authentication flows for patient-facing and clinician-facing access patterns. FHIR response normalization layer that maps EHR-specific extensions and coding systems (SNOMED, LOINC, RxNorm, ICD-10) to a consistent internal representation your application can work with.
Parsing and transformation of HL7 v2 messages from hospital interface engines and legacy EHR systems. Message types handled: ADT (admission, discharge, transfer events), ORU (lab and radiology results), ORM (order messages), MDM (medical document notifications), and SIU (scheduling). MLLP listener setup for receiving messages over TCP, with acknowledgment handling (ACK/NAK) and message queue for reliability. Transformation from HL7 v2 pipe-delimited format to structured JSON or FHIR-equivalent resources for use in your application. Error handling for malformed messages, unexpected segments, and non-standard vendor extensions. Message routing rules to direct specific message types to the appropriate processing workflows in your system.
Development of SMART on FHIR applications that launch from within the EHR clinician workflow. Patient-context launch -- the app receives the current patient's FHIR ID and can immediately query that patient's data without a separate search. Clinician-context launch with practitioner scope. Launch from Epic Hyperspace, Cerner PowerChart, or any SMART-compatible EHR. App Orchard submission support: we prepare the technical documentation, complete Epic's app review questionnaire, and handle the review process including any clarification rounds. SMART on FHIR is the fastest path to embedding your application into an existing clinical workflow without requiring the hospital to change their EHR.
Two-way data flow between your platform and the EHR: reading patient demographics, appointment schedules, lab results, medications, and diagnoses from the EHR into your application, and writing structured data back into the EHR record. Write-back use cases include: clinical notes as DocumentReference resources, care plan updates, appointment status changes, and structured observations from your platform. Write-back scope is constrained by what each EHR vendor permits via API -- Epic's write scope is more limited than its read scope, and some resource types require additional vendor approval. We map your specific write-back requirements against what each target EHR's API supports and flag any gaps that require alternative approaches before we build.
PHI handling architecture designed for HIPAA compliance: encryption in transit (TLS 1.2 minimum) and at rest (AES-256), access control with role-based permissions and minimum necessary access, comprehensive audit logging of every PHI access event with user, timestamp, and data accessed, and secure API key and credential management. PHI data minimization -- we store only the specific fields your application needs rather than caching full EHR records. Audit trail design that supports HIPAA breach assessment and your organization's compliance program. Architecture documentation suitable for your compliance team's HIPAA risk assessment and for presentation to healthcare enterprise customers during their vendor security reviews.
Master Patient Index (MPI) logic to resolve patient identity across multiple EHR systems and data sources. Deterministic matching on exact field combinations (name + date of birth + gender + address), probabilistic matching with configurable confidence scoring for partial matches, and a review queue for near-match exceptions that fall below the auto-match threshold. Deduplication rules that handle common data quality issues: name variations (legal name vs. preferred name), address changes, date of birth transcription errors, and multiple MRN assignments for the same patient across systems. The MPI layer sits between your application and the source systems, presenting a single unified patient record regardless of how many EHRs contribute data. Configurable matching rules and thresholds so your clinical and compliance teams control the trade-off between false positive and false negative match rates.
Tell us your target EHR, the data types you need to sync, and whether you need read-only or bi-directional. We'll scope the integration and give you a fixed price and timeline.
Three layers of complexity compound on each other.
Proprietary implementations on top of open standards. FHIR R4 is a standard. But Epic's FHIR endpoints support a specific subset of resources, return vendor-specific extensions, and require Epic-specific authentication flows. What works in Epic's sandbox does not always work in Cerner's. What works in Cerner does not always work in Allscripts. Your team needs EHR-specific experience, not just FHIR knowledge.
Certification adds timeline independent of development. Epic's App Orchard review process runs 8 to 16 weeks from submission to approval. You can complete your technical integration in parallel, but you cannot connect to production Epic systems at a customer site until the review clears. That timeline needs to be on your product roadmap before you promise a launch date to a hospital customer.
Data quality is inconsistent. Patient records in production EHR systems contain incomplete fields, non-standard coding, duplicate entries, and historical data entered in free-text fields rather than structured codes. Building a normalization layer that makes this data reliably usable in your application -- and deciding what to do when required fields are missing -- adds meaningful development time that spec-reading does not reveal.
| Scope | Timeline | Cost range |
|---|---|---|
| Single EHR, FHIR R4 read-only (demographics, appointments, labs) | 8 to 12 weeks | $40,000 to $65,000 |
| Single EHR, FHIR R4 bi-directional with write-back | 12 to 16 weeks | $55,000 to $90,000 |
| Multi-system HL7 v2 integration (hospital interface engine) | 10 to 16 weeks | $45,000 to $80,000 |
| Multi-EHR FHIR + HL7 v2 with patient identity matching | 16 to 24 weeks | $80,000 to $150,000 |
Epic App Orchard certification adds 8 to 16 weeks to production readiness and is not included in development time above. These are fixed-price engagements -- we scope before we quote, and the price does not change during delivery unless the scope changes.
We start with discovery. Before any code is written, we need to understand your target EHR systems, the specific data types you need to access or write, whether patients or clinicians are the API users, and what your compliance requirements are. That conversation typically takes two to three hours and produces a scope document with the exact API endpoints, data flows, and architecture decisions we will make.
From there, we build against the EHR sandbox environment first. Epic, Cerner, and Athena all provide sandbox credentials for development. We build and test against sandbox data before you have access to any patient information. That phase also covers the App Orchard submission documentation if Epic is in scope.
Production integration and normalization come next. We connect to production EHR endpoints at your first customer site, build the data normalization layer for that site's specific EHR configuration, and run live data validation against real (but de-identified in development) patient records.
We deliver working integrations, not architectural documents. Your engineering team inherits a codebase they can extend, test, and operate. We document the integration patterns, the certification requirements for each EHR vendor, and the data normalization decisions so the next engineer who touches the code understands what was built and why.
If you need to connect to Epic, Cerner, or any major EHR system, contact us and tell us which system and what data you need. We will scope it and give you a fixed price before you commit to anything.
Frequently asked questions
HL7 v2 is the older messaging standard. It has been in use since the late 1980s and is still the dominant format for hospital-to-hospital and system-to-system event notifications -- admission, discharge, transfer, lab result delivery, order placement. If a hospital needs to push patient admission data or lab results to your platform in real time, they are most likely sending HL7 v2 ADT or ORU messages over MLLP or TCP. FHIR R4 is the modern REST-based API standard. Major EHR vendors now expose FHIR R4 endpoints, and it is the required standard for US ONC interoperability rules under the 21st Century Cures Act. If you need to query patient records, pull appointment data, or write clinical notes back into the EHR via API, FHIR R4 is the right approach. In practice, most healthcare integrations involve both. Your platform might receive real-time HL7 v2 ADT feeds from a hospital's interface engine, while also querying the EHR's FHIR API to pull richer structured data on demand. We scope which protocols apply to your specific use case before we build.
Epic's FHIR API implementation is more complete than most EHR vendors, but their certification and sandbox process adds time. To get production API credentials for an Epic customer, your application has to pass Epic's App Orchard review process. That involves submitting the app for review, demonstrating HIPAA-compliant data handling, and meeting Epic's technical requirements. The timeline from sandbox access to production approval typically runs 8 to 16 weeks, independent of the technical integration work itself. We have experience navigating the Epic App Orchard process. We know what documentation Epic requires, what the common rejection reasons are, and how to structure the integration to pass review without multiple rounds of changes. If your target customers are on Epic -- and most large US hospital systems are -- the certification timeline needs to be factored into your product roadmap from the start.
Patient identity matching is one of the harder problems in healthcare interoperability. Each EHR system assigns its own internal patient ID. When a patient exists in Epic at hospital A and in Cerner at hospital B, there is no shared universal identifier. Master Patient Index (MPI) matching uses a combination of deterministic and probabilistic matching: exact matches on name, date of birth, gender, and address are deterministic; partial matches on subsets of those fields with confidence scoring are probabilistic. Building a reliable MPI for a multi-system integration requires defining your matching rules, handling edge cases like name changes, address updates, and transcription errors, and deciding how to handle near-matches that could be the same person or two different people. We build the patient deduplication logic that sits between your platform and the EHR systems, so your application works with a clean patient record regardless of how many source systems feed into it.
A FHIR R4 integration with a single EHR system -- Epic, Cerner, or Athena -- covering patient demographics, appointments, and clinical data reads typically runs $40,000 to $90,000 and delivers in 8 to 16 weeks. If the scope includes HL7 v2 message parsing from a hospital interface engine plus multi-system integration against two or three EHR vendors, expect $80,000 to $150,000 and 16 to 24 weeks. The largest cost drivers are the number of EHR systems in scope, the data types you need to sync (read-only versus bi-directional write-back), and whether you need a custom FHIR server or are querying existing EHR-hosted endpoints. Epic App Orchard certification adds 8 to 16 weeks to production readiness independent of development time. We scope every integration after reviewing your target EHR systems, data flow requirements, and compliance constraints before pricing.
HIPAA compliance is built into how we architect healthcare integrations, not added at the end. PHI (protected health information) handling, audit trails, encryption at rest and in transit, access controls, and BAA (business associate agreement) requirements are scoped during discovery and addressed in the architecture before a line of code is written. We do not sign BAAs as a subcontractor on behalf of your organization -- that is between your business and the EHR vendor or covered entity -- but we design the technical architecture to support your compliance obligations and document the data flows that your compliance team needs for their assessment. If your legal team needs documentation of how PHI moves through the integration layer, we produce it.
Work with us
We scope EHR Integration Services in 30 minutes. You walk away with a clear cost, timeline, and approach. No commitment required.