Every healthtech founder I know has the same origin story for their EHR integration. It goes something like this: "We figured four weeks, maybe six. We had a great engineer, the FHIR docs looked straightforward, and our pilot hospital was enthusiastic. Ninety days later, we were still debugging patient matching logic and waiting on App Orchard review."
I have lived this timeline. Not once, but across multiple integration projects. And the uncomfortable truth is that nobody tells you what the first 90 days actually look like. The vendor documentation describes the API. Your Y Combinator batchmates describe the dream. Nobody describes the middle part — the grinding, demoralizing, expensive middle part where you learn that healthcare data is nothing like the clean JSON you prototyped against.
This is the week-by-week account I wish someone had given me before we started. It is not a tutorial. It is a field report.
Week 1-2: The Optimism Phase — "This Looks Easy"
You start by reading documentation. Epic's FHIR documentation is genuinely excellent — well-organized, comprehensive, with working examples. You sign up for Epic on FHIR, get sandbox credentials in a day, and within 48 hours you are pulling Patient resources and Observations from their test environment. You write a demo. Your CTO is impressed. Your investor deck gets a new slide.
Meanwhile, you register on App Orchard (now transitioning to Epic Showroom) and start the application process. You read through Oracle Health's (formerly Cerner) Code Console documentation and get their sandbox running too. You poke around athenahealth's developer portal. Everything looks achievable.
Here is what you are not seeing yet: the sandbox is a curated, clean, well-structured dataset designed to make the API look good. It has exactly the right FHIR resources, perfectly coded allergies, neatly structured medication lists. Real production data looks nothing like this. But you do not know that yet, so you are happy. You estimate four weeks to MVP and tell your pilot hospital you will be ready next month.
You are wrong.
Week 3-4: The Reality Check — "Wait, What Do You Mean 8 Weeks?"
The first cold shower arrives when you discover that App Orchard review is not a formality. It is a multi-stage process that typically takes 8 to 12 weeks. You submit your application, answer detailed questions about your app's functionality, data access patterns, and security posture, and then you wait. There is no fast-track for startups. There is no "MVP-mode" that lets you skip ahead.
During this period, three things happen simultaneously that rearrange your entire roadmap:
First, you discover vendor fragmentation. Your pilot hospital runs Epic, but your second prospect uses Oracle Health (Cerner), and your third uses athenahealth. Each vendor has its own developer program, review process, and FHIR implementation quirks. Oracle Health's Code Console has different authentication flows than Epic. athenahealth's API has endpoints that are not strictly FHIR-compliant. You realize you are not building one integration — you are building three.
Second, you discover the middleware question. You need something between your application and the EHR that handles authentication, token management, data transformation, webhook subscriptions, and retry logic. You can build this yourself (which is what most first-time founders try, and what we tried), or you can license a middleware platform like Redox, Health Gorilla, or 1upHealth. The middleware route costs $50K to $150K per year. Building your own takes 3 to 6 months of dedicated engineering time. Neither option is what you budgeted for.
Third, you learn about SMART on FHIR. If you want your app to launch inside the EHR (as an embedded application that clinicians can use without leaving Epic or Cerner), you need to implement the SMART on FHIR authorization framework. This is a well-designed but non-trivial OAuth2 flow with launch parameters, scopes, and context-passing. It takes a solid week to implement correctly, plus another week to debug the edge cases that only appear with real identity providers.
By end of week four, your "four-week MVP" estimate is looking painfully naive. You adjust to eight weeks. You are still being optimistic.
Week 5-8: The Data Quality Nightmare — "Why Is This Allergy in Free Text?"
This is where most healthtech startups lose their innocence. You finally get access to real patient data (either through your pilot hospital's test environment or through a more realistic sandbox), and you discover that production EHR data is a war zone.
Patient matching is your first crisis. You search for a patient and get three results. Are they the same person? Different people with the same name? A patient who was registered twice? You need a patient matching strategy, and it is harder than you think. Name variations (Robert vs. Bob vs. Roberto), address changes, merged medical records, and typos in date-of-birth fields mean you cannot rely on simple exact-match queries. Real-world patient matching has a well-documented error rate that requires probabilistic algorithms, and getting it wrong has regulatory consequences.
FHIR resources are sparse. The specification defines hundreds of data elements per resource, but real-world implementations populate only a fraction. You write code expecting a nicely structured AllergyIntolerance resource with SNOMED codes and severity ratings. What you actually get is a free-text note in the note field that says "pt reports penicillin allergy — rash." No structured code. No severity. No onset date. Your entire allergy-processing pipeline needs to be rewritten around the reality that half the clinical data is unstructured text.
The data mapping grind begins. You spend three weeks — three weeks that nobody on your original timeline accounted for — building data transformation layers. FHIR Condition resources use SNOMED CT codes at one hospital and ICD-10 codes at another. Medication resources reference NDC codes, RxNorm codes, or proprietary formulary identifiers depending on the source system. Lab results use LOINC codes but with local variations. You build mapping tables, translation layers, and fallback logic. This is not glamorous work, but it is the work that determines whether your product actually functions in the real world.
Here is a pattern that catches every first-time integrator: Epic's FHIR API returns Observation resources for lab results, vitals, and social history — but the way each category is structured differs significantly. Vital signs follow the Vital Signs Profile with specific LOINC codes. Lab results include reference ranges and interpretation codes. Social history observations are often free text. You cannot write one parser for all three. You need separate handling logic for each category, with fallbacks for the cases where the hospital has customized their FHIR implementation.
By week eight, you have a working integration that handles maybe 70% of the data scenarios. The remaining 30% is a long tail of edge cases that will take months to fully address. Your pilot hospital is understanding but asking when you will be ready for production. You say two more weeks. You are wrong again, but this time for a different reason.
Week 9-12: The Compliance Gauntlet — "You Need What?"
Just when you think the technical work is done, the compliance requirements arrive. And they arrive all at once, like a wall of paperwork that nobody mentioned during the sales process.
SOC 2 Type II certification. Your pilot hospital's IT security team sends you a vendor security questionnaire. It is 400 questions long. One of the requirements is SOC 2 Type II certification, which requires an auditor to observe your security controls over a minimum period of six months. You are a two-person startup that has existed for four months. The cost is $30K to $80K through a firm like Vanta, Drata, or a traditional audit firm. Some hospitals will accept SOC 2 Type I (a point-in-time assessment) as a starting point, but many will not.
HIPAA risk assessment. You need a documented risk analysis, risk management plan, policies covering access control, audit logging, encryption at rest and in transit, workforce training, incident response, and breach notification procedures. If you have not done this before, it takes 2 to 4 weeks to get right, even with a template. The HHS guidance runs to dozens of pages.
Business Associate Agreement (BAA). Your hosting provider (AWS, GCP, Azure) needs to have a signed BAA. You need a BAA with the hospital. Your hospital's legal team will redline your BAA, and the back-and-forth takes 3 to 6 weeks. Do not assume this is a formality — hospital legal departments are thorough, and they have seen vendors cut corners.
Penetration testing. Many hospitals require a third-party penetration test before going live. This costs $10K to $25K and takes 2 to 3 weeks to schedule, execute, and remediate findings. The pen test will find things. Your remediation adds another week or two.
Here is the part that really stings: none of this is optional, and none of it can be parallelized with your engineering work unless you planned for it from day one. Most startups do not plan for it from day one. I certainly did not.
The Pivot: What Actually Works
After going through this gauntlet, here is the strategy I would use if I were starting over today. It is not the fastest path in theory, but it is the fastest path in practice because it avoids the traps that cost you months.
Start with read-only, single-direction, single-workflow
Do not try to build bidirectional data sync on day one. Start with the simplest possible integration: read-only access to patient demographics, problem list, and current medications. This is what SMART on FHIR was designed for. It requires fewer permissions, involves less risk, clears compliance review faster, and gives you a working product that clinicians can actually use while you build toward more sophisticated integrations.
Pick one EHR vendor and go deep
If your pilot hospital runs Epic, build for Epic first. Get through App Orchard review. Get listed. Get live. Then add Oracle Health. Then athenahealth. Trying to support all three simultaneously in your first 90 days is a guaranteed way to ship nothing.
Budget for compliance from day zero
Start your SOC 2 process the same week you start your engineering work. Use an automated platform like Vanta or Drata that can run alongside your development. Sign your cloud provider's BAA on day one. Get HIPAA policies drafted in week one. If you wait until the hospital asks for these things, you have already lost two months.
Use middleware — at least initially
I know it costs money. I know it feels like a dependency you do not want. But a middleware platform like Redox or Health Gorilla handles token management, data normalization, webhook reliability, and multi-vendor translation out of the box. It costs $50K per year, but it saves you 4 to 6 months of engineering time. Once you have product-market fit and revenue, you can evaluate whether to bring the integration layer in-house.
Get real data exposure early
Do not build against sandbox data for two months and then discover production data is different. Get access to de-identified production data (most hospitals can provide this under a research agreement or data use agreement) as early as possible. Build your data transformation layer against real data from the start.
The 10 Questions to Answer Before You Write a Line of Code
Before you commit engineering resources to EHR integration, sit down with your team and answer these questions honestly:
- Which EHR does your target hospital actually use? Not which one you want them to use. Which one is installed. Get the version number too — it matters.
- Do you need read-only or read/write access? Read-only clears review 3x faster. Start there unless your core product absolutely requires write-back.
- Is your hosting environment SOC 2 compliant? If you are on a shared Heroku dyno, the answer is no. Plan your infrastructure migration now.
- Do you have a signed BAA with your cloud provider? AWS, GCP, and Azure all offer these for free, but you have to request them.
- What FHIR version are you targeting? The answer should be R4 (FHIR 4.0.1). If someone says DSTU2 or STU3, they are describing a legacy system that will be harder to integrate with.
- Are you going for sandbox or production access first? Sandbox lets you build. Production requires compliance. Plan accordingly.
- Who at your company signs the App Orchard agreement? It is a legal document. Someone with signing authority needs to review it. This takes longer than you think.
- What is your patient matching strategy? If your answer is "exact match on name and DOB," you are going to have a bad time.
- What is your data mapping plan? Specifically, how will you handle SNOMED-to-ICD-10 translation, local code systems, and free-text clinical data?
- What is your budget for integration middleware? If the answer is zero, add 3 to 6 months to your timeline for building it yourself.
What Realistic Timelines Actually Look Like
Based on my experience across multiple integration projects, here are the timelines that are actually achievable:
| Integration Scope | Realistic Timeline | Common Blocker |
|---|---|---|
| Read-only patient summary (single EHR) | 3-4 months | App Orchard review |
| Read-only with SMART on FHIR launch | 4-5 months | SMART auth edge cases |
| Single-direction write-back (e.g., post results) | 5-7 months | Clinical validation requirements |
| Bidirectional sync (single EHR) | 8-12 months | Data quality + compliance |
| Multi-vendor (Epic + Oracle Health) | 12-18 months | Everything |
These timelines assume you have at least one experienced backend engineer, a cooperative pilot hospital, and the budget for either middleware or 3 to 6 months of dedicated integration engineering. If you are missing any of those, add 50% to the timeline.
Where Nirmitee Fits
We built Nirmitee because we went through this exact journey ourselves. We spent months building EHR integration infrastructure, handling FHIR data normalization, implementing SMART on FHIR authentication, and navigating vendor review processes. We learned every lesson in this article the hard way.
Now we help healthtech startups compress the 90-day timeline into something more manageable. We handle the integration infrastructure — the FHIR data mapping, multi-vendor support, SMART on FHIR authentication, and ongoing maintenance — so your engineering team can focus on the clinical workflow that makes your product valuable. We do not replace the compliance work (you still need SOC 2 and HIPAA), but we eliminate the months of integration engineering that sits underneath it.
If you are at the beginning of your EHR integration journey, or if you are somewhere in the painful middle and looking for a faster path, reach out. We have been where you are. We can help.
Building interoperable healthcare systems is complex. Our Healthcare Interoperability Solutions team has deep experience shipping production integrations. We also offer specialized Agentic AI for Healthcare services. Talk to our team to get started.
Frequently Asked QuestionsHow long does Epic App Orchard review really take?
Plan for 8 to 12 weeks. Some apps clear in 6 weeks, but that is the exception. The review includes security questionnaires, architecture review, and sometimes a live demo. Epic is transitioning to Showroom (their new marketplace), which may change the process but is unlikely to make it faster.
Can I use the same FHIR integration for Epic and Cerner?
In theory, yes — FHIR is a standard. In practice, no. Each vendor implements FHIR slightly differently. Supported resources, search parameters, authentication flows, and data population patterns all vary. You will need vendor-specific adapters even if your core data model is shared.
Do I really need SOC 2 to sell to hospitals?
Most hospitals with more than 200 beds will require it. Smaller practices and ambulatory clinics may accept alternative evidence (HIPAA risk assessment, security questionnaire, penetration test). But if you are targeting enterprise health systems, SOC 2 Type II is table stakes.
Is it worth building FHIR integration in-house or should I use middleware?
If EHR integration is your core product and you plan to support it as a primary feature, build in-house after your first successful integration (use middleware to get to market, then internalize). If EHR integration is a supporting feature of your product, use middleware permanently. The maintenance cost of in-house FHIR infrastructure is significant and ongoing.
What is the minimum viable FHIR integration?
Read-only access to Patient, Condition, MedicationRequest, and AllergyIntolerance resources via SMART on FHIR launch. This covers the patient summary use case and clears vendor review with minimal friction. You can ship a useful product with just these four resource types.