Part of our complete guide to HL7 fundamentals.

You signed a customer who runs on NextGen, and now you need to read their patient data, push results back, or both. So you go looking for "the NextGen API" - and find two different products, a developer program with an approval gate, an interface engine with a confusingly familiar name, and very little that tells you which path actually fits your use case. That ambiguity, not the coding, is what stalls most NextGen integrations in the first two weeks.

This guide maps the real terrain: the two NextGen products you might be connecting to, the ONC-certified FHIR R4 APIs and how onboarding works, the HL7 v2 interfaces that still carry most live clinical traffic, and the one thing nobody warns you about - that production access and contracting, not the build, drive your timeline. If you have integrated other major EHRs, much of this will rhyme with the patterns in our EHR integration guide.

First: which NextGen are you integrating with?

"NextGen" is a brand, not a single system. Before you write a line of code, confirm which product the practice runs, because the APIs, the onboarding, and even the data formats differ.

• NextGen Enterprise - the on-premise or hosted platform built for larger ambulatory practices, multi-specialty groups, and health systems. This is where most complex HL7 interface work and the Developer Program / marketplace path live.
• NextGen Office - the cloud-based EHR and practice management system aimed at smaller and independent practices. It publishes its own FHIR R4 developer guides, including patient access and SMART app launch APIs.

The distinction matters more than it looks. A FHIR app you certify against NextGen Office will not automatically work against NextGen Enterprise, and a practice's contract, hosting model, and add-on modules all shape what you can actually reach. Ask the customer this question explicitly on day one; "we use NextGen" is not a complete answer.

The FHIR R4 APIs: ONC-certified, USCDI-shaped

NextGen Healthcare is ONC 2015 Edition Cures Update certified, which means both products expose standardized FHIR APIs designed to satisfy the 21st Century Cures Act's patient-access and information-blocking rules. In practice, that gives you a clean, predictable read surface for clinical data.

The APIs implement HL7 FHIR R4 and are scoped around the U.S. Core Data for Interoperability (USCDI): patient demographics, problems, medications, allergies, lab results, vitals, and the rest of the core data set, exposed as FHIR resources over REST. NextGen Office also publishes a Bulk FHIR (Flat FHIR) capability for group-level USCDI export, and SMART App Launch support so your app can be invoked in clinical context with OAuth2-based authorization.

If you are deciding between formats, this comparison captures the trade-off most teams wrestle with:

The short version: FHIR R4 is the better path for reading USCDI data and for patient- or provider-facing apps that launch in context. It is REST and JSON, secured with OAuth2 and SMART scopes, and it behaves consistently because the certified scope is defined for you. Where FHIR is still thin - high-volume, event-driven clinical traffic like real-time admits, discharges, and orders - HL7 v2 remains the workhorse. For the security model behind the FHIR side specifically, our healthcare API security guide walks through OAuth2, SMART on FHIR, and the HIPAA controls you will need in place before production access is granted.

The Developer Program and marketplace path

You do not get NextGen FHIR credentials by emailing a sales rep. NextGen runs an API Developer Program that gates access through registration, sandbox testing, and a production-approval step. Onboarding follows a recognizable arc.

First you register as a developer and pull the right FHIR R4 guide for your target product. Then you build against the sandbox - implement SMART app launch and OAuth2, validate your USCDI reads against the published profiles, and prove your app behaves. The third stage is where projects slow down: requesting production access. This is not a button. It involves NextGen's review, data-use agreements, and the practice's own sign-off, because you are about to touch real PHI in a production tenant. Finally, if your app is meant for many NextGen practices rather than a single customer, you can pursue a marketplace listing so Enterprise practices can discover and enable it.

Plan your schedule around stage three. The engineering against a sandbox is often the fastest part; the contracting, security review, and approval cycle is what turns a "two-week" integration into a two-month one. We say more about why this approval-and-contracting reality dominates EHR timelines in our multi-EHR integration guide, where the same pattern repeats across Epic, Oracle Health, and athenahealth.

A few things make the difference between a smooth approval and a stalled one. Have your security posture documented before you ask: how you store tokens, how you scope access, how you handle PHI at rest and in transit. Decide early whether you need a patient-facing app (where the patient authorizes access to their own record) or a provider-facing/system-level integration (where the practice authorizes a backend service) - they follow different authorization flows and carry different review weight. And get the practice itself engaged early, because their sign-off is part of the gate; a customer who has never talked to their NextGen account team will slow you down more than any code problem. The teams that ship on time treat production access as a project workstream from week one, not a formality they discover at the end.

HL7 v2 is still doing the heavy lifting

FHIR gets the headlines, but if you are moving live clinical events in and out of NextGen, you are almost certainly working in HL7 v2. The three message families you will meet most often:

• ADT (Admit, Discharge, Transfer) - patient registration and movement events. The backbone feed that keeps downstream systems' patient context in sync.
• ORU (Observation Result) - lab and diagnostic results flowing back into the chart.
• SIU (Scheduling Information Unsolicited) - appointment scheduling events, bookings, reschedules, and cancellations.

These are event-driven, near-real-time, and high-volume - exactly the traffic FHIR is not yet optimized to carry. If you want the mechanics of these message types, segment by segment, our HL7 integration guide breaks down how ADT, ORU, and SIU are structured and parsed. The practical point for NextGen specifically: most of this v2 work is going to flow through one particular interface engine.

It is also worth being honest about why v2 has not gone away. An HL7 v2 feed pushes the moment something happens - a patient is admitted, a result is finalized, an appointment is booked - and the receiving system acknowledges each message. That push-and-acknowledge model is exactly what a billing system, a patient-engagement platform, or a downstream analytics pipeline needs to stay current. A FHIR read, by contrast, is a pull: you ask for data when you want it. For batch reconciliation and patient-access apps, pull is fine. For "tell me the second this changes," you want the v2 feed. Mature NextGen integrations almost always run both, and the design question is not "which one" but "which data over which channel."

NextGen Connect is Mirth Connect - and that changes your plan

Here is the detail that reframes a NextGen HL7 project. NextGen Connect is the commercial edition of Mirth Connect, the open-source interface engine that thousands of healthcare teams already run. They are the same engine.

The lineage is straightforward. Mirth Connect started in 2006 as a tool for parsing and routing HL7 messages and was released as free open source. Mirth Corporation was acquired by Quality Systems, Inc. - the company that later rebranded as NextGen Healthcare - and the engine was renamed the NextGen Connect Integration Engine. The core is identical under either name: the same channels, transformers, MLLP listeners, JavaScript-based filters and mappings, and the same destination connectors. (One operational note: NextGen moved newer Mirth releases, 4.6 and up, to a commercial per-channel license in 2025, while older builds remain freely available - worth confirming which version a site runs before you scope licensing.)

Why this matters: if your team already knows Mirth, you already know how to build NextGen HL7 interfaces. The channel architecture, the transformer pipeline, the way you reach into an HL7 segment and reshape it - it all carries over directly. If you are new to it, the open-source engine is the perfect place to learn the exact skills you will use against NextGen, and you can stand it up locally without touching a production system. Our deep dive on building an HL7 interface engine with Mirth Connect is, in effect, a NextGen Connect tutorial by another name - the channels, filters, and ADT/ORU transformers you build there are the same artifacts you will deploy on a NextGen project.

A realistic build plan for a NextGen integration

Putting it together, a NextGen integration usually decomposes into two parallel tracks. On the FHIR track, you register in the Developer Program, build SMART/OAuth2 app launch against the sandbox for the right product, validate USCDI reads, and start the production-access conversation early. On the HL7 track, you model the ADT, ORU, and SIU feeds you need, build and test them as channels in Mirth / NextGen Connect, and agree the message specs and acknowledgments with the practice's interface team.

The mistake we see most often is treating these as one undifferentiated "API project." They are not. FHIR gives you clean, certified reads; HL7 v2 through NextGen Connect gives you the live event stream. Designing each to its strengths - and starting the contracting clock on the FHIR side before you think you need to - is what separates an integration that ships on schedule from one that quietly slips a month.

Healthcare is the only industry we work in, and we are FHIR R4 native. We have built EHR integrations for 30+ healthtech startups, including multi-EHR work for Yown Health spanning Epic, Cerner, Allscripts, and athenahealth, and we have open-sourced a Headless EHR covering 28 clinical domains and 70+ FHIR R4 resources. NextGen's split of FHIR APIs plus Mirth-based HL7 is a pattern we work in routinely. The wider regulatory context lives with ONC and the certification rules that shape every certified API surface.

Key takeaways

• Confirm the product first: NextGen Enterprise (larger practices) and NextGen Office (cloud, smaller practices) expose different APIs and onboarding.
• The FHIR R4 APIs are ONC-certified and USCDI-shaped - the clean path for patient/provider reads and SMART app launch.
• HL7 v2 (ADT, ORU, SIU) still carries most live clinical events; FHIR and v2 are complementary, not interchangeable.
• NextGen Connect is the commercial edition of open-source Mirth Connect - same engine, so existing Mirth skills transfer directly.
• Production access and contracting, not the sandbox build, are the real timeline drivers. Start that conversation early.

If you are scoping a NextGen integration and want a second opinion on the FHIR-versus-HL7 split for your specific use case, book a 15-minute call - we will tell you which path fits and roughly what the approval timeline looks like.