Taction Software — FHIR Integration with Mirth Connect
FHIR R4 · US healthcare · BAA-ready

FHIR Integration Services

We build and maintain FHIR R4 interfaces for US healthcare organizations and digital health companies — using Mirth Connect, HAPI FHIR, and the native APIs of Epic, Cerner and eClinicalWorks. Work is delivered as fixed-price sprints, embedded engineers, or an ongoing retainer for interfaces already carrying production traffic.

Tell us what you're integrating →See pricing →

What we build

FHIR façade over an existing HL7 v2 estate

Your interface engine keeps running exactly as it does today. We put a FHIR R4 API in front of it that reads from the same message flow, so application teams can consume Patient, Encounter, Observation and Condition over REST without anyone touching the v2 channels that already work. This is the cheapest route to a modern API surface and it does not put your existing feeds at risk.

Deliverable: A deployed FHIR R4 endpoint backed by your current engine, with resource mappings documented per segment.

HL7 v2 to FHIR R4 mapping

Segment-level mapping, done properly and validated against US Core rather than eyeballed. We work through PID, PV1, OBX, ORC and the rest field by field, decide what each one becomes in FHIR, and record the decisions where the next engineer can find them — including the fields your source system leaves empty, which is usually where these projects come unstuck.

Deliverable: A mapping specification plus working transformation, with US Core validation output showing what conforms and what does not.

FHIR server implementation

HAPI FHIR, Azure Health Data Services, or Google Cloud Healthcare API. Which one is right depends on where the rest of your infrastructure lives, what your compliance posture requires, and whether you need to extend the server's behaviour or just run it. We will tell you which we would pick for your situation and why, including when the answer is the one that costs less.

Deliverable: A provisioned, secured FHIR server with core resources loaded, auth configured, and a runbook for your team.

Bulk data export ($export)

The FHIR Bulk Data spec is straightforward on paper. In practice each vendor has its own behaviour around kickoff requests, polling intervals, NDJSON layout, and how much data it will hand over in one job. eClinicalWorks in particular has quirks that will cost you a week if you meet them for the first time in production; we have already met them.

Deliverable: A working $export pipeline with job polling, NDJSON ingestion, and retry handling for partial or expired exports.

SMART on FHIR app integration

Authorization, scopes, and launch contexts — the parts that decide whether your app actually launches inside the EHR or fails a security review. We handle standalone and EHR launch flows, scope negotiation against what the vendor will actually grant, token refresh, and the sandbox-to-production path including the vendor registration steps.

Deliverable: A registered SMART app with working launch flows in the vendor sandbox and a documented production go-live path.

US Core / USCDI v4 compliance work

A gap assessment against the current US Core profiles and USCDI v4 data classes, then the remediation to close what is missing. This is the work that turns "we support FHIR" into something that survives a certification review or a payer's technical due diligence.

Deliverable: A conformance gap report against US Core and USCDI v4, plus the implementation to close the gaps you choose to close.

Also within scope

CDS Hooks integration

Clinical Decision Support Hooks development — custom CDS services that surface evidence-based alerts, order sets, and recommendations inside EHR workflows. Covers patient-view, order-select and order-sign hooks, FHIR prefetch query design for low-latency responses, card and suggestion authoring, and integration with the Epic CDS Hooks sandbox and Cerner hooks framework.

ONC and HTI-1 compliance development

The technical requirements of the ONC 21st Century Cures Act and the HTI-1 rule: Patient Access API, Provider Directory API, payer-to-payer exchange, information blocking exceptions documentation, and SMART on FHIR authorization for patient-facing apps. Includes a compliance gap assessment and a remediation roadmap.

Platforms we work with

Each of these has its own auth model, its own API quirks, and its own vendor process for getting to production.

Epic

App Orchard / Vendor Services

Cerner — Oracle Health

Millennium, code marketplace

eClinicalWorks

including $export quirks

NextGen

NextGen Connect and EHR APIs

athenahealth

athenaOne APIs

Meditech

Expanse and Magic

Allscripts — Veradigm

Unity and FHIR APIs

Greenway Health

Intergy and Prime Suite

How engagements work

Fixed-scope project

From $13,500

6 weeks, fixed price, fixed scope

You know what you need built. We scope it, quote it once, and deliver against that number. The FHIR R4 Adapter Sprint and the eClinicalWorks $export Sprint both start at $13,500 over six weeks. Larger FHIR work is quoted the same way — a fixed number before we start, not a rate card and an open clock.

See sprint scopes and pricing →

Staff augmentation

From $3,800/month

60 hours of senior engineer time per month

A senior FHIR and HL7 engineer working inside your team, on your board, in your standups. Priced as monthly capacity rather than a rate: 60 hours a month at the entry tier, 120 at the middle tier, up to a four-engineer team at the top. Useful when you have the roadmap but not the interoperability depth in-house.

See capacity tiers →

Ongoing support retainer

From $3,800/month

4-hour critical SLA, 15 minutes on Silver and above

For interfaces already in production. Monitoring, incident response, version upgrades, and the mapping changes that arrive every time a vendor updates something upstream. Bronze covers 60 hours a month with a 4-hour critical response; Silver moves that to a 15-minute critical response and 120 hours.

Compare support plans →

Where we work

We work with health systems, labs, and digital health companies across the United States, with delivery staffed for US business-hours overlap rather than a handoff to a timezone twelve hours away. That includes California and the West Coast — Los Angeles, Orange County, and the Bay Area — where most of our digital health work sits, along with Texas, New York, and the Northeast corridor. Our offices are in Chicago, Austin, Sacramento, and Cheyenne.

In practice location matters less than overlap. FHIR work needs live conversations with your EHR vendor's technical contacts and your own security reviewers, and those happen in your working day. Engineers on your engagement are reachable during Pacific and Eastern business hours, and production incidents are covered outside them under a support retainer.

Proof

Three engagements, anonymized. Full write-ups with architecture diagrams are on the case studies page.

Health-tech startup · Series A

First Epic integration shipped in six weeks, with no integration hire

Constraint: Two backend engineers, no HL7 experience, and a 60-day deadline before a hospital pilot.

Shipped: Full ADT and orders integration live in six weeks. Epic Connection Hub registration completed. The internal team was trained to maintain it, and zero integration engineers were hired.

Specialty clinic · athenahealth

ADT latency cut from four seconds to 180ms

Constraint: ADT messages from athenahealth took up to four seconds to reach downstream systems, breaking real-time scheduling and creating phantom appointments.

Shipped: Channel architecture redesigned. Throughput up 20×, p95 latency down from 4,000ms to 180ms.

Diagnostic lab · Multi-EHR

Surprise HIPAA audit passed after a two-week remediation sprint

Constraint: A gap assessment found weak TLS configuration, audit logging gaps, and PHI sitting in plaintext in the message store.

Shipped: All Critical and High findings closed in two weeks. Audit logging brought to an OCR-defensible standard. The follow-up audit returned zero findings.

FAQ

Frequently Asked Questions

FHIR integration, scoping, and commercial questions.

Which FHIR implementation guides do you support?
We support US Core, Da Vinci PDex, Da Vinci PAS (Prior Auth), CARIN Blue Button, mCODE (oncology), QI-Core, and custom IGs. We also help organizations develop and publish their own FHIR IGs.
Can you integrate FHIR with our existing HL7 v2 infrastructure?
Yes. Using Mirth Connect and custom mapping engines, we build bidirectional bridges between your legacy HL7 v2 interfaces and FHIR R4 APIs — so both old and new systems can coexist.
Do you offer FHIR integration for smaller clinics and practices?
Absolutely. We work with organizations of all sizes — from single-provider practices to large health systems. We scope projects to match your budget and integration complexity.
How do you handle FHIR version mismatches between systems?
We implement translation layers between FHIR STU3 and FHIR R4, handle structural maps, and manage version negotiation at the API level. Content negotiation and version-aware routing are standard parts of our integration architecture.
What FHIR version do you develop against?
We primarily target FHIR R4 (4.0.1), which is required for ONC compliance and supported by all major EHRs. We also support FHIR STU3 for organizations with legacy systems and can implement upgrade paths from STU3 to R4.
Can you help us pass Epic App Orchard review?
Yes. We have experience building SMART on FHIR apps certified through Epic App Orchard and Cerner's code marketplace. We guide you through the sandbox testing, security review, and go-live process.
How long does a FHIR R4 server implementation take?
A baseline FHIR R4 server with core resources (Patient, Encounter, Observation, Condition) typically takes 6–10 weeks. Full implementation with bulk export, SMART auth, and custom profiles depends on scope.
Do you work with open-source FHIR servers like HAPI?
Yes. We configure, extend, and maintain HAPI FHIR servers and can also implement FHIR on top of custom backends. We help you choose the right stack based on your infrastructure and compliance requirements.
How long does a FHIR integration take?
A FHIR façade over an existing HL7 v2 estate or a vendor bulk-export pipeline typically runs six weeks, which is how our fixed-price sprints are scoped. A baseline FHIR R4 server implementation runs six to ten weeks. Larger programmes — multi-resource mapping across several source systems, or US Core conformance work on top of a server build — are longer and we scope them explicitly rather than averaging them. The variable that moves timelines most is not our side; it is how quickly the EHR vendor grants sandbox and production access.
What does FHIR integration cost?
Fixed-scope FHIR projects start at $13,500 for a six-week sprint, which covers the FHIR R4 Adapter and eClinicalWorks $export scopes. Ongoing support for interfaces already in production starts at $3,800 per month for 60 hours of senior engineer time with a 4-hour critical response. Staff augmentation is priced on the same monthly capacity basis. We publish these numbers rather than quoting on request, because a fixed number you can take to a budget holder is more useful than a conversation.
Do you work with Epic and Cerner directly, or through our IT team?
Either, and in practice usually both. Vendor programmes like Epic's Vendor Services and Oracle Health's code marketplace require a registered application and a named technical contact, and we can take that role or work behind your team as a subcontractor. What we cannot do is bypass your organization's own governance — the sandbox credentials, the security review, and the production connection request all run through your IT and compliance functions, and we work to their process rather than around it.
Can you make our existing HL7 v2 interfaces FHIR-compatible without a rebuild?
Yes, and it is usually the right first move. A FHIR façade reads from your existing message flow and exposes FHIR R4 resources over REST, so your v2 channels keep running untouched while application teams get a modern API. You get the API surface without the risk of re-plumbing feeds that already work, and you can migrate the underlying interfaces later, or never, depending on whether there is a reason to.
Do you sign a BAA?
Yes. We sign a Business Associate Agreement on every engagement that involves access to protected health information, before any access is granted. For scoping conversations we work from PHI-stripped exports and configuration files, which contain no patient data and need no agreement in place to review.

Tell us what you're integrating

Describe the source system, the target, and the constraint you are working against. A senior engineer will tell you what the work involves and what it costs — a fixed number, not a rate card.

Tell us what you're integrating →See pricing →

Part of our Mirth Connect support practice — senior HL7 and FHIR R4 engineers, based in the US.